In this blog post, I would like to show you how to uncover duplicate payments in SAP. You will encounter many “False Positives” while searching for duplicate payments. Identifying and excluding as many “False Positives” as possible to get to the real duplicate payments is a high art. Finding duplicate payments is more like looking for a needle in a haystack.
Part II of the series: “Uncovering duplicate payments”
1. Cashback: How the audit department pays off with duplicate payments
2. 3 steps for detecting duplicate payments in SAP
3. Duplicate Payments: Reducing False Positives using a Utility Analysis
4. How to prevent Duplicate Payments with the Internal Control System
How to identify duplicate payments?
Twice payed invoices can probably never be identified with clear reliability. But you can look for indications that portend duplicate payments. If a document cumulates the following indications, a twice payed invoice is likely to exist. Such indications can be:
- Same amount on different documents and
- Same posting date and
- Same document date and
- Same document type and
- Same accounting account and
- Same vendor and
- Same external invoice number.
Of course, even if there are many matches, there is no guarantee to find a duplicate payment in SAP. However, experience shows that investigating relevant documents and focusing on high invoice amounts stands a good chance to quickly finding a few thousand euros!
How to perform duplicate payment analytics in SAP?
If you want to analyze duplicate payments in your SAP, you need the necessary data structure and data from your SAP system. By using our software zap Audit, the data is downloaded automatically from your SAP system.
Step 1: Finding documents with same amount
First, I advise you to match every document line of incoming invoices that show the same amount. The basis will be made of document pairs (SAP table BKPF, field BELNR), where individual posting lines (table BSEG, field BUZEI) show the same amount (field DMBTR). The posting lines are filtered by account type: vendor (field KOART=”K”) that indicate a payment (field XZAHL=”X”) on debit (field SHKZG=”S”). Thus, you get the posting lines that balanced a liability with a payment.
The result may look as follows:
MANDT | BUKRS | GJAHR | BELNR1 | BUZEI1 | BELNR2 | BUZEI2 | DMBTR |
---|---|---|---|---|---|---|---|
902 | 1000 | 1997 | 1500003696 | 4 | 1700000071 | 1 | 17895.22 |
902 | 1000 | 1997 | 1700000071 | 1 | 1500003696 | 4 | 17895.22 |
902 | 1000 | 1997 | 2000000281 | 2 | 2000000299 | 2 | 6467.84 |
902 | 1000 | 1997 | 2000000299 | 2 | 2000000281 | 2 | 6467.84 |
902 | 1000 | 1997 | 2000000275 | 2 | 2000000289 | 2 | 5556.46 |
902 | 1000 | 1997 | 2000000289 | 2 | 2000000275 | 2 | 5556.46 |
902 | 1000 | 1997 | 2000000198 | 2 | 2000000213 | 5 | 3527.91 |
… | … | … | … | … | … | … | … |
Every row contains two different documents (BELNR1 and BELNR2) with the corresponding posting lines (BUZEI1 and BUZEI2) having the same amount (DMBTR). The results are showing ;the same amounts twice. The reason behind is, that the same document is being listed once on the left and once on the right of the document pair.
You can easily detect such duplicate amounts with a SQL statement. In my whitepaper, you will learn how to identify the 10 biggest same amounts and relating documents by simply using SQL:
These analytics provide a variety of false positives. We, at zapliance, have the goal to design your SAP audit more efficiently. Therefore, we have improved these analytics to reduce false positives and integrated them in the software.
Step 2: Adding indications for duplicate payments
In our next step, we will add indications to the identified document pairs from step 1.
In the following we are using:
- same posting date
- same document date
- same document type
- same accounting account
- same vendor
- same external invoice number
The result may look as follows:
BELNR1 | BUZEI1 | BELNR2 | BUZEI2 | DMBTR | Document type | Posting date | Document date | Vendor | Account | External document number |
---|---|---|---|---|---|---|---|---|---|---|
same | same | same | same | same | same | |||||
1700000071 | 1 | 1500003696 | 4 | 17895.22 | X | X | X | X | X | |
1500003696 | 4 | 1700000071 | 1 | 17895.22 | X | X | X | X | X | |
2000000281 | 2 | 2000000299 | 2 | 6467.84 | X | X | X | |||
2000000299 | 2 | 2000000281 | 2 | 6467.84 | X | X | X | |||
2000000275 | 2 | 2000000289 | 2 | 5556.46 | X | X | X | |||
2000000289 | 2 | 2000000275 | 2 | 5556.46 | X | X | X | |||
2000000213 | 5 | 2000000198 | 2 | 3527.91 | X | X | X | |||
2000000198 | 2 | 2000000213 | 5 | 3527.91 | X | X | X |
By creating such a table, you get a clear overview of the mentioned data fields that are the same beyond the amount. For example, the documents 1700000071 and 1500003696 from the first line seem to be especially interesting, because many data fields are the same and the amount is high, too! It’s worth looking further at this document pair!
Step 3: Consulting the frequency of duplicate payments
Another step you may consider is to further consult the frequency of listed duplicate payments and include it in your analytics. For example, specific amount could appear frequently because of typical business processes. Such amounts would be declared as: “nothing special”. In your SAP system, you can find out how frequently item amounts appear in different documents by using the following SQL statement:
SELECT DMBTR,COUNT(DISTINCT BELNR) FROM BSEG WHERE DMBTR>0 GROUP BY DMBTR HAVING COUNT (DISTINCT BELNR)>1 ORDER BY COUNT(DISTINCT BELNR) DESC
The result may look as follows:
DMBTR | COUNT(DISTINCT BELNR) |
---|---|
0.01 | 856 |
235.19 | 63 |
204.52 | 60 |
529.19 | 57 |
51.13 | 54 |
511.29 | 48 |
46.02 | 48 |
613.55 | 45 |
40.90 | 42 |
184.07 | 42 |
3233.92 | 40 |
122.71 | 39 |
30.68 | 39 |
255.65 | 39 |
153.39 | 34 |
… |
It is clearly visible that an amount of 0.01 is by far the most frequent. This is for example a difference, which is uninteresting because of its low value. Looking at the following entries in the table you should ask yourself, whether the amount could be qualified as a “standard amount” in the context of “standard processes”, or not. Otherwise they should be considered as duplicate payments. I recommend investigating rarely appearing high amounts.
In the next blog posts about “Uncovering Duplicate Payments”, you will find out on how to reduce the amount of “false positives” with the help of a Utility Analysis.