The Procure to Pay cycle generally involves the following steps in the below mentioned order:
Although the above figure holds good for any standard P2P process, there are still n-number of deviations from these process based on different industries and business processes followed in the company (ex: Subcontracting). We will try n discuss all of them.
In case of SAP (t-codes) the above cycle translates to somewhat like this:
ME53N -> ME23N -> MIGO (MB51) -> MIRO (MIR4) -> F-30 (FB03/FBL1N)
When translating to tables, it will be something like this:
EBAN -> EKKO / EKPO -> MKPF / MSEG -> RBKP / RSEG -> BSAK / BSIK
There are other very important tables which we will go through once we move forward. Also for the sake of this discussion (from audit analytics point of view) we will leave PR out. So let’s start with Purchase Order.
The PO in SAP has numerous controls that we will discuss, almost all of which resides inside the EKKO & EKPO tables. The PO inside SAP looks somewhat like this:
The top items displayed separately are header (EKKO) data and the ones inside the table are line items (EKPO) data. A purchase order can have different types as configured by the company based on the different sorts of requirement & processes happening inside the company. for ex: NB – ‘Standard PO’ , UB – ‘Stock Transfer Order’ etc. changes from client-to-client. Two columns inside EKKO & EKPO are pretty important – ‘ABSKZ’ & ‘LOEKZ’ i.e. rejected or deleted purchase orders. A PO can be deleted or rejected basis the individual line items and also each item can have GRNs / IRNs respectively.
Usually in well-established SAP systems, there is an approval process defined for Purchase orders, the basis of the approval, hierarchy, final authority etc. depends upon multiple conditions but is usually mapped inside SAP on the basis of type of PO, which we discussed above identified by the fields BSART & BSTYP in the tables. The approval process is called as release strategy in inside the SAP and the PO is set to be released or unreleased basis it’s workflow approval trajectory.
The fields FRGKZ, FRGKE etc. inside EKKO usually pertains to the PO approval process and they are either:
- Empty – No Strategy in place hence no approval process
- ‘X’ – ‘Generally speaking – released/approved
- ‘1/2’ – ‘Released, Cancelled, Blocked’ etc. can be configured by the company as per their needs
apart from the above there can be new keys generated for different sorts of approval needs. A PO release tab looks like this, with the green tick resembling the approval at each step and the yellow being the pending authority as of now:
Another not so famous control indicator is GR/IR Indicator in EKPO WEBRE which is a control placed for GR based invoice verification. There can be many genuine cases based on the different processes inside the company where this indicator might not be ticked such as Service POs but it’s usually a good practice to still tick it automatically through config so that it can’t be edited by the user when creating a Purchase Order.
But how to download this data from SAP and filters to give?
We have to start with EKKO based on the (BEDAT) Document date filter and the company code (BUKRS) we will go ahead and get all the corresponding Purchase Orders along-with all the relevant fields for analysis. Take these Purchase Orders and put them as filters for EKPO to get all the corresponding line items for them.
Next let’s discuss one of the most important tables for P2P: EKBE (Purchase Order History). This tables gives the whole trail that happened against a purchase order, be it GRN, Invoice, down payments, advances etc. The PO history tab is also visible in ME23n SAP screen and somewhat looks like this, wherein you can the Invoices & GRN against each item of a Purchase Order:
The indicator BEWTP (history category) or Trans/Event Type, either of them can be used to identify the type of document posted against the PO. Generally: Q-Invoice, E-GRN. Apart from this it holds the Vendor, net value, quantity, movement type, clearing value among other interesting fields. With just this table and the PO ones discussed above, we can actually do almost all the analysis for auditing including but not limited to 3-way match, GRN analysis, IRN analysis etc. The only thing we need to take care is that there is no quantity unit mapping in this table i.e. in a few engagements I have found the PO quantity to be different and this GRN/IRN quantity to be different in this table, due to which certain differences arise.
UEBTO/UEBTK are the tolerance limits used in conjunction with the 3-way matching control inside the PO table. The over delivery and under delivery limits are either configured or can be updated at the time of creating a Purchase Order and is respected through out the SAP eco-system. Apart from this there are individual tables for both Invoice & Goods Receipt as RBKP/RSEG & MKPF/MSEG. These tables also hold different interesting fields which are used for analysis. MSEG table contains the full movement of a material at an individual level which makes it one of the most populated tables inside SAP.
Using the above mentioned tables in conjunction with the Vendor tables mentioned in last blog, we can conclude upon the tables for P2P. There are numerous tables which we have not touched upon such as EKBZ which holds the planned delivery details & charges levied on the GRN/Invoice against a PO etc, but for our purpose this would suffice, we will see different tables and learn about them when we will dive deep into the data analysis for these SAP tables and discuss other business processes.
Until then… 🙂
VAD3R 