Step through nine common purchase-to-pay scenarios and their proper mitigations on the way to compliance. These tips include configuration and processes you can apply in your standard SAP ERP systems.
Key Concept
Purchase-to-pay or procure-to-pay (commonly referred to as P2P) is one of the most common and critical business processes for any company that buys a good or service. P2P consists of all the subprocesses and activities from the time a determination is made to buy a good or service through its payment. It includes activities and processes such as a request for quotation, purchase requisition, vendor selection, purchase orders, goods receipt, invoice receipts, and payments.
The purchase-to-pay (P2P) process straddles key modules in the SAP ERP system, including materials management (MM) and accounts payable (AP). Given the sprawling nature of the process, as well as its importance and impact on the bottom line, it is important that companies implement strong controls that mitigate the risk of mistakes or fraud.
I’ll take you through nine scenarios that I’ve seen companies face in their P2P processes, and how to mitigate them in SAP ERP systems. These scenarios and their mitigation are targeted to business analysts, configuration specialists, and security or internal audit personnel, all of whom are collectively responsible for maintaining the integrity of the P2P process in an enterprise. All scenarios and screenprints are from an SAP ERP Central Component (SAP ECC) 6.0 system, but the concepts and controls apply to earlier versions as well.
Scenario 1: If accounts payable (AP) entries are not properly posted in the general ledger, it is possible that your AP is understated, thereby causing potential financial misstatements. It is important to note that AP needs to be accurately synchronized with your general ledger.
Mitigation 1: Ensuring that your system is set up for AP to automatically update the general ledger requires carrying out configuration in vendor account management. First, you need to make sure that the general ledger reconciliation account (field) is a mandatory entry for the vendor account groups. To do so, use transaction code OMSG or follow IMG menu path Financial Accounting > Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations for Creating Vendor Master Records > Define Account Groups with Screen Layout (Vendors). Double-click one of the vendor account groups and in the next screen double-click Company Code Data. In the next screen, double-click Account Management, which takes you to the screen in
Figure 1. This screen is for maintaining field status groups. Make sure that the Req. Entry radio button is selected for Reconciliation account, which makes this field mandatory for entry whenever you create a vendor (master). This ensures that each time a financial posting is made involving this vendor, the reconciliation account is updated and ultimately the corresponding general ledger account is updated.
Figure 1
Make the reconciliation account a mandatory entry
Additionally, you need to make sure that all the reconciliation accounts pertaining to vendors have the Post Automatically Only check box (field technical name XINTB) checked in table SKB1 (G/L account master company code).
Scenario 2: The three-way match is one of the most important P2P controls. A three-way match refers to the existence of a purchase order, goods receipt, and an invoice for a P2P transaction that is being reviewed. Specifically, you need to link a vendor invoice to a goods receipt and an accompanying purchase order (PO). Otherwise, there is the likelihood of bogus invoices being created (and worse, paid).
Mitigation 2: You need to first analyze which vendor account groups are to be subjected to the three-way match. If you are an auditor, you would have to obtain this information from the company you are auditing. Note that you can get a list of vendor account groups from the table LFA1 (technical name of the field is KTOKK). Then use transaction OMSG or follow IMG menu path Financial Accounting > Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations for Creating Vendor Master Records > Define Account Groups with Screen Layout (Vendors). Double-click the vendor account group you are reviewing, then under Field Status, double-click Purchasing Data. Under Select group double-click Purchasing Data. Make sure that the Goods-receipt-based inv.verif. field has the Req. Entry radio button selected (
Figure 2).
Figure 2
Set the GR-based invoice verification field to mandatory
With the list of vendors from table LFA1 that belong to the vendor groups that should be part of GR-based invoice verification, browse the contents of table LFM1 (vendor master record purchase organization data). Make sure that all the vendors in question have the GR-based Invoice Verification field checked. The technical name of this field is WEBRE.
Scenario 3: Proper segregation of duties (SoD) procedures and practices do not exist in the area of processing invoices and goods receipts. When a user can process invoices as well as goods receipts, it could lead to fraudulent activities.
Mitigation 3: You need to make sure that users do not have access to transactions that result in SoD violations. Ideally, companies should have a detailed matrix that maps the SAP user’s job responsibilities to activities and transaction codes within the SAP system. You therefore have to compare the access results that you obtain in the SAP system with this matrix. If any inappropriate access is detected, you should look for supporting documentation explaining the exception. If supporting documentation is not available, you should make note of this in your official audit report.
The transaction codes that should be within scope are:
- MIGO: Post goods movements
- MB01: Post goods receipts for PO
- MB02: Change goods receipts for PO
- MB31: Goods receipts for PO
- MB0A: Post goods receipts for PO
- MB1C: Other goods receipts
- MIGO_GO: Goods movement
- MIGO_GR: Goods movement
- MRHR: Enter invoice
- FB10: Invoice/credit fast entry
- FB60: Enter incoming invoices
- MIRO: Enter incoming invoice
- F-41: Enter vendor credit memo
- F-43: Enter vendor invoice
Note
In SAP systems, you often find more than one transaction code that carry out the same function. Sometimes certain transaction codes whose purposes seem to be identical are obsolete but companies continue to use them. It is therefore all the more important that all related transaction codes (such as the list above that contains many similar ones) are checked for appropriate access and that no assumptions are made about whether certain transaction codes are being used or not.
Scenario 4: The goods receipt/invoice receipt (GR/IR) account is manually cleared, thereby leading to financial misstatements.
Mitigation 4: The GR/IR account should never be manually cleared. Controls should be in place to ensure that only automated clearing is enabled. To do so, you first need to identify these accounts by using transaction OBYC. This gives you the list of transaction keys for postings in MM (
Figure 3).
Figure 3
Identify the GR/IR transaction key
Double-click the GR/IR clearing account line (with the transaction key WRX) to go to the screen in which you get the GR/IR clearing accounts. Make a note of these accounts, because you next need to verify whether these accounts are flagged for automatic posting. To do this, browse the contents of table SKB1 (G/L accounts per company code). Enter the GR/IR clearing account numbers in the selection criteria for this table in transaction SE16. Make sure that for this account number, the Post automatically only field is checked. (The technical name of this field is XINTB.) If this field is not checked for the GR/IR clearing account, it is a violation of internal controls.
Scenario 5: Lack of adequate controls and rigor in the realm of material master creation and maintenance could lead to incomplete or inaccurate data being entered.
Mitigation 5: First, you need to identify the material types that are being used. To do so, go to the material master table MARA (general master view). The technical name of the material type field is MTART. One of the material types I retrieved from this list is ZSTK (
Figure 4).
Figure 4
Identify the GR/IR transaction key
Retrieve the field reference groups that correspond to this material field type. For this example, I am only considering type ZSTK. Retrieve the contents of table T134 for the ZSTK material type. From this table, the value in the Field ref. (field reference for material master) field is ROH. Then run transaction OMSR and enter ROH in the search field for the field selection group. Position your cursor on the correct record and click the arrow icon to see the screen in
Figure 5.
Figure 5
Ensure the relevant field reference is mandatory
As shown in
Figure 5, make sure that the field reference ROH is a required entry.
Scenario 6: A selected (preferably small) group of individuals should have the ability to post goods receipts or inventory in the SAP system. Access by personnel outside this small group could be inappropriate and could cause fictitious goods received to be recorded.
Mitigation 6: Check the following transaction codes for inappropriate access:
- MB11: Enter goods movement
- MB31: Goods receipt for order
- MB0A: Goods receipt: PO unknown
- MB01: Goods receipt for PO
- MB02: Change material document
- MB1C: Enter other goods receipt
- MIGO: Goods receipt purchase order
- MIGO_GO: Display material document
- MIGO_GR: Goods receipt purchase order
Review your company’s documentation on user profiles, roles, and authorizations as well as their mapping with users and their responsibilities in their organization. Once you have identified all users with access to these transactions, you also need to ascertain why they have this access and whether that is reasonable or not. Make a note of any discrepancies and violations and bring them to the attention of the appropriate parties.
Scenario 7: Service entry sheets may not be configured in a way that prevents fraudulent goods receipts from being recorded.
Mitigation 7: Numerous companies that use MM use the service entry sheets functionality to process external services received. The received services are recorded as goods received. Therefore, it is important that appropriate measures are taken to ensure that certain fields are mandatory so that there is no attempt — erroneous or malicious — made to post fictitious entries.
Follow IMG menu path Materials Management > External Services Management > Define Screen Layout. Scroll down to find the entries for service entry sheets, such as ML81 Maintain Service Entry Sheets and ML82 Display Service Entry Sheets. Double-click the ML81 entry to go to the field selection key. Double-click Quantity fields to see the pop-up in
Figure 6. Make sure the top two entries are listed as required entries.
Â
Figure 6
Validate settings of certain quantity fields
Close the pop-up screen and double-click the Price and value fields line from the field selection screen to bring up the pop-up screen in
Figure 7. Select Gross price and Price unit as required entries.
Figure 7
Validate settings of certain price and value fields
Scenario 8: Unauthorized processing of blocked invoices could lead to certain invoices being processed that should remain in a blocked state. This could further lead to such invoices being processed for payment.
Mitigation 8: Only a handful of authorized personnel should have access to release or unblock blocked invoices. Two transaction codes are relevant to this activity:
- MRBR: Invokes a report that lists blocked invoices based on the selection criteria you enter and lets you release one or more of these
- MR02: Invokes a report similar to the one above but with different selection criteria
Review the company’s documentation on user profiles, roles, and authorizations, as well as mapping with users and their responsibilities in the organization. Once you have identified all users with access to these transactions, you also need to ascertain why they have this access and whether it is reasonable. Make a note of any discrepancies or violations.
Scenario 9: Duplicate invoices are created unintentionally or on purpose causing your AP to be overstated. This also creates the possibility of fraudulent activity in your SAP system.
Mitigation 9:
Anurag Barua
Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.
You may contact the author at
Anurag.barua@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the
editor.