Automated Audit of Purchase-to-Pay in SAP

In this second blog post on auditing of purchase-to-pay in SAP, I would like to present the automated approach in greater detail, taking a look at all its various aspects. A lot of these analyses can of course be executed manually, but this is very time-consuming to do and thus should be avoided.

Purchase-to-pay master data

“Vendors” is the keyword when it comes to purchase-to-pay master data. Every single vendor that delivers goods or even services has a master data record. Many mistakes can be made here, ones that should lead to questions being asked at the audit stage at the very latest. In certain cases, you may even be forced to ask yourself: “How has it even come to this?”. But one thing that we can tell you for sure is that nearly every indicator developed by us is something that has already occurred at least once in the past. One very good example in the area of master data in my opinion is that of the:

Missing vendor

Taking a look at the criterion that is used to tag a document with this indicator makes it clear what we are dealing with here:

A document will be marked when it references a vendor (Table BSEG, Field LIFNR) that does not exist in the vendor master data (Table LFA1 or LFB1).

In our last post, we already introduced the SAP data structure in purchase-to-pay, including the relevant data tables. We therefore know that the relevant vendor master data can be found in tables LFA1 and LFB1. The reference starts in one of the most important SAP tables in accounting: the “BSEG” table. But why does the BSEG table only contain a reference to table LFA1 or LFB1? The simple answer is that by doing this redundancy is avoided. Think of it like this: would you write a shopping list for yourself and then write another one for your spouse or partner? That wouldn’t make any sense at all, right? That is why data is often stored with a reference to other tables, which contain the necessary information. This should be clear to see simply by taking a look at the following tables:

  Table BSEG                                        Table LFA1

If vendor 1204 is also missing in table LFB1, the document number “1800000013” would be marked for the indicator concerned. There is a risk of insufficient traceability of business transactions due to missing vendor master data.

Other examples of indicators in the area of master data are:

Vendor master data with inappropriate or incomplete payment terms

The aim of this indicator is to identify opportunities for savings.
There is a risk that inefficiencies or working capital losses have been caused by lax payment management.
The criterion for a document being marked for this indicator is as follows:
The document will be marked if the payment terms of the referenced vendor are not maintained or are inadequate.

Vendors without bank account

This aim of this indicator is to meet the audit objective of compliance and correctness.
There is the risk that payments cannot be traced due to missing bank account details.
The criterion for a document being marked for this indicator is as follows:
The document will be marked if it references a vendor where a bank account has not been maintained. However, at least one payment has been identified for this vendor.

It would be going beyond the scope of this blog post to introduce all indicators in this field here. This is why we have prepared a whitepaper containing details of all of the purchase-to-pay indicators that we have developed and implemented in zap Audit:

Purchase orders and goods received

Especially in the area of purchase orders and goods received, business transactions can frequently occur in unwanted ways. There are cases where the purchase order is posted after the goods received, where there is no reference to a purchase order for an item of goods received, or where purchase orders have been set up with missing or inappropriate payment terms. There are plenty of other cases I could mention. But these three examples should be enough for now:

Purchase order creation after invoice creation

Audit objective:
This indicator aims to meet the audit objective of compliance and correctness.
Description:
The document will be marked if an FI document was entered prior to the referenced purchase order.
Risk:
Standard processes and internal controls have been circumvented by directly entering the invoice.

Goods receipts without purchase order

Audit objective:
This indicator aims to meet the audit objective of process standardization.
Description:
The FI document has been marked because it is linked to a material document with the movement type 501. 501 means there is a goods receipt without a purchase order.
Risk:
There is the risk that invoice verification will be hindered due to the absence of a purchase order.

Purchase orders with inappropriate or incomplete payment terms

Missing payment terms are always a good sign of opportunities for savings, and that is precisely the objective of this indicator. There is a potential risk of lost discounts due to missing payment terms. This indicator helps you to easily identify opportunities for savings and thus save money in the future. It may also help you to improve your purchase-to-pay processes, if used correctly. In total, we have implemented 15 indicators for auditing opportunities for savings in zap Audit.

Auditing of invoices

Once your purchase orders and goods received have been audited, the next step is usually to audit invoices. But in some cases, there may be deviations from the standard process, where the invoice has been cleared before the goods received was posted. Of course, we have also accounted for this scenario:

Invoice cleared before goods received

This indicator does not directly analyze the data in the SAP tables, but instead analyzes the generated sequences by Financial Process Mining. One risk that may come to mind here is that of payment for services / goods without the service / goods being rendered. For this reason, an invoice is marked if it was cleared prior to the posting date of the goods received document.

zap Audit does not just analyze sequences in this area. Invoices in particular offer a great deal of scope for analysis and thus give rise to a lot of different indicators. From statistical outliers such as the “very high incoming invoice amount” indicator to that for “duplicate payments”, which we will take a look at in the next section. But first, here’s one for the statistics fans among you:

Very high incoming invoice amount

The document will be marked if it contains a very high invoice amount for a specific vendor. “Very high” means that the invoice amount is more than six standard deviations above the average invoice amount for the specific vendor. Vendors are only taken into consideration when more than 20 different invoice documents for the specific vendor have been found. The outlier analysis is based on Tchebysheff’s inequality. If you want to read more about this indicator, simply take a look at our blog series: “Getting serious: What are high incoming invoice amounts?“

Duplicate payments

It is not always that easy to say what added value the internal audit function contributes to the company. Internal audit is often seen as a regulatory necessity. It would therefore be much easier to justify this necessity by saving money. This is precisely why we have already devoted a comprehensive four-part series to duplicate payments. You can find the first part here: “Cashback: How the audit department pays off with duplicate payments“. For this reason, I will only explain the basics of how to detect duplicate payments in brief here. It is nearly impossible to say with absolute certainty that a duplicate payment occurred. Instead, there are several indications of such a scenario and if they crop up at the same time, then it is probable that a duplicate payment has occurred:

• Same amount on different documents and
• Same posting date and
• Same document date and
• Same document type and
• Same General Ledger account and
• Same vendor and
• Same external invoice number.

Exotic processes

The title “Exotic processes” may seem a little confusing at first, but it is actually a pretty good description of what these indicators are all about. In addition to the process areas of master data, purchase orders, goods received, incoming invoices and payments, there is another area that we have taken into account in zap Audit: that of Process Plausibility. We will take a brief look at what this means in this section. Simply reading the names of the associated indicators may be enough to send a shiver down any conscientious auditor’s spine. And that should hardly come as a surprise, because, in certain individual cases, such scenarios may even lead to cases of fraud. These include cases involving “transactions with blocked vendors”, or “vendors with multiple bank account changes”.

If we take a closer look at the case of “transactions with blocked vendors”, one might think that this is something that should not even be possible and which must be a contradiction in terms. Unfortunately not! There are two possible scenarios that may lead to a such a case of fraud:

1. A single SAP dialog user has all necessary authorization rights to unlock a vendor, enter a posting and lock the vendor afterwards or
2. There is the possibility of two individuals interacting with each other.

Both scenarios are possible, but these are not the only reasons for “transactions with blocked vendors”. A description of cases in which a document will be marked for the indicator is as follows:

A document will be marked when the vendor has more than one change to the vendor block field within the same day (Table LFA1 or LFB1 Field SPERR). The changes occurred on the same day as the processing date of the referencing FI document.

“Vendors with multiple bank account changes” works in a pretty similar way. A document will thus be marked when it was processed between two changes to the bank account of a vendor used in the document. The two changes to the bank account were made within a time period of 7 days` maximum.

Segregation of Duties

Segregation of Duties in SAP means that specific transactions in SAP should not be executed in one process by the same person. There are several existing tools on the market for analyzing SoD conflicts. But, in general, they simply analyze SAP authorizations to check if a certain user may use a critical combination of transactions. Most of them cannot check if a certain user has in fact used their authorizations to do so. This is because there is practically no other tool on the market that is able to reconstruct the actual processes in SAP. Thanks to our Financial Process Mining Algorithm though, we are able to check if someone has actually used their authorizations in a way that has had a critical impact on processes.

In what follows, I will present several examples of our 149 segregation of duties conflicts that zap Audit is able to detect in a fully automated way:

• Create fictitious vendor and initiate payment to the vendor
• Maintain a fictitious vendor and direct disbursements to it
• Create fictitious vendor invoice and initiate payment for it
• Procure unauthorized items and initiate payment by invoicing
• Procure unauthorized items and hide by not fully receiving the order
• Procure unauthorized items and enact payment for them
• Maintain a fictitious vendor and initiate purchase order to the vendor
• Receive services and release blocked invoice to offset receipt
• Maintain PO and release a previously blocked Invoice