Avoiding and analyzing conflicts of SoD is not easy without third-party tools. That’s why we present an approach you can use to analyze conflicts in SoD without using one of them like zap Audit. Everything you need to perform the analyses can be found in a standard SAP system. We will set out the approach to adopt for 5 critical SoD conflicts you should prevent in your company.
Duties within an organization are segregated (Segregation of Duties, SoD) to prevent the abuse of critical combinations of operations within a process. The authorization management of a company implements preventive measures to avoid criminal activities by single users. In order to provide these preventive measures against criminal activities, the SoD conflicts have to be identified in the first place. To be able to take these measures, it is necessary to perform an analysis. There are two different approaches to doing this: the proactive approach, which targets analyzing the authorization objects assigned to a user and the reactive approach which detects business transactions which have occurred. Conflicts in SoD appear in various areas of a company, e.g. in the area of Order to Cash (O2C) or Purchase to Pay (P2P).
If a single person performs a combination of critical activities within a process sequence, this is referred to as a conflict of SoD. This means there is a possibility a person did not act in the interests of the company. Conflicts indicate the possibility of several criminal activities being combined. Of course, not every single conflict implies illegal activities on the part of a user. If illegal activities have however indeed occurred within the company, a SoD conflict may very well serve as an indicator of this – considered in the context of the entire set of rules.
In order to detect SoD conflicts, both conflicting activities have to have been executed by one single user. Illegal activities that were executed by more than one user, e.g. in cooperation between two or more employees, are not taken into consideration here.
5 critical Conflicts of SoD
P2P: Vendor Master Data Maintenance + Vendor Master Data Confirmation
Users can create and change vendor master data without having to observe the four-eyes principle. Fictitious vendors can be created or bank account information can be changed to redirect payments to a different account. As a compensatory control, the “Master Data Change Protocol” should be checked before every payment run. You can examine the protocol using the transaction “FK04“. It is necessary to check if the same user has maintained the Master Data and confirmed the change to it. This check should be carried out by a person who does not have authorization to maintain Master Data.
The information about which user created what Master Data is provided in the “LFB1” table. The confirmations of changes to master data are stored in the “CDHDR“ table. Restrict the data to the transaction code “FK08” and you will obtain all confirmations with the associated user. By executing the transaction “SQVI“, you can join together both tables for the user. Users who executed both activities are displayed as a result. It is not possible to analyze if a user confirmed the same Master Data that he changed in the “Quick Viewer”. Additional ABAP programming has to be done due to a field type incompatibility for the vendor number in both tables.
List fld. selection:
- LFB1 – Name of Person who Created the Object
- LFB1 – Account Number of Vendor or Creditor
- CDHDR – Transaction in which a change was made
- CDHDR – User name of the person responsible in change document
- CDHDR – Object class
- CDHDR – Object Value
The result shows you whether the four-eyes principle has been sidestepped by any user.
P2P: Purchase Order Maintenance + Purchase Order Release
Users could possibly create, change and simultaneously release purchase orders. An effective four-eyes-principle should be implemented for the purchase order process. The combination of both authorizations, that is for the maintenance of the purchase order and for its release, might lead to the issuing of unauthorized purchase orders.
Details of which user created which purchase order are provided in the “EKKO“ table. Each purchase order is linked to the user who posted it.
You can find the associated change documents in the “CDHDR“ table. Orders can be released by executing one of the following transactions: “ME28”, “ME29”, “E29N”. To obtain these particular results, restrict the data from the “CDHDR“ table to the aforementioned transactions. The result obtained contains all purchase order releases for the corresponding user.
In order to identify a conflict, you can first check if a user has created and confirmed any purchase order. If there is no overlap of users in both tables, there is no conflict of SoD. To take the analysis further, you can once gain use the Quick Viewer transaction “SQVI“ and join the tables together with the following restrictions: Table: “EKKO” technical Name “ERNAM” with Table: “CDHDR” technical name “USERNAME” (see Figure 1). Restrict the results from the “CDHDR“ table to purchase order release transactions. Select the purchasing document number with the corresponding user and the object value with the corresponding user from the “CDHDR” table. Due to the different object types of the purchasing document number and object value, it is not possible to join both tables for these fields without additional ABAP code. The only way to get the results required is a manual analysis.
List fld. selection:
- EKKO – Name of Person who Created the Object
- EKKO – Purchasing Document Number
- CDHDR – Transaction in which a change was made
- CDHDR – User name of the person responsible in change document
- CDHDR – Object class
- CDHDR – Object Value
The result shows the users who executed both activities. To take the analysis further, you can compare the purchase document number from the “EKKO” table with the object value from the “CDHDR” table. If both values are equal, the corresponding user released his own purchase order: a conflict in the segregation of duties exists.
Comparing the purchase order IDs from both tables with big datasets is very time-consuming. Our advice: Export the result as a .csv file and import the data into e.g. Excel. Filter the data to show only purchasing documents with an equal object value. The SoD results are restricted to the creation of purchase orders. Changes are not taken into account because they are stored in the same “CDHDR” table with the corresponding transactions “ME22/ME22N” as the releases. The Quick Viewer does not allow a single table to be used multiple times so it is not possible to analyze purchase order changes and releases without ABAP programming.
Figure 1: Table join EKKO – CDHDR for SoD analysis
P2P: Purchase Order Maintenance + Goods Receipt Posting
In this conflict, users can maintain purchase orders and simultaneously post a fictitious goods receipt. It is conceivable that an agreement between the vendor and an employee may have been reached. Users could create a purchase order and subsequently fake the receipt of goods.
Purchase orders with the corresponding users can be found in the “EKKO“ table in the “ERNAM” field. You can find the user responsible for posting the goods receipt in the “MKPF” table in the “USNAM” field. It is necessary to check if users created a purchase order and also posted the goods receipt.
Use the “SQVI“ transaction to join both tables together for the User. (Table: EKKO Field: ERNAM equals Table: MKPF Field: USNAM). The result contains all users who performed both activities. Because of the different datatypes, you can only check whether the purchase order matches the corresponding goods receipt manually. We recommend that you export the data because of the large volumes of data involved.
Purchase orders are generally only audited above a certain amount and value. If the SoD conditions are not being properly met, cases of fraud then become possible up to a certain threshold. The authorizations for the transactions “ME21“, “ME21N“, “ME22“ and “ME25“, combined with the authorizations for “MB01“, “MB0A“, “MB1A“ or “MIGO“, are critical because users can then issue both purchase orders and goods receipts.
List fld. selection:
- EKKO – Name of Person who Created the Object
- EKKO – Purchasing Document Number
- EKKO – Company Code
- MKPF – User name
- MKPF – Transaction Code
- MKPF – Reference Document Number
The analysis includes only the conflicts resulting from creating a purchase order, not changing it. An extension of this that also takes changes in purchase orders into consideration is difficult to build since the whole Change Log has to be included in the analysis.
O2C: Customer Master Data Maintenance + Entry of/Changes to Sales Orders
Wide-ranging authorizations of a single user in the order-to-cash area can also lead to conflicts of interest: Users with the authorizations to maintain customer master data and sales orders could create fictitious customers with fake bank information. There is a possibility to show a credit and subsequently redirect payments to one’s own account.
Customer Master Data is stored in the table “KNA1“. In order to create or change customer master data, the transactions “FD01”, ”FD02”, “XD01” or “XD02” are performed. The “VBAK” table contains all sales orders. Sales orders can be created by using the transactions “VA01” or “VA02”.
To perform the analysis, join both tables together using the “SQVI“ transaction on the user (Table: KNA1 Field: ERNAM and Table: VBAK Field: ERNAM). Additionally join the customer from both tables (Table: KNA1 Field: KUNNR and Table: VBAK Field: KUNNR) (see Figure 2).
The result contains the users who created a sales order and the corresponding customer.
Figure 2: Table join KNA1 – VBAK for SoD analysis
List fld. selection:
- KNA1 – Name of Person who Created the Object
- KNA1 – Customer Number
- VBAK – Sold-to party
- VBAK – Name of Person who Created the Object
As in the other case, this analysis is limited to creations and not changes of customer master data, since otherwise the whole change log would have to be included (see conflicts 1-3).
P2P: Purchase Order Maintenance + Payment Run Execution
Another conflict in SoD may occur due to the combination of purchase order maintenance and the execution of payment runs. When performing the “MIRO” transaction, e.g. the bank data of the one-time vendor can be changed. If users are also authorized to execute payment runs, this may lead to unapproved invoices being paid unnoticed by the company.
Executing the “MIRO” (Invoice posting) or “FB01” (GL posting) transactions and simultaneously executing payment runs with e.g. transaction “F110” is another indicator of a possible SoD conflict.
The “BKPF” table shows, amongst other things, the vendor invoices created with the transactions “MIRO” and “FB01”. The clearing documents for the vendor statements can be found in the “BSEG” (Accounting document segment) table. However, since no transaction codes are listed in the “BSEG” table, the transaction codes for the clearing documents must be exported from the “BKPF” table in a second step.
First, link the “BKPF” and “BSEG” tables together using the accounting document numbers (BELNR), the company code (BUKRS) and the fiscal year (GJAHR). Use the selection fields to restrict the result to the transactions “FB01” and “MIRO”. Then export the result, e.g. to Excel. Unfortunately there is no other way of joining
As a second step, you have to export a selection from the “BKPF” table, limited to the TCODE “F110” via transaction “SE16N”. Only the technical fields BELNR, BUKRS, GJAHR, USNAM and TCODE are required for the purposes of the analysis. Then, you connect the first export using the fields 1.BSEG.AUGBL, BSEG.AUGGJ and 1.BSEG.BUKRS with the second result 2.BKPF.BELNR, BKPF.GJAHR and 2.BKPF.BUKRS.
List fld. selection:
- BKPF – Accounting Document Number
- BKPF – Company Code
- BKPF – User name
- BKPF – Transaction Code
- BSEG – Document Number of the Clearing Document
- BSEG – Fiscal Year of Clearing Document
If the “USNAM” field has the same value in both fields of the new result table, a SoD conflict is present and the user has executed two activities: posting of the invoice and triggering of the payment run.
Conclusion
In certain cases, it is either difficult or impossible to evaluate SoD conflicts without ABAP programming or third-party tools. At no point was possible it to detect SoD conflicts triggered by changes to data for instance. This leads to incomplete results. However, many cases can still be identified and this constitutes a good initial step in the direction of a clean and conflict-free system with regard to SoD.
Manual auditing of SOD conflicts comes up against a large number of restrictions. If an obligatory SOD has been identified, then it is only possible in a very minimal number of cases to determine whether it has actually taken place in the same process sequence and thus constitutes a determined finding for the purposes of the audit. As a result, zap Audit is the perfect solution as it allows you to conduct an analysis of segregation of duties based on transaction codes and actual conflicts. The integrated mining of financial processes reconstructs entire process sequences and serves as the basis for the analysis. This not only eliminates restrictions, but also efficiently reduces false positives. This article presents only one of 125 audit questions from zap audit.
