“How can we reduce the amount of results of twice payed invoices?” was a question in the preparation of this blog post. In collaboration with the Professor and my vague recollection of past business administration lectures, we opted for a utility analysis. Therefore, the combination of Professional Judgement and hard facts of data analytics should become a part of this article.
Part III 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 in SAP: Reducing False Positives using a Utility Analysis
4. How to prevent Duplicate Payments in SAP with the Internal Control System
Why conduct a utility analysis for potential SAP duplicate payments?
“The term utility analysis (UA) can have a host of different meanings depending on the field of study. In general, it refers to processes that predict the usefulness (utility) of decision options. “
Source: Michael C. Sturman Ph.D
In our case, the problem is characterized as the twice payed invoice in SAP. As each company has its own processes, your Professional Judgement is required, to successfully implement a utility analysis. Nobody knows the company you are working in better than you do! Therefore, your expertise is needed at this point. I would like to show you an example of how a utility analysis looks like, which purpose it fulfils and to which extent it may or may not be used.
What is the objective of a utility analysis?
I am using the utility analysis to prioritize the identified amounts from the 2nd post of this series. At the end of this post, you will receive a list, ranking the probability for a potential duplicate payment from highest to lowest.
Enough theory for now – Let’s get started!
For the implementation of the utility analysis, I will use parts of the results from the instruction introduced in the last series. You can download it here:
After you have downloaded the instruction and used the SQL statement, we can start. By using the SQL Statement, you will obtain 10 document pairs showing the same amount. However, you do not need each field of the results for the implementation of the utility analysis. According to the 10 document pairs, you begin by creating an overview of the document pairs. It does not matter, if a document is number 1 or number 2. You should only eliminate duplicate entries, showing the same amount and having the same documents once in cell BELNR1 and once in cell BELNR2. My table looks as follows:
| Case | BELNR1 | BELNR2 | Same amount |
| 1 | 2000000185 | 2000000151 | 770195,23€ |
| 2 | 2000000188 | 2000000154 | 575964,94€ |
| 3 | 2000000190 | 2000000156 | 448569,57€ |
| 4 | 2000000186 | 2000000152 | 316526,42€ |
| 5 | 2000000155 | 2000000189 | 216692,30€ |
| 6 | 1500000002 | 100008630 | 32000€ |
| 7 | 100008654 | 100008630 | 32000€ |
| 8 | 1500000000 | 100008654 | 32000€ |
| 9 | 100008630 | 100008654 | 32000€ |
| 10 | 100008654 | 1500000002 | 32000€ |
After identifying the 10 highest duplicate amounts, stay calm in your seat. The duplicate amounts do not already represent twice payed invoices. For the time being, only a reasonable suspicion exists. In the following we will enrich the cases with the help of the utility analysis.
The approach, or how to reach the target
After defining the target, the analyses basically consist of the three following steps:
- Selection of criteria
- Weighting of the criteria
- Evaluation of alternatives
Before thinking about the weighting of the criteria, you must select criteria first. For this purpose, you may use our criteria from the last blog post:
- 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.
The same amount on different documents represents a sufficient condition – without duplicate amounts no duplicate payment! Therefore, we will not consider the same amount as criteria and only use the six remaining criteria.
In the next step, you build the utility analysis based on the six criteria and allocate the weighting in percentage. You can also select points, but you will need to watch the scale. I chose percentage, where 100% imply the accordance of all the criteria. A little tip at this point: Do not use more than 5 to 7 criteria, because the weighting will be too small and under these circumstances important criteria might not receive the adequate significance or even exert to much influence. In my case, I built the following scale and would like to explain it to you:
| Criteria | Weighting |
| same posting date | 10% |
| same document date | 15% |
| same document type | 15% |
| same accounting account | 15% |
| same vendor | 25% |
| same external invoice number | 20% |
These values are not randomly selected, but originate from certain preliminary considerations. This is where you come into play: trust your own Professional Judgement and engage into preliminary considerations. Here are some interesting questions that I would like to share with you (incomplete list):
- Is it possible to post on different days because of the personnel situation?
- Did your employees receive any trainings in the past year?
- What is the maturity level of your internal control system?
Think about scenarios that could influence the weighting.
In my case, the criterion with the highest weighting is the same vendor, followed by the external invoice number. From my point of view, this combination seems to be the most likely, because of the current staffing in the department.
Why?:
Because in my virtual company, two people are working in the accounts payable department. One of them is a part-time employee, working from Monday till Wednesday. The second employee is a full-time employee. Resulting from this constellation, it could be possible that an invoice is being posted by mistake once by the full-time employee on Thursdays. Afterwards, it ends up on the desk of the part-time employee by mistake and is posted again on Mondays. Because of this, the same posting date (10%) is less relevant to me than the document date (15%). Resulting from this constellation, the vendor and the external invoice number ideally match. A perfect scenario for a duplicate payment, don’t you think?
The valuation standard is constructed easily, as you only differentiate between specified (yes) and not specified (no). At this point, the advantages of data analyses come into play (e.g. BELNR1 and BELNR2 have the same document type (yes) or not (no)). There is no “maybe” at this point. In the next step, you should look up all the criteria in your SAP system and put them into a second table. You can do this by calling the SAP transaction “SE16n” or simply “SE16”. The information needed can be found in the table “BSEG“. Consequently, you receive a certain black-and-white picture from the data analyses in your SAP system.
As soon as you have identified all the criteria in your SAP system, you can produce the following table, which also includes the weighting:
| Case | |||||||||||
| Weighting | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |
| same posting date | 10% | Yes | Yes | No | No | No | Yes | Yes | No | Yes | Yes |
| same document date | 15% | Yes | Yes | No | No | No | No | Yes | No | Yes | No |
| same document type | 15% | No | Yes | Yes | No | Yes | Yes | No | Yes | No | Yes |
| same document type | 15% | No | No | Yes | No | No | No | No | Yes | No | Yes |
| same vendor | 25% | No | No | Yes | Yes | No | No | Yes | Yes | No | Yes |
| same external invoice number | 20% | Yes | Yes | No | Yes | No | No | No | Yes | Yes | No |
To finally calculate the probability of a potential twice payed invoice, simply add all the weightings of the criteria that have the specification (yes).
For the first case, the calculation of the probability looks as follows:
posting date (10%) + document date (15%) + invoice number (20%) = 45%
Calculating the probabilities for every case:
| Case | Probability |
| 1 | 45% |
| 2 | 60% |
| 3 | 55% |
| 4 | 45% |
| 5 | 15% |
| 6 | 25% |
| 7 | 50% |
| 8 | 75% |
| 9 | 45% |
| 10 | 65% |
Especially case 8 strikes our eye, as it indicates the highest probability with 75% for a potential duplicate payment. Case 10 (65%) and case 2 (60%) are following closely. Now we only need to put the results in a certain order. Starting with the highest probability and ending with the lowest. Start further investigations at case 8, followed by case 10 and case 2.
Would you have chosen this order before?
Yes?
Then you should consider playing lottery.
Please note: Identifying a case with a probability of 100% does not mean, that you found a duplicate payment in your SAP system. It is to be understood as a strong indication of a potential twice payed invoice.
We already integrated an optimized duplicate payment analysis in zapliance, so that you don’t need to check document types or posting dates yourself anymore. Furthermore, our analyses are even more sophisticated, supplied with Business Intelligence methods and are constantly being improved. Let zapliance automate everything that can be automated and use your valuable time to audit what must be audited. Because nobody likes to deal with False Positives, right?
If you have any questions / suggestions / ideas, or already did duplicate payment analytics by yourself, please contact us here.
In the next series, you will learn how to use the internal control system of SAP to investigate parts of the chosen criteria. By using the internal control system, you can partially prevent duplicate payments in the origin. In addition, I will provide you with a step-by-step instruction for your SAP customizing settings to prevent duplicate payments from occurring.
