The Ultimate Guide to Auditing Order-to-cash in SAP

In our experience, the focus of an audit of business processes in SAP is often on purchase-to-pay, followed by authorizations. I don’t want to speculate about the reasons for this at this point. The aim of this article is instead to cover absolutely everything this is to know about the basics of auditing order-to-cash in SAP on the basis of data analyses.

Okay, absolutely everything is perhaps somewhat of an exaggeration; I have, however, summarized, the topics which are relevant and could be perhaps the subject of your next audit. So, without further ado, let’s get started.

Before extensive data analyses can be started in an order-to-cash audit in SAP, knowledge of the actual sales processes should form the basis of a digital audit. In this context, however, I am not talking about interviews or surveys, but about an approach based on empirical determination from existing data. What else will be covered in this article?

  1. What is the difference between purchase-to-pay and order-to-cash in SAP?
  2. What is a data-based audit?
  3. Which tables serve as the basis for the audit and how do you actually obtain data?
  4. What can an audit of master data in order-to-cash look like?
  5. Which audit questions does cash raise in sales?
  6. A classic: Segregation of duties in order-to-cash

1. What is the difference between purchase-to-pay and order-to-cash in SAP?

If you compare the organization of data in the SAP system between purchase-to-pay and order-to-cash, you will notice the following: In order-to-cash, the data structures are designed in such a way that the sales process (SAP Sales and Distribution (SD) module) can be considerably more complex than purchase-to-pay. While in purchase-to-pay there are essentially “only” purchase requisitions and purchase orders outside Accounting, there is a sales document flow in the order-to-cash process. This sales document flow can be defined flexibly and individually and contains the following “triad” in the simplest case: Order => Delivery => SD invoice. However, the sales document flow can also be considerably extended, for example, to include inquiries and offers, though it does not have to be. The Financial Process Mining algorithm in zap Audit and zap Cash also takes the sales document flow into account and take you right through it step-by-step, so that each individual order-to-cash process becomes apparent in the data.

2. What is a data-based audit?

Once the processes have been reconstructed, whether in zap Audit or manually via the findings on the sales document flow, the actual data analyses and the audit follow. We call the data analyses indicators because the results of a data analysis represent indications for a finding. There are only a few data analyses where you can directly say that a result is a finding. However, segregation of duties conflicts would be such an example, because documents are posted with a certain transaction and this is a fact which leaves no room for any doubts.

Indicators always correspond to an audit-relevant audit question. From a technical point of view, these are data queries that search for documents from the dataset and satisfy certain predefined criteria.

However, the indicator must be defined in such a way that it always and exclusively targets the determination of a quantity of individual documents, i.e. all documents in the database are examined as to whether the indicator is relevant for a document or not (in other words, the indicator divides all documents into a kind of “black-and-white world”).

After the indicator has “run through” the database, all relevant documents are marked with the indicator. The documents concerned then have an indication of a finding with respect to this indicator.

To be able to navigate better within the indicators, each indicator is assigned to different dimensions. Each indicator belongs to a certain process, process area and has an audit objective. For order-to-cash this means:

Process: Order-to-Cash

Process areas: Master data, billing document, payment, delivery, sales document and process plausibility

Audit objectives: Compliance and correctness, saving opportunities and process standardization

In the following ePaper, we have summarized all the information mentioned for you, including an example of risk:

Download pdf

I will also present some examples from the various process areas in the course of this article. A detailed listing of all indicators would however probably go beyond the scope of the article at this point.

3. Which tables serve as the basis for the audit and how do you actually obtain data?

The most important SAP tables for the order-to-cash process for the auditor are:

  • VBRK: Billing Document: Header Data (SD)
  • VBRP: Billing Document: Item Data (SD)
  • LIKP: SD Document: Delivery Header Data
  • LIPS: SD document: Delivery: Item data
  • VBAK: Sales Document: Header Data
  • VBAP: Sales Document: Item Data
  • BKPF: Accounting Document Header
  • BSEG: Accounting Document Segment
  • KNA1: General Data in Customer Master
  • KNB1: Customer Master (Company Code)
  • KNBK: Customer Master (Bank Details)

Relations to accounting

Certain documents in accounting point at documents in order-to-cash. Such accounting documents are usually sales invoices and outgoing goods documents. The position of an accounting document (BSEG table) in the VBELN (billing document) data field refers to the header of an SD invoice (in the VBRK table). 

Getting data from your SAP system

Getting data from your SAP system is not always easy. There are various tools on the market which allow for data extraction from SAP systems. Usually for this purpose, an ABAP program is installed. However, this is at the same time a “show-stopper” in many companies, as transports into a SAP system require a Change Management process. They often take a long time and it is necessary to go through a series of authorization steps.

Another possibility is to manually download single tables from the SAP system. To do so, transactions like SE16 may be used. However, this requires a lot of manual processing and is rather inconvenient.

SAP data tables can also be extracted from an SAP system via Remote Function Call (RFC). To do this, a user account with corresponding user rights needs to call up RFC-components. An ABAP program is then not required. On the one hand, RFC is comparatively old and sometimes slow. On the other hand, it is well-established and available in every SAP system. By using RFC, the data extraction can smartly be optimized. In addition, it makes data extraction from SAP systems for analysis purposes easy and convenient. In zap Audit, we use this approach to automatically mirror the data from the SAP system into a local database at your company.

4. What can an audit of master data in order-to-cash look like?

After we have collected enough data, the first data analyses can now begin. But what do I actually want to audit? Here are a few suggestions from zap Audit:

Postings with customers without sales tax ID

A fairly simple, yet effective analysis that is always worth a look. Why? Because there is a risk that the sales tax has not been correctly recorded and that the tax authorities will contact you. But there are two small peculiarities to consider: The debtor…

  1. …must be located in an EU country other than your own, and
  2. may not be a natural person

Postings with non-existent customer

Okay, this analysis is really simple: No master record is found in the tables KNA1 and KNB1 for the KUNNR field of the BSEG table. In this context, various scenarios are conceivable as to why this might be the case. The simplest reason might be the deletion of a master record, which is not allowed according to the prohibition of deletion [Radierverbot] (Section 239 of the German Commercial Code – Handelsgesetzbuch [HGB]).

Looking for something more? Then you will find all of the 42 indicators from zap Audit that can be used to check your order-to-cash processes here:

Download pdf

 

5. Which audit questions does cash raise in sales?

Possible double-paid credits

The counterpart to the double-paid invoices in purchase-to-pay are double-paid credit notes. In this context, the following must be checked: If a document contains a credit note that has been cleared or offset by an (outgoing) payment and there are other items from other credit notes (for the same customer) that have also been paid or offset and that have the same amount, then it can be assumed to be a finding.

Deliveries not invoiced

This one is even more simple: A delivery for which no SD billing document / invoice can be found. The risk is simply that deliveries have not been invoiced and therefore have not been paid.

Looking for something more? Then you will find all of the 42 indicators from zap Audit that can be used to check your order-to-cash processes here:

Download pdf

6. A classic: Segregation of duties in order-to-cash

Segregation of duties in SAP means that certain combinations of tasks should not be conducted by one and the same person, as those are critical combinations of tasks. There are various tools on the market which allow for the evaluation of conflicts that arise during segregation of duties in SAP. These usually allow licenses to be evaluated in order to determine which user should perform which transactions. This determines whether a user couldperform a critical combination of transactions.

Of particular interest here is whether a user has actually performed such a critical combination within the same process. In such a case, there has been a breach of segregation of duties during a business transaction with regard to the critical task combination. Most analysis tools do not offer this kind of analysis, because it requires the end-to-end process to be identified first. The Financial Process Algorithm however fulfills this requirement, making it possible to conduct a real segregation of duties analysis.

The following concrete examples of separation of duties conflicts in SAP sales processes could be of interest:

  • Maintain a sales doc and generate a billing doc for it
  • Initiate a payment by creating fictitious credit notes
  • Maintain customer master records and post fraudulent payments
  • Create a billing document and inappropriately post payment
  • Maintain sales docs and enter an incorrect invoice
  • Maintain fictitious customers and initiate orders

Artikel teilen

Facebook
Twitter
XING
LinkedIn