Do customers always pay on time?

In extreme cases, non-payments can cause companies to get into real trouble. That’s why we will be taking a closer look at this topic – one which is well known to auditors – over the course of the coming weeks. The end of the year is slowly but surely drawing near, and, for many companies, this means the close of the financial year as well. Plans for the next fiscal year are already being made in some cases, and the question of the budget available is one that comes up year after year. This brings us to the topic of receivables management as a central element of liquidity planning.

This means that an analysis of your customers’ payment behavior can quickly become a matter of greater importance. In this first blog post, we focus on the different types of documents and receivables accounts. The aim is to provide an overview of the document types and receivables accounts with simple statistics for classifying and interpreting the results. Next week, we will take a closer look at the individual customers and their average payment behavior before, in the blog post for the week after, showing how such data can be visualized with different scatterplots in Excel.

So now let’s start with the document types and receivables accounts in this blog post.

Why should the document types and receivables accounts be taken into consideration in SAP Receivables Management?

As a starting point for analyzing the payment behavior of your customers in SAP, the document types in combination with the receivables accounts provide a very good starting point for getting a initial feeling for the data at your disposal. The receivables accounts group different accounts of the subledger in SAP and reveal initial differences, for example, with regard to deliveries and services by domestic or foreign companies, or on an intercompany basis with affiliated companies. While intercompany receivables may not be a matter of special focus for most, this is a quick and easy way of revealing differences between international and domestic receivables. The result set is also pretty “small” due to the aggregation on receivables accounts. For this kind of analysis, we have created a whitepaper that explains all the necessary steps involved and contains the necessary SQL statements. This makes it quick and easy to evaluate document types and receivables accounts for receivables management. The instructions are available free of charge by clicking on the following link:

Once the first SQL statement has been executed, you will see a table that looks something like this:

How is this table read?

Here, it should be pointed out that the data shown is not a real data set, but data from a test system that is used for training purposes. For this reason, the result set is very concise, which makes it very suitable for illustrative purposes.

If you are interested in an overview, e. g. in the form of a glossary, of the relevant SAP terminology, please e-mail us at info (at) zapliance. com and we will also write a blog article on this topic.

In a zap audit project, a fiscal year and a company code are always analyzed, because this enables you to draw a clear and proper distinction. For this reason, the table always shows the same client (column MANDT), company code (column BUKRS) and fiscal year (column GJAHR) for the current data record (not displayed in this blog post). Depending on how the data is accessed, these fields may differ in your analysis. The two columns below show the document types mentioned above. On the one hand, in the known short form (column BLART), which can be found almost everywhere in SAP FI, and on the other hand, with the name of the document type (column BLART_NAME). This is followed by the account number of the General Ledger Account (column HKONT) and the G/L account in long text (column HKONT_NAME). Optionally, zap Audit can also be used to audit all fiscal years.

The first statistics, which can be directly implemented by means of SQL, then begin in the 8th column. In addition to counting the individual receivables documents (column DOCUMENTS), there are also columns for the average difference (column AVG) and both the minimum (column MIN), as well as the maximum difference (column MAX) in days between the baseline date for due date calculation (date of invoice creation – ZFBDT) and the clearing date (AUGDT). However, you must differentiate between the clearing date. As a rule, the clearing of an open invoice takes place automatically when the payment is received. However, there are cases in which payments cannot be assigned appropriately and land first on a clearing account. Only after a manual check is the payment then assigned to an invoice, so that the date of the payment and the settlement date may differ considerably. Before you confront your customers with this anomaly, you should first check internally when a payment was received by the company.

What does the table tell us in detail and what audit approaches does it provide?

Keeping your eyes open is the order of the day. Use your auditor’s sense to critically assess the table. Intuitively, in this example, half of the lines (lines 1, 2, 6 and 8) look particularly conspicuous. The minimums of “-19” and “-104” days between the baseline date of the due date calculation and the settlement date are particularly noticeable. This would mean that a customer has already paid 19 days before it in theory received an invoice. In addition, there is a very large fluctuation between the two dates in all other lines mentioned. In our case, it may be due to the underlying data. Such a scenario should however cause you to sit up and pay attention and look into the reasons for such incidents. A difference of more than 90-120 days is usually conspicuous and should be checked, though this of course depends to some degree on your company and business.

Can claims also be displayed above a certain limit?

Let’s assume that your company has defined fixed guidelines for the settlement of receivables (= payment targets), as is the case in a large number of companies. For example, a customer should have paid within 30 days at the latest, otherwise the receivable is transferred to the dunning system and the customer is dunned accordingly. In this case, we have specified a second SQL statement in the manual, which sorts all requests into clusters and shows the distribution.

Of course, these can be changed individually at the corresponding points in the SQL statement. The defined clusters make the results table for the statement even clearer:

In addition to the columns already familiar to us from the last table, the following clusters have been added:

Clearing before base date for due date calculation (column LESS_THAN_0)

Clearing within 30 days of the due date calculation (column BETWEEN_0_30)

Clearing between 31 and 60 days after the baseline date for due date calculation (column BETWEEN_31_60)

Clearing between 61 and 90 days after the baseline date for due date calculation (column BETWEEN_61_90)

Clearing between 91 and 180 days after the baseline date for due date calculation (column BETWEEN_91_180)

Clearing after at least 181 days after the baseline date for due date calculation (column MORE_THAN_180)

Assuming that the defined guideline in your company is set to the 30 days mentioned above, the question arises as to whether the defined dunning process was also adhered to in the cases concerned, or whether there were any exceptions to the dunning procedure.

Now it’s over to you! We hope you enjoy the tutorial: