4/8/2019 3 data analyses for auditing the payment program in SAP

Other
3 data analyses for auditing the payment program in SAP
5 reading min.

written by
Dennis Jürgensen

Tweet

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 1/9
4/8/2019 3 data analyses for auditing the payment program in SAP

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

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 2/9
4/8/2019 3 data analyses for auditing the payment program in SAP

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

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 3/9
4/8/2019 3 data analyses for auditing the payment program in SAP

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 con icts 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
https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 4/9
4/8/2019 3 data analyses for auditing the payment program in SAP

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":

SELECT DISTINCT BKPF.MANDT, BKPF.BUKRS, BKPF.GJAHR, BKPF.USNAM,

BKPF.BELNR, BKPF.TCODE, BSEG.AUGBL, B2.TCODE, LAUFD, LAUFI, XVORL FROM
BKPF
LEFT JOIN REGUP ON (BKPF.MANDT = REGUP.MANDT AND BKPF.BUKRS = REGUP.BUKRS
AND BKPF.GJAHR=REGUP.GJAHR AND BKPF.BELNR=REGUP.BELNR)

1 LEFT JOIN BSEG ON (BKPF.MANDT = BSEG.MANDT AND BKPF.BUKRS = BSEG.BUKRS

AND BKPF.GJAHR=BSEG.GJAHR AND BKPF.BELNR=BSEG.BELNR)
JOIN BKPF AS B2 ON (BSEG.MANDT = B2.MANDT AND BSEG.BUKRS = B2.BUKRS AND
BSEG.AUGGJ=B2.GJAHR AND BSEG.AUGBL=B2.BELNR)
WHERE BKPF.TCODE='FB01' AND B2.TCODE='F110' AND BKPF.USNAM=B2.USNAM AND
BKPF.TCODE!=B2.TCODE AND BKPF.stblg='' and b2.stblg=''

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

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 5/9
4/8/2019 3 data analyses for auditing the payment program in SAP

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:

Contact

Topics: Data Analytics, Purchase, payment, Payment run, SAP Audit, SQL

Sign up to receive
our latest news and special o ers
direct to your inbox!

 Your business email

I agree to the terms and conditions of the Privacy Policy.*

subscribe now

Comments

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 6/9
4/8/2019 3 data analyses for auditing the payment program in SAP

Name*

Email*

Comment*

I agree to the terms and conditions of the Privacy Policy.*

protected by reCAPTCHA
Privacy - Terms

submit

Recommended for you 

Auditing SAP processes for xed An unsparing look behind the

asset and inventory scenes: How to analyze one-time
accounts in SAP

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 7/9
4/8/2019 3 data analyses for auditing the payment program in SAP

Professional Judgement in auditing

SAP xed assets

Two steps to analyze bad payment

terms in SAP

Automated Audit of Purchase-to- Digitization of auditing SAP

Pay in SAP purchase processes

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 8/9
4/8/2019 3 data analyses for auditing the payment program in SAP

© zapliance GmbH 2019 Legal Notice Privacy Policy General Terms & Conditions

https://www.zapliance.com/en/blog/auditing-the-payment-program-in-sap 9/9