About ap­ples and or­anges: Per­form and in­ter­pret pay­ment term anal­y­ses

One of the conclusions of the last blog post was that vendor master data is maintained on different levels in SAP® which are independent from each other. There are master data elements on level of procurement as well as on level of accounting.

Two analytic questions customers regularly ask us to solve are

1. Finding out where payment terms are missing / not maintained
2. Finding out where differences exist for the same vendor

I will discuss what should be considered from my point of view when tackling those objectives. There are points which should be considered when doing the analytic work, and points which should be taken into account when interpreting the results.

From a technical point of view, the vendor master data in SAP® for procurement and for accounting are stored in separate tables, LFM1 is the table name for the vendor master data table in procurement, LFB1 is the table name for the one in accounting. Those tables do not only contain payment terms, in fact all procurement or accounting specific master data can be found there (e.g. incoterms for procurement, or the reconciliation account for accounting). If you have a close look at the screenshots used in this article, you will recognize that as well.

In the following picture both master data tables are put next to each other, on the left-hand side table LFM1 for vendor master data for “Procurement”, on the right-hand side table LFB1 for vendor master data on “Accounting” level. The data is filtered for purchasing organization 1000 (left) and company code 1000 (right):

1. Mis­sing mas­ter da­ta – Ex­am­ple sce­nar­ios

Identifying missing payment terms does not seem to be difficult. A first, easy approach would be to test where the field “Payment term” is empty in the corresponding table, or where a vendor is not listed in one of the tables at all. In our example screenshot, we quickly notice missing payment terms in both tables, for procurement as well as for accounting. For the vendors 0000000012 to 0000000014 neither procurement nor accounting payment terms are maintained:

Another scenario could be that payment terms are missing for only one of the two different levels. If you had a close look before you might already have noticed this. Here is a more detailed screenshot, showing vendor 0000001012 who has a payment term for procurement, but not for accounting:

However, as I already pointed out in my last blog post about that topic, this might not be critical for vendors, who only have invoices related to a purchase order. In such cases, whenever an invoice is entered related to a purchase order for example with SAP® T-Code MIRO, SAP® will use the payment terms which are stated in the PO – and these have been pulled from the vendors procurement master data in the first place when creating the purchase order with transaction ME21n for example. In such a scenario it does not even matter having no accounting payment terms in table LFB1.

Lastly, I would like to point out that not only empty fields should be considered when analyzing missing payment terms. There might be cases, where no purchasing (or accounting) master data is maintained for a vendor at all. In such cases, you will not find an entry for that vendor numbers in the corresponding table at all. Vendor number 0000000008 is a good example, as shown in the next screenshot. That vendor has an entry in the accounting master data table, but not in the procurement master data table:

2. a) Pay­ment term dif­fer­ences with­in pro­cure­ment or ac­count­ing – Ex­am­ple sce­nar­ios

After having a closer look at different aspects of missing payment terms, we now will discuss scenarios where vendors do have several payment terms on different levels which differ from each other. Even within one level, for example for accounting, different payment terms for the very same vendor can be maintained. Vendor accounting master data in SAP® is differentiated by company code, and each company code can have a different payment term for the very same vendor. Let`s have a look at vendor 0000000111 in the next picture. He has two entries in table LFB1, with different payment terms: One for company code 1000, and another one for company code 3000:

However, this might not be a critical finding or inconsistency. Sometimes it makes perfect sense to have differences, as maybe a vendor who deals with company code “Germany” will have other payment terms compared to the business he is doing with company code “United States”. In Germany for example, Cash Discount (Early payment discounts) are quite common – in the United States or even other European Countries this is not so common at all. Therefore it makes sense to be able to differentiate the payment terms for one vendor depending on the company code the invoices are posted for.

The same applies for the vendor master data in procurement. For one vendor, multiple payment terms can exist in procurement as well, differentiated by the purchasing organization.

This makes sense as well, as a purchase organization which is responsible e.g. for the United Stated might exist, and another one which is responsible e.g. for the procurement for Germany. But not only regional differences are a potential reason. It could be, that different purchase organizations exist, being responsible for different types of goods, one for “Services”, another one for “Material”. Depending what is bought, different payment terms may apply. Or there might be a purchasing organization which is responsible for big contracts on global level. Maybe that purchase org negotiated a high-volume material contract with a certain supplier – for that big deal, the supplier had to accept very strict payment terms. If regional purchase organizations however by other materials in small amounts which are not covered by the contract, a different, more generous payment term may apply.

The next screen shows vendor number 0000000111 who has two different payment terms in place, but this time this is the procurement level, one for purchase organization 1000, one for purchase organization 3000. If this is an inconsistency, or if it actually makes sense or is necessary based on the scenarios explained will need to be audited then, case by case:

2. b) Pay­ment term dif­fer­ences be­tween pro­cure­ment or ac­count­ing – Ex­am­ple sce­nar­ios

The differences we looked at so far were happening within each level, so different payment terms for the same vendor in accounting, or for the same vendor in procurement. Of course there are situations, where the payment terms between procurement and accounting are differing.

Differences could have a negative monetary impact, if some invoices are posted with reference to a purchase order (with SAP® transaction MIRO for example), and others are not posted with reference to a PO (e.g. with SAP® T-Code FB01) .

Let’s assume, the purchasing organization did a good job and after a tough negotiation phase the vendor agreed to “We pay within 90 days and can still deduct 2% early payment discount”. However there is an inconsistency, and the accounting payment term is “14 days net”. This means, if invoices are posted directly in SAP® FI Accounts Payable and – for what reason ever – are not referring to a purchase order, that (from our point of view bad) payment term would be used, which usually is not intended.

To identify such vendors, we should generate a list of vendors, where the payment term(s) in procurement differ(s) from those in accounting. The next picture shows a comparison between procurement and accounting payment terms for vendor 0000000111:

For procurement, the payment terms ZB03 and ZB01 are set up for that vendor 0000000111, in accounting the payment terms are labelled ZB02 and ZB50. So obviously we do have differences, but which ones should actually be compared, which ones should match?

To approach this task, we should have a closer look at the way an enterprise and it`s organization units can be structured in SAP®: A purchase organization can be assigned to a company code in SAP® customizing. Or the purchase organization can be assigned across several different plants – and plants are assigned to company codes, so assigning a purchase organization to one or more plants would indirectly lead to an assignment of one or more company codes. This assignment is done in SAP® in the Customizing, which can be done by SAP® transaction SPRO:

Having this in mind, it only makes sense to compare payment terms between purchasing organizations and those company codes which are assigned directly to that purchase organization or indirectly via the plants. The next screenshot shows the assignment of purchase organization to company code. Purchase organization 1000 is assigned to company code 1000, and purchase org 3000 to company code 3000 (the fact that the numbers are matching is a training system coincidence only). This means, in a first phase from my point of view it only makes sense to compare payment term ZB02 vs. ZB03 (for the 1000/1000), and ZB01 vs. ZB50 (for the 3000/3000):