Author: Stefan Wenig
connect on xing
connect on LinkedIn
When looking at the Cash Flow, doing liquidity planning or analyzing master data quality, payment terms are an important topic. They determine whether and how much early payment cash discount can be deducted from the original invoice amount, and what the final due date of an invoice will be. Understanding which payment terms are set up in the system and analyzing those is one of the key business tasks.
In this article I will highlight the vendor payment terms logic in SAP® by explaining some master data basics, which are important when it comes to data analytics in this area. It will be shown that different payment terms can be stored for the very same vendor on different master data levels, and explained under which circ*mstances either one or the other will be used.
Let’s have a look at one concrete example: To display vendor master data, the SAP® transaction “XK03” (Display vendor centrally) can be used. I will start looking at vendor number 1000. As additional parameters I enter the organizational units “Company Code” and “Purchasing Organization”. On the training system, both units have the same number (“1000”), but this is just a training system coincidence – in real life, all three parameters could (and probably will) of course differ from each other.
After confirming the parameters by pressing the enter key we can browse through several single screens (views) of the vendor master data. On screen “Payment transactions accounting” we encounter the payment term for this vendor for the first time, it is payment transaction „ZB01“.
So far, everything seems to be ok. When continuing browsing through the screens, we encounter the payment term “ZB01” a second time – this time on screen “Purchasing data”. It looks like a redundancy, as we noticed the same value two or three screens before already.
However it is not a redundancy. This is the first fact I want to point out: In SAP®, payment terms can be stored on different master data levels, in our example on level of procurement (so for this vendor in context of the purchasing organization we entered before), as well as on level of accounting (for this vendor in context of the company code we entered). The fact that both of the payment terms we just have seen are equal, is just a coincidence – they could as well differ from each other, as in fact these are two different elements, just containing the same value in our first example. The next example for vendor number 111, company code 1000 and purchasing organization 1000 shows a different scenario:
The payment term for vendor 111 in accounting for company code 1000 is „ZB02“. However, moving on to the purchasing view, a different payment term with the value “ZB03” is set:
Why do we need to have different master data levels where payment terms can be stored at all? To understand (one of) the reason(s), let’s have a look at how the business process looks like: If both SAP® modules SAP® MM-PUR (Procurement) and SAP® FI-AP (Accounts Payable) are used, a typical process would start with a purchase requisition and purchase order, and later on a goods- and invoice receipt will be recorded for that purchase order.
And this is why payment terms are stored on level of procurement (per vendor and purchasing organization): If for example a purchase order gets entered by using SAP ® T-Code ME21 for vendor number 111 and purchasing organization 1000, payment term “ZB03” will be applied (and usually be passed on in the next process steps automatically) towards the SAP® FI-AP Accounts Payable module. This is indicated by the green process step boxes in the picture above.
However it is possible to enter invoices directly within the SAP® FI-AP module without referencing a purchase order, for example by using SAP® T-Code FB01. Doing this there is no option to enter a purchase organization, so the payment term on purchasing level cannot be determined, as it requires vendor number and purchase organization. But as we have payment terms stored on accounting level as well (which means, per vendor and company code) in this case payment term “ZB02” will be applied.
Let me summarize the highlights:
- For one vendor, different payment terms can be stored on different levels in SAP®.
- These can differ from each other, so the payment term for that vendor in procurement not necessarily equals to the payment term in accounting.
- Depending on where the process starts (where the first transaction will happen, e.g. in SAP® Procurement or in SAP® Financials) one or the other will be pulled
But how can we proceed with data analytics to compare the different levels, finding out about differences, and what do we need to consider when doing so? This is what my next blogpost about payment terms will be all about.
For any comments on this article, feel free to write us at info(at)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
