SAP Substantive testing for 3 Way Match

SAP substantive analytical procedures from start to end from the 3-way match perspective.

Definition

For application controls perspective, Substantive Testing is an audit procedure that examines the financial transaction to see if a transaction has bypassed the controls. We don’t perform substantive testing of all the controls we test as part of application controls. Only those controls where Walk-through or Configuration testing fails at design or implementation level then we carry out substantive testing.

Why 3 Way Match substantive testing is Complex?

From 3-way match perspective, the substantive testing brings us new challenges which we don’t face in other controls substantive testing. Challenges mainly arise out of the volume of data and complexity of the tables from which data is to be extracted.

Before we begin

Before you continue reading this post on How to perform substantive testing for 3 way match in sap, I would recommend you read about – How 3-way match is tested in SAP here. You will get an idea of what configurations are required to be tested.

What are the steps that be perfomed?

1. Defined on what grounds the 3-way match is failing
2. Identify what data you need to check (based on 1 above)
3. Identify tables where this data is stored
4. Extract this tables. Link tables (if necessary)
5. Analyse data extracted and conclude.

In this post, we are going to assume that 3-way match filled in all possible way. Hence we need to test each and every aspect of the 3 way match substantively.

Following is the list of tables for 3 way match testing

While tables – EKKO and EKPO are straight forward, EKBE is a complex table. We cannot directly use EKBE table.

Following are the fields with corresponding tables for 3 way match testing.

We have 2 options (TCodes) for extracting data 1st – SE16N 2nd – SQVI

The best option is to use SQVI, as it allows for one data extraction. If you don’t have access to SQVI, then use SE16N to extract one table and use this data as an input for another table. If data volume is more than a 50 thousand rows then SE16N may give ABAP error. Using SE16N we can only filter and extract data from one table. Using SQVI, we can filter based on one table and extract data of another table (of course as long as there is a link between these 2 tables).

Using SQVI

We need to extract 3 different data.

1. EKKO (PO header) – Filter using Date, Company Code fields from EKKO table itself
2. EKPO (PO Line) – Link EKKO and then filter Date, Company Code fields from EKKO
3. EKBE (PO History) – Link EKPO, then Link EKKO and filter Date, Company Code fields from EKKO.

1. Invoice without GRN

In default SAP installation, a key field named “GR-Bsd IV” i.e. “Goods Receipt based Invoice” is editable at the time of PO by users. This is a cause for concern for auditors because this will enable users to create an invoice without GRN. The best case scenario for this configuration to be “Display only”, i.e. users should not be able to edit this field in Purchase Order. If the field is editable, we need to extract data and check whether any users have left it unchecked in any PO. The field is in EKPO table, Field Name – WEBRE.

Practically, we might find that this field is not ticked for some of the scenarios listed below

1. Service PO. Check EKPO-PSTYP (Item category in purchasing document) to exclude “Service” Category.
2. Import PO. Check EKKO-WAERS (Currency Key) to exclude Local Currency, or check EKKO-BSART (Purchasing Document Type) to exclude the PO document type used for Import PO.
3. PO from Affiliate vendors. Check EKKO-LIFNR (Vendor’s account number) to Exclude 3rd party affiliated vendors or check EKKO-LLIEF (Supplying Vendor) to exclude non-3rd party affiliated vendors.
4. Bulk low-value materials. Check EKPO-MATKL (Material Group) to exclude such type of materials.

2.Tolerance for GRN

Tolerance for GRN quantity is copied to PO from PO Configuration or from Material Master (if defined). At the time of PO, tolerance fields may be editable. If users change the tolerance fields in PO, then GRN can be created against that PO up to that tolerance. In best case scenario, the tolerance fields should not be editable in PO. If it is editable, then we need to extract data and check whether users have modified the tolerances. For the setting of tolerance in PO, we have 2 fields – UEBTO (Overdelivery Tolerance Limit ), UEBTK (Indicator: Unlimited Overdelivery Allowed). If UEBTK is ticked, then users can create GRN for any quantity.

In some cases, we might find that “Unlimited Overdelivery Allowed” indicator may be ticked.

1. Service PO. Check EKPO-PSTYP (Item category in purchasing document) to exclude “Service” Category.
2. PO from Affiliate vendors. Check EKKO-LIFNR (Vendor’s account number) to Exclude 3rd party affiliated vendors or check EKKO-LLIEF (Supplying Vendor) to exclude non-3rd party affiliated vendors.

3.Tolerance for Invoice Price

Tolerance for invoice creation is dependent upon Receiving Invoice Configuration. In best case scenario, a system should not allow the price to be edited at the time of Invoice Booking (i.e. at the time of MIRO). If the system (SAP ERP) allows prices to be edited, then if the price entered is higher than PO, then invoice should not be allowed to be posted.

To sum up, we will test it substantively in following situations. 1st – Tolerance is not set. 2nd -Tolerance is set but Invoice is allowed to be posted for higher price/quantity. For testing this, we need to compare – PO Price vis a vis Invoice price

To calculate PO Price – NETPR / PEINH (i.e. Price divided by Per Unit) from EKPO table for each individual PO Line Item. This value is in PO Currency. Hence we need to compare Value in Foreign Currency only.

To calculate Invoice Price – REFWR / MENGE  (i.e. Invoice Value in Foreign Currency divided by Invoice Quantity) from EKBE Table. This value will be in Foreign Currency. Hence will not be affected by Currency Fluctuations. Filter for only Invoice Transactions by using a filter on VGABE (Event Type) as 2 (Invoice). There can be multiple Invoice against the same PO, hence when comparing using Invoice price table as your base to compare PO price. In short, in EKBE table, use Vlookup to get values from EKPO table.

3.Tolerance for Invoice Quantity

Tolerance for invoice creation is dependent upon Receiving Invoice Configuration. If the quantity entered is higher than PO, then invoice should not be allowed to be posted. If the system allows Invoice quantity to be higher than GRN quantity then we need to test the control substantively. Thus we need to find cases where Invoice quantity is more than GRN quantity. For testing this, we need to compare – GRN Quantity vis a vis Invoice Quantity.

To calculate GRN Qty – From EKBE table calculate a sum of all MENGE (Quantity) based on BELNR (Material Document) per PO Number and PO Line Number. Filter on VGABE (Event Type) as 1 (GRN).

To calculate Invoice Qty – From EKBE table calculate a sum of all MENGE (Quantity) based on BELNR (Material Document) per PO Number and PO Line Number. Filter on VGABE (Event Type) as 2 (Invoice)

The best way to analyse this is to use Pivot Tables in Excel. Download Sample Excel file from here or Here

The primary key is “PO Number” and “PO Line Number”. Hence First we need to drag PO Doc number and PO Line Number into Row. Then To get the sum of quantity based on Material Document drag “Material Doc Num” to Row. We need to compare Invoice and GRN quantity, hence Drag “Event Type” to Columns. Finally to get sum of quantity, drag “calculated Qty” to Values.