After analyzing all vendors with bad or unsuccessful payment terms in the last blog post, we now want to gain a deeper insight into the various respective terms of payment.
Part III of the series: "Payment terms in vendor master data"
1. Are you failing to benefit from cash discounts due to poorly maintained payment terms in SAP?
2. How to analyze bad payment terms in SAP in two steps
3. Revised terms of payment: How to clean up your vendor master data
4. How to analyze your own payment behavior in SAP
We will answer the following questions in this post:
- Are there payment terms with equal characteristics which are thus redundant?
- How often are payment terms used which don’t make sense?
- How often are payment terms missing?
True to the proverb "All roads lead to Rome", I would like to point to one way of arriving at the answers to the questions asked in each case.
Which payment terms are eqaul?
Before we start to analyze equal payment terms, we first need to consider what we really we mean when we say terms of payment are equal, and in which SAP table the corresponding fields can be found. In addition, we will consider the terms of payment for just one company code and not conduct a cross-departmental audit, since this can give rise to quite a different set of questions, which we may discuss separately in a later blog post.
Payment terms are considered to be equal in SAP when we have the same characteristics for the following fields in table T052 (terms of payment):
Technical name |
Field name |
ZTAG1 |
Days from Baseline Date for Payment |
ZPRZ1 |
Cash Discount Percentage Rate |
ZTAG2 |
Days from Baseline Date for Payment |
ZPRZ2 |
Cash Discount Percentage Rate |
ZTAG3 |
Days from Baseline Date for Payment |
Table 1: Fieldnames of table T052
Table 1 shows the field names and their technical names according to the display in the SAP logonpad. In the payment terms, up to three payment periods can be specified. The first two (ZTAG1 & ZTAG2) show you for up to how many days after payment period a cash discount (ZPRZ1 & ZPRZ2) is granted. From x days after the payment period (ZTAG3), the net price is then due.
There are, of course, other fields in SAP where the conditions can be different, such as, for example, the possibility of payment by installment. This is not something we are going to cover in this post. In the next step, you have the option of choosing between two procedures. Do you want to view all payment terms, or just the ones that are currently being used? Since, in the second question, we are going to deal with the terms that are not used at all or only very rarely, we will first examine all those which are currently being used. To do this, we need to take a look at table LFB1 (vendor master (company code)).
Using SAP transaction "SE16N", we can get a quick insight into the payment terms used. Specifying the table LFB1 and restricting the company code to, say, 1000, as well as by unselecting all irrelevant field names for this analysis, we get a nice overview for each vendor.
The list can be transferred to Excel via "Export - Spreadsheet" so that we do not have to evaluate the huge list of results individually. Upon opening the exported file, we can quickly and easily create a PivotTable (Insert - PivotTable) and take a look at the frequencies. To do this, we simply choose payment terms both as "lines" and as "values" of the PivotTable. We now already have an overview with the frequencies as follows:
Now leave the Excel file open and go back to SAP.
How do we now examine the impact of the terms of payment?
After we have checked which payment terms are actually being used, the impacts of the fields from Table 1 must be compared. To do this, we navigate back to SAP, call up the transaction "SE16N" (General table display) again, and enter the table T052 (Payment Terms) that we have already mentioned previously above. Now we must take all payment conditions from the overview with the frequencies displayed in the table and enter them in another Excel sheet. The result will look something like this:
MANDT |
BUKRS |
ZTERM |
ZPRZ1 |
ZPRZ2 |
ZTAG1 |
ZTAG2 |
ZTAG3 |
Frequencies |
902 |
1000 |
ZB01 |
3.00% |
2.00% |
14 |
30 |
45 |
438 |
902 |
1000 |
184 |
||||||
902 |
1000 |
0001 |
4.00% |
2.00% |
116 |
|||
902 |
1000 |
ZB05 |
0.00% |
0.000 |
0 |
0 |
0 |
92 |
902 |
1000 |
ZB00 |
3.00% |
2.00% |
14 |
30 |
45 |
82 |
902 |
1000 |
0002 |
0.00% |
0.000 |
0 |
0 |
0 |
80 |
902 |
1000 |
ZB50 |
2.00% |
1.50% |
14 |
30 |
45 |
7 |
902 |
1000 |
NT30 |
2.00% |
0.00% |
20 |
30 |
0 |
5 |
902 |
1000 |
ZB02 |
2.00% |
0.00% |
10 |
30 |
0 |
4 |
902 |
1000 |
ZB10 |
4.00% |
2.00% |
15 |
30 |
0 |
3 |
902 |
1000 |
ZB03 |
0.00% |
0.00% |
20 |
30 |
0 |
2 |
902 |
1000 |
0004 |
3.00% |
2.00% |
14 |
30 |
45 |
1 |
Table 2: Overview of Payment Terms
This gives us an overview of the payment terms used and now allows us to identify payment terms with equal impact either by using the filter function of Excel, or by simply looking at the data. Accordingly, we can, for example, see that ZTERM: "ZB00" and "0004", as well as "ZB05" and "0002" are equal, and that "0004" has been used only once. I’ll leave it entirely up to your professional judgment to decide whether the terms of payment have changed, or if there might be a valid reason for the duplications, and the associated action to be taken as a result.
How often are payment terms used which don't make sense?
Based on the good groundwork we have put in so far, this question can be answered relatively quickly. Simply by looking at Table 2, it become very clear which terms of payment make no sense. For example, the condition (ZTERM) "ZB03", which does not provide for a cash discount but is defined as "days from payment period" and then used twice. Simply use your common sense and go through the list of payment terms. Check which combinations make little or no sense and adopt a critical attitude. Once again, the following principle applies: incomplete or missing payment conditions have a direct impact on profit and loss!
How often are payment terms missing?
This question can be answered relatively simply because we have in fact already analyzed it. In the third line of the last table, almost all the fields are empty. If the field name ZTERM is empty or "null", then no payment conditions are stored in this case.
In addition, there is the option of outputting all vendors with no payment terms maintained. To do this, we call the popular SAP transaction "SE16N" and enter the table LFB1. Before calling up the report, choose a value of, say, 1,000 in the "company code" field and set the "Payment terms" option to "Select: Equal". Leave From value and To value empty. By pressing F8 or "Online", we now obtain a list of all vendors with no payment terms maintained.
At this point, I once again leave it to your professional judgment as to how you handle the results. Should the master data be adapted, or is there a meaningful explanation for the empty fields? This is definitely something you should check, as your company may be failing to make use of potential discounts as a result.
What other questions are relevant in this context?
In addition to the questions outlined above, there are, of course, many others which it is useful to ask oneself and answer in this context. For example:
- Are there terms of payment that are rarely used and that can perhaps be adapted to the contractual standard?
- Are there other conditions for the same vendor beyond the boundaries of a company code?
- What are the terms on the invoice, in the contract and in SAP?
Are there any other questions which, in your opinion, it is crucial to address in this context and that we should definitely take another look at? If so, please leave a comment below!
Can I save myself all the manual work involved?
Of course, you can. Simply download zap Audit and take advantage of a total of more than 125 indicators. The method for analyzing missing or incomplete payment terms is already integrated into zap Audit, so you do not need to look up document types, posting data or anything like that manually. Furthermore, our analysis is more mature, comes equipped with business intelligence methods and is being continually improved. This allows you to be effective in reducing false positives while leaving it to zap Audit automate everything that can be automated. So use your valuable time to audit what needs to be audited. What are you waiting for? Start your zap Audit project today:
This is a very extensive topic and one that can have a direct impact on P & L. For this reason, we will take a look at your payment behavior in the next blog post and see how we can identify outliers, in addition to lost opportunities to obtain discounts.