Let’s have a date! - Date fields in SAP® Fi­nan­cials

If you ever dealt with data analytics in a SAP® environment, you probably came across a date field or two, or three, or even a handful.

To shine some light on that topic, we will have a look at some basic date fields in SAP®. All our examples will use the date format DD-MM-YYYY, so Christmas 2014 will be written like 25-12-2014.

Starting with the financials module and looking at table BKPF for example (which contains the General Ledger document headers) you have at least three important date fields to look at:


Document numberCompany CodeFiscal YearDocument TypeDocument DatePosting DateEntry Date
14000000110002012VE INV.06-06-201206-06-201206-06-2012
14000000210002012VE INV.15-04-201215-04-201218-04-2012
14000000310002012VE INV.25-01-2013 31-12-201228-01-2013

Picture 1 – Date examples based on SAP® table BKPF


If you look at our (made-up) examples, the date values sometimes are equal, but sometimes different from each other.

Before we examine the differences and look at some explanations, we want to determine what the three fields are used for. Their names are:

  • Document date
  • Entry date
  • Posting date

The document date (technical fieldname BLDAT) can be explained best when we think about an invoice which was sent from a vendor via letter post. There usually is an invoice date written on that paper invoice. When entering the invoice into the system, this date can be entered as “document date”. In other words it is the date as stated on the original document.

The entry date (technical fieldname CPUDT) is the date which gets stored by the SAP® system. It is when the user clicks on the “POST” button. The system records the exact moment in time when the document gets saved to the database. By the way, this is also indicated by the fieldname of that field, it is the date created automatically by the “CPU”. You can treat it as “creation date” of a financial document.

Last but not least there is the posting date (technical field name BUDAT). This is the date which is most important for bookkeeping, as it states the date on which that value is posted per in your books. The posting date can make the difference whether a posting belongs to fiscal year 2013 or fiscal year 2014, as based on the posting date both fiscal period and fiscal year get determined.

Now that we explained the different date types, you can use this for certain analytic approaches. Are you interested where the data entry part is largely different from the date it was posted per in your books? Just compare the difference between entry date CPUDT and posting date BUDAT. Are there strange cases where there is a big time gap between the date on the paper document and document entry? Then you might want to go for the range in days between document date BLDAT and entry date CPUDT.

We listed some real-live examples in the table above.


Document numberCompany CodeFiscal YearDocument TypeDocument DatePosting DateEntry Date
1400000011000 2012VE INV.06-06-201206-06-201206-06-2012

Picture 2 – All dates do have the same value


Document 140000001: All three dates in picture 2 are on the same day. If we assume that no data entry error was made, it means that there is a vendor invoice issued on 6th of June and entered on the very same day. This could happen of course if the invoice was sent digitally or if there is an EDI (Electronic Data Interchange) interface to that vendor.


Document numberCompany CodeFiscal YearDocument TypeDocument DatePosting DateEntry Date
14000000210002012VE INV.15-04-201215-04-201218-04-2012

Picture 3 – This example looks like expected in a standard P2P process


Document 140000002: The document above (see picture 3) seems to represent a standard case. The vendor invoice is dated per 15th of April. It got entered on 18th (so 3 days later) in the system, which may be perfectly OK, as if it was sent by letter mail, it takes some time until it arrives at the accounting department. As posting date the data entry person used the 15th of April again. This seems to be quite fair, as maybe the posting date indicates the payment term baseline date as well, so the three days it took the invoice to reach the right place and get into the system are not delaying the payment of the vendor. (I want to point out here that the payment terms in context on baseline date is a topic which is worth a separate blog post, so here we only used one simple example).


Document numberCompany CodeFiscal YearDocument TypeDocument DatePosting DateEntry Date
14000000310002012VE INV.25-01-201331-12-201228-01-2013

Picture 4 – The third example covers shows almost 3 months in between document date and entry


Document 140000003: In picture 4 we have to deal with quite an unusual scenario. The vendors invoice is dated per 25th of January 2013; it was put into the SAP® system three days later, on 28th of January. However the posting date is 31st of January of the previous year. This might be a case where something was forgotten or costs needed to be slipped into the previous fiscal year. With posting date being 31st of December 2012, it got financially relevant in the previous fiscal year. (Of course this would have required to have that SAP®posting period still open – or re-opened – for posting things into a previous period.)

In real-life, data analysts will encounter lots of different scenarios, and a lot of different approaches to explain those. When following up those scenarios, an digital archive can be very helpful, best-case directly integrated into SAP®: All original documents can then be viewed easily by the click of a button, and the values there are easy to compare with the data in the system.

This was just a first glimpse on “date fields” in SAP®. Content wise there is a lot more to this topic: There is the baseline date for payment terms (technical name ZFBDT), the change date on which a payment block was removed and the invoice had been released (recorded in the change tables CDHDR and CPDOS), there is the clearing date on which a financial document was cleared (AUGDT), but these elements (and the business processes they are involved in) are worth a separate post. It is still early 2014 when it comes to blog postings, so stay tuned.

By the way date fields can be analyzed easily with ACL™. My colleague Ilona already wrote an article about that, which can be found here. You may recognize some of the field names (BUDAT, CPUDT) there. Please do not forget when analyzing date differences, that the document date can be entered manually. So it can be entered differently (on purpose or by accident). Your data analytics will be as good as the quality of the data is that got entered to the system.

I hope you found that introduction into the “SAP® date fields” interesting. For any comments on that article, feel free to write us at info@dab-gmbh.de.

To contact the author you can also use LinkedIn or XING (you may have to login first before you can access these links).

LinkedIn: http://de.linkedin.com/pub/stefan-wenig/54/1b8/b30

XING: https://www.xing.com/profile/Stefan_Wenig2?sc_o=mxb_p

Comments (0)
Be the first who comments this blog entry.
Blog login

You are not logged in. Please log in to comment this blog entry.

go to Login