Pay­ment terms - don't judge a book by its cover

This blog post marks the end of the series on terms of payment in SAP®. In two preceding instalments I showed how terms of payment exist at different levels or between different SAP® modules, and explained what to observe when comparing master data.

In this article I wish to show that, when it comes to analyzing terms of payment you "don't judge a book by looking at the cover". This time we are not looking at master data but the terms of payment at the level of single transactions.

In day-to-day business in the context of auditing/revision, accounting or controlling it is often interesting which terms of payment are used, and whether corporate standards are maintained. Terms of payment have considerable influence on cash flow calculations for instance – when do financial means go out and when do they accrue again.

Terms of payment contain periods for payment and sometimes also discounts (cash, early payment) – depending on countries and regions, and the payment practices common there. In the SAP® modules terms of payment have an identification code that represents a particular interpretation of terms and/or discount percentage rates.

The following figure is an extract of terms of payment from an SAP® IDES system:



Term of payment
Days 1
Discount 1
Days 2
Discount 2
Days net
ZB01143%302%4514 days 3%, 30/2%, 45 net
ZB0700%00%0Due immediately in full
ZB10103%00%0Within 10 days 3% discount
NT30300%00%0Net 30

Figure 1 – Examples of terms of payment from SAP IDES®


You see that there are different possibilities to formulate terms of payment. There are up to three fields for the days and two discount percentage rate fields. If all day fields are filled with zeroes, that implies "Due immediately" (as in ZB07). There is also a field "Days net", but this is often only applied if the "Days 1" and "Days 2" fields and discount rates 1 and 2 are likewise filled in. The term of payment "NT30" stands for "30 days net", and since there is only one period this appears in the first column "Days 1" and not in the last "Days net".

The terms of payment are created in the customizing of SAP® (SAP® transaction code SPRO). The following Figure 2 shows clearly how a new term of payment can be created with different attributes (baseline date, type of business partner, etc), including an explanatory text.

Figure 2 – View when creating / servicing terms of payment in SAP® transaction SPRO

As we have seen in previous blog posts, the terms of payment in customer and vendor master data are saved at different levels. Of course they are also logged at document level as part of single transactions, ie they appear in the SAP® FI documents of the customer and vendor subledgers. The screenshot below in Figure 3 shows an invoice to a customer with term of payment ZB01 (meaning 14 days 3%, 30 days 2%, 45 days net).

Figure 3 – Customer invoice in SAP® FI-AR with term of payment ZB01

So we have terms of payment that can be saved as master data through customizing in SAP®. These are then applied in business transactions (such as the customer invoice above), and are also logged appropriately for each transaction. Everything is straightforward up to now.

With what we know we can now start to analyze the terms of payment at document level. Let us proceed from the simplest case: Term of payment ZB01 is to be applied in invoices for all customers. Our 146 sample invoices can be found in ACL™ Analytics software, enabling us data analysis of very different kinds with ready defined commands and without data record constraints.

Figure 4 – Sample invoices

We will have a look at the three examples which are highlighted in the screenshot. Our invoice from above is also here numbered 0100000608. If we condense our invoice documents in ACL™ by "Classify", everything looks regular. Of 146 invoices all are assigned ZB01. That looks alright, the application appears to be homogeneous according to the directive.

Figure 5 – Condensation of sample invoices by term of payment

Nevertheless there is a snag, and that is the essence of this short article: With the appropriate authorization it is possible to alter both the due date intervals or due dates themselves, and the baseline date for due date calculation. I will show this by single examples.

To be more precise, it is not only possible to select a different term of payment to ZB01 for instance, but also to alter different interpretations. Based on the first example you can alter the period for payment from 14 / 30 / 45 days to other figures, and thus decisively extend the due date. Take invoice 0100002388, which is also contained in the above list and likewise with term of payment ZB01. But looking at the details in Figure 6 you find the following:

Figure 6 – The term of payment is ZB01 but the figures are different

Despite term of payment ZB01 there are other periods and percentages – 30 days 5%, 90 days 2.5%, 180 days net! In our first example of analysis that would not have shown because the designation is ZB01. Such alterations can occur both direct when entering an invoice and at a later time, as long as the invoice is still open in the system.

A second possibility of extending periods of payment is alteration of the baseline date for payment. This determines when a period for payment commences. If the baseline date for payment is 01.01.2015 and the period for payment 10 days, payment is due on 11.01.2015 (01 January + 10 days). If you alter the baseline date for payment to 01.02.2015, suddenly payment is due on 11 February – and that without matching the actual due days.

Figure 7 illustrates such an example:

Figure 7 – The baseline date for payment was advanced by one month

This is also an invoice from our list above. It was originally booked with a date (and thus start of period for payment) of 31.07.2005; final maturity was 15.09.2005 (45 days later). But then the baseline date for payment was altered to 31.08.2005; final maturity thus advances by one month, namely to 15.10.2005. So although the individual days and percentage rates remain unaltered, the customer's period for payment has extended by 30 days.

These two examples illustrate that it is worth risking more than a fleeting glance when analyzing terms of payment. With appropriate authorization alterations could have been made that influence the final maturity of an invoice. This can already be done when entering an invoice as well as in the subsequent process as in my examples. These possibilities are the reason why you cannot only judge the contents of terms of payment by their identification code and details, but should also look at the contents of the days and discount fields as well as alterations of the baseline date for payment.

I hope you found the article interesting. We will gladly support you in your data analysis with our dab:Exporter data extraction software, the ready defined analytics in our dab:FastForwards, or ACL™ analytics software plus our services. If you make further use of information from our blog, in publications for instance, we would appreciate reference to this blog as your source.

For any comments on this 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