In our last blog post, we provided you with a general overview of some of the peculiarities of the payment program in SAP. This time round, we are going to look at things in more detail and have prepared 3 data analyses that you can use to audit the payment program in SAP.
But before we get started with performing an audit of individual payment runs or segregation of duties conflicts in the payment program, we will first take a look at the SAP tables in which you can find information about the payment program.
Important payment program tables in SAP
The payment program basically revolves around the tables that start with REGU* for regulation and can be broken down as follows:
- REGUA Change of payment proposals: user and time
- REGUH Settlement data from payment program
- REGUP Processed items from payment program
- REGUPO Line item status before the “n”th change
- REGUPW Tax information per tax type / FI line item in payment run
- REGUS Accounts blocked by payment proposal
- REGUT TemSe – Administration Data
- REGUTA Paying Company Codes for DME Files
- REGUV Control records for the payment program
This looks like a lot of information, but for the following analyses only parts of the tables are needed. Essentially, it is in the REGUH, REGUP, and REGUV tables where the main action takes place. More general information about the payment run can be found in the REGUH table, such as the run date (LAUFD field) or the additional identification feature (LAUFI field). REGUV contains a lot of interesting information, such as whether a payment proposal has been processed or whether a payment proposal was created at all. Table REGUP is somewhat more detailed with regard to the details of documents. Here you can find, for example, the document number, document date, amount and much more.
Auditing the payment proposal
In our last blog post, we already mentioned that the execution of a payment proposal is optional and can be repeated as often as desired. It can also be easily deleted from the SAP system, making it difficult or impossible to audit changes to released payment proposals under certain circumstances. The situation is different when a change has been made. This can easily be seen in the REGUV table. In this context, the XVORB field serves as an indicator as to whether a proposal has been processed or not. Without evaluating written approvals of the payment proposal, we now already have a good indication as to whether a payment proposal has been examined or not. If there is an “X” in the field, it has been changed.
The test is therefore very simple. The fastest method is probably by using the transaction “SE16” or “SE16N”.
The data for the input mask is then:
Table: REGUV
Field Name: Indicator: Proposal run edited, option: equal to, from value: ” (empty)
By clicking on “F8” or the clock, we then obtain as a result all payment runs for which the proposal run was not processed. This list may be very large for some of you. It would therefore be advisable at this point to carry out a detailed examination of those payment proposals which contain a large number of payments made. Because the probability that none had to be processed for many payments is significantly lower.
Non-existent payment proposal
But what if no payment proposal has been executed at all? Then it follows that it wouldn’t have been possible for any to have been processed either. This is exactly the question we are going to address next. The necessary information is also to be found in the REGUV table in the XVORE field.
Once again, it is quick to run the check. To do this, we again use the transaction “SE16” or “SE16N” with the following input mask:
Table: REGUV
Field Name: Indicator: Proposal run carried out, option: equal, from value: ” (empty)
Field Name: Indicator: Production run carried out, option: equal, from-value: ‘X’
The second selection (production run carried out) limits the result set to only all those payment runs that were actually executed. In the resulting list of results, you now have to check why no payment proposal was created. There may be a simple reason for this, in which case the audit can be completed quite quickly. For example, it is conceivable that only a small number of payments have been settled and the audit has already been carried out manually in advance.
Back to the roots: Segregation of Duties conflicts in the Payment Program
Segregation of duties conflicts always hold a certain potential for fraudulent actions. Especially in the area of payments, you should always take a closer look, because the outflow of liquidity can be faster than you expect. To make the audit a little easier to perform, I have created an SQL query (tested on HANA). To use the query in SAP, call up the “DBACOCKPIT” transaction and navigate to “SQL Editor” via “Diagnostics”:
| 1 | SELECT DISTINCT BKPF.MANDT, BKPF.BUKRS, BKPF.GJAHR, BKPF.USNAM, BKPF.BELNR, BKPF.TCODE, BSEG.AUGBL, B2.TCODE, LAUFD, LAUFI, XVORL FROM BKPF |
The result is a quick and clear list of all document pairs that have a separation of duties conflict (where the user name (USNAM) is the same and the transactions conflict with each other (FB01 – Post document and F110 – Automatic payment transactions). Cancellations are also excluded (STBLG=”). However, this procedure only finds conflicts that follow on from each other directly in the process. In zap Audit, conflicts are also found where further activities lie between the posting of a document and automatic payment; for example, when an invoice is subsequently changed.
An analysis of various separation of duties conflicts is already built into zap Audit, so that the SAP tables are automatically analyzed and you, as an auditor, only have to follow up on the findings. In this way, we provide you with support in performing your audit so you can concentrate on what is most important: doing the audit itself! So why not try zap Audit for free? Just contact us to get started.
