We are all familiar with it, and most probably all of you use it, but perhaps only some of you have ever asked yourself the question: How do you audit it? What we are talking about is nothing less than the payment program in SAP. In this article, we explain the issues involved and how you, as an auditor, can best approach the matter.
The Basics of the Payment Program in SAP
First of all, you must strictly separate the payment program into the payment proposal and the payment run. In the first step, the payment proposal is created by combining all due open items and open items for which payment is not possible. The result is a payment proposal list.
As soon as a corresponding payment proposal list has been created, it is possible to make certain changes to it. For example, you can remove open items from the list to exclude them from the payment run. The creation of a payment proposal list can be repeated as often as required because, in contrast to the payment run, it does not make any postings in SAP. It is therefore only used for grouping and managing open items.
After checking the payment proposal list, the payment run can be triggered to create the payment data. The results include information for printing checks, as well as payment files (e.g. direct debits or bank transfers). In parallel to the creation process, SAP clears the open items in the system, whereby the items are considered as paid / paid. At this point, a misunderstanding can often arise, because, strictly speaking, the posts have not yet been paid at this point. The payment files created must first be transmitted to the bank, usually electronically, so that the settlement takes place only after a certain period of time.
Which controls has SAP already implemented?
- SAP checks for direct dependencies between the payment proposal and the payment run. That means:
- Documents that were posted after the payment proposal, but before the payment run, do not find their way into the payment run.
This procedure also applies to documents that have a payment lock when the payment proposal is created but which has been removed before the payment run.
In addition to the direct dependency between the two program parts, SAP also blocks the customers and vendors used for the payment proposal. This is the only way to ensure that documents can only be cleared by a single payment run and that there is no overlap with, for example, a parallel payment run or changes to the data.
Why the above is only half the truth and what auditors can do
As is so often the case with SAP, there is a flip-side to all this. Because the use of the payment proposal is not obligatory. It is only carried out if explicitly specified and then but only then inconsistencies or even fraudulent actions can be found quickly. The scenario is very simple:
If no payment proposal is made, the payment proposal list cannot be checked. Without checking the list, unauthorized documents can easily enter the payment run, and are paid without further ado.
But that’s not all. Even if a payment proposal is made and a payment proposal list is created, there are other possibilities of fraudulent action. As an auditor, you should therefore take a closer look at the target process defined for checking the lists, on the one hand, and, on the other hand, you should be aware that a payment proposal is merely a test run of the actual payment run. This means that unneeded payment proposals can be deleted at any time. This procedure may provide a perfect gateway for fraudulent action, as Achim Gründel pointed out in 2016:
In the company, the written signature with date and signature of the auditor is required on the payment proposal. Due to the small number of employees in accounting, there is no separation of duties between the “Post document” and “Execute payment run” activities. Under these circumstances, it would therefore be possible for an employee to print out the valid payment proposal list and submit it to his or her superior for signature (4 eyes principle). The latter cannot detect any abnormalities and signs off on the list. The employee then deletes the payment proposal and posts an invoice of his/her “own” for the same amount as one of the amounts in the old list and simply exchanges the items in the payment proposal. In this way, the total amount also matches and the employee has a signed list which is “actually valid”. The fraud would most probably never be noticed, because the deleted payment proposals are definitively deleted in the SAP system. Accordingly, there is no table that lists a history of all payment proposals ever made or even a corresponding note to that effect.
For this reason, it is particularly important to check your internal regulations and to take appropriate measures where necessary.
This blog article started by looking at the basics of the payment run first, so that we can go into things in more detail in the next article and perform the corresponding data analyses in SAP. Of course, we will then include all the SQL statements and recommendations you need to perform an audit on this topic.
Source in German language:
Gründel, Achim: Betrugsrisiken im SAP-gestützten Auszahlungsprozess (Teil 4): Der automatisierte Zahllauf. In: PRev Revisionspraxis, Boorberg-Verlag Bd. 2 (2016), S. 87–100
