Different operational steps could allow errors and fraud over the following subprocesses: processing purchase orders (POs), entering incoming invoices, unlocking invoices, and processing payments. I show you how to measure the control effectiveness in order to understand if key settings have been correctly implemented in an SAP system. This phase is control assessment and effectiveness. I also describe mitigation controls over the procure-to-pay (P2P) process that you can use to cover the risk of money lost owing to the price or quantity variance generated by possible errors or conflicts of interest.

Perform a Three-Way Match Invoice Control Effectiveness Assessment

The first important step to be analyzed is related to the layout settings in PO processing. Using transaction code ME22N, you can modify many relevant fields that are not related to the settings of the layout, but that are relevant to the PO, by bypassing three-way match control (Figure 1). Those fields include GR-Bsd IV, Unlimited, and the Delivery complete flag. To change a PO follow menu path Logistics > Material Management > Purchasing > Purchase Order > Change. In the next paragraph I discuss the different impacts of PO changes in order to help you understand how easy it is to bypass the three-way match invoice control.  

GR-Bsd IV

The GR-Bsd IV indicator is located in the PO line item Invoice tab (Figure 1). This indicator ensures that the invoice receipt performed using transaction code MIRO (Figure 2) is only submitted as long as a goods receipt (GR) is posted using transaction code MIGO. There is a risk, however. The GR-Bsd IV setting is active in the PO, but it can be easily modified after the final approver’s release because the transaction layout has not been properly grayed out as shown in Figure 1.   When the indicator GR-Bsd IV is active, the system forces you to carry out the GR before making an IR. If you follow SAP standard menu path Purchasing > Purchase Order > Follow-on Function > Logistic invoice Verification (MIRO) to post a logistic invoice related to a released PO without a GR, the following message appears in a pop-up window: No (suitable) item found for purchase order 4500000029 (Figure 2). If the indicator in the PO is off or modifiable by an end user after management final approval, you can post an invoice entry (MIRO), even if the goods are not received in the warehouse.

Unlimited and Delivery Complete

You can find the Unlimited and Delivery Complete indicator in the PO line item Delivery tab (Figure 3). The Unlimited indicator must be grayed out and eventually inserted automatically by default in the PO. Otherwise, by activating the indicator manually in transaction code ME22N, you can bypass some standard preventive controls. Also, the Delivery Complete indicator should be defaulted automatically by the system when the GR has been posted and should not be possible to enter the indicator manually; otherwise it is possible to hide goods invoiced and paid, but not received in the warehouse.  

Evaluate Tolerance Key Settings

In the three-way match invoice control, you can set the tolerance key to control differences in price or quantity among PO, GR, and IR, and fluctuations between material standard and the price included in the PO.

Tolerance Key: B1

Tolerance key B1 allows you to control the percentage of goods quantities that could be accepted in excess or defect (i.e., above or below specified delivery amounts) compared with quantities confirmed in the PO by management. With tolerance key B1, you can set percentages for lower and upper tolerance limits. For example, I have set these limits to five percent (Figure 4). Use customizing menu path SPRO > Material Management > Inventory Management and Physical Inventory > Good Receipt > Set Tolerance Limit. If a user tries to post a receipt of two quantities of goods with transaction code MIGO, with reference to the PO 4500000044 of one single quantity, the system automatically blocks the GR because the percentage upper limit of five has been exceeded. See the error message in Figure 4. The menu path for posting a GR is Purchasing > Purchase Order > Follow-on Function > Good Receipt.  

Tolerance Key: DW

Tolerance key DW controls the delta quantity amount allowed between the GR and IR when the GR has not yet been posted. The system delivers a warning message that Delivered Quantity is 0, and the invoice is blocked for payment. Figure 5 explains how tolerance key DW works and shows the related error message during the task of entering an incoming invoice. You can customize tolerance key DW by following menu path SPRO > Material Management > Logistic Invoice Verification > Invoice Block > Set Tolerance Limit. In this way you can create an invoice before the good has been accepted in the warehouse (GR = 0), but the value of the quantity invoiced using transaction code MIRO is compared with the PO price. In the following example I try to post an invoice of €11,000, but the delta value between PO and IR exceeds the upper absolute limit of 10 percent. The invoice is also automatically blocked for payment.  

Tolerance Key PP

The tolerance key PP in Figure 6 indicates the price difference allowed between the PO and the IR 5105600125 (created using transaction code MIRO) and the related blocking reason applied to the invoice. To set tolerance key PP follow menu path SPRO > Material Management > Logistic Invoice Verification > Invoice Block > Set Tolerance Limits.   This check verifies the price of the PO with respect to the invoice. If the price of the PO is greater than the material master standard price, the block is not performed. Thus, it is important to set the tolerance key PE.

Tolerance Key PE

The tolerance key PE indicates the price difference between the PO and material master allowed by management (Figure 7). I try to create a PO using transaction code ME21N with a material price of €11,001. This price is 10 percent higher than the standard price recorded in the Material Master Data Accounting 1 View, so the PO is blocked. To display the material master standard price follow menu path Logistics > Material Management > Material Master > Material > Display and then select Accounting 1 View.   If the tolerance key PE is not customized, when you create or change the PO price (in transaction ME21N or ME22N), the material price in the PO could be higher than the price stored in Material Master Accounting 1 View. Figure 7 shows the error message that blocks the creation of a PO with an incorrect amount greater than 10 percent if compared with the standard price stored in the Accounting 1 view of the material master data (transaction code MM03).

Integration Point: SAP BusinessObjects Process Control

When you use SAP BusinessObjects Process Control’s standard rule, you can automatically control changes to all tolerance keys shown in Figure 8 and send the issue to the control owner via workflow.  

Evaluate How to Unlock an Invoice Blocked for a Payment Procedure

Now I discuss the different ways to unlock a logistics invoice blocked for payment (also possible for a financial invoice). Figure 9 is an example of how you can unlock an invoice using the Release Manually functionality in transaction MRBR. Follow menu path Material Management > Logistic Invoice Verification > Further Processing > Release Blocked Invoices (MRBR). After you populate the Company Code and Posting Date fields and select the Release Manually indicator, the system lists all blocked invoices. To manually unlock an invoice, select a specific item referred to a vendor invoice and click the release icon (green flag).  

Security Consideration for Transaction Code MRBR

Figure 10 shows an authorization object controlled during execution of MRBR — Release Manually. If you want to manage the blocking reason authorization object for M_RECH_SPG invoices, you have to use transaction code PFCG. From a security point of view, this transaction code enables you to control users authorized to unlock invoices for specific blocking reasons.

Change Vendor Line Item

You can unlock an invoice using transaction codes FBL1N and FB02. Usually transaction code FBL1N is used as a standard report to display Vendor Open Item. However, if a user is also authorized to execute transaction code FB02, the user can automatically change the invoice from transaction code FBL1N by selecting the change icon (the pencil) and deleting the blocking reason R (Figure 11). To perform this task follow menu path Accounting > Financial Accounting > Accounts Payable > Account > Display/Change Line Items. In the section titled “Mitigation 2,” I show you how to remediate this issue.  

Change Payment Proposal

Another way to manually remove the IR Payment Block R, bypassing the three-way match control, is in transaction code F110 during the activity of change payment proposal performed by the treasury department. As shown in Figure 12, after you select the change icon in transaction code F110, the system automatically displays in red the vendor invoice blocked. After you double-click the red line item, you see the change line item pop-up screen. You can now manually delete the reason for the block. To perform this task follow menu path Accounting > Financial Accounting > Accounts Payable > Periodic Processing > Payments.   Although the reason that generates the invoice block for payment was not removed, you can manually remove the Payment block R (in Figure 12 the field Payment block is editable). In this way, the price difference is paid to the supplier. For help evaluating whether the reason for the block has been truly removed, see the section titled “Mitigation 3.” In Figure 13 I show you how the system has been incorrectly maintained, allowing you to manually release logistics invoices blocked for a delta price or delta quantities. The setting related to Blocking Reason R Invoice Verification has been set for Change in Payment proposal (transaction code F110) and Manual Payments Block (transaction code FB02) tasks. The correct setting is not changeable as explained in Figure 16. In the section titled “Mitigation 2,” I show you how to remediate this issue.

Security Consideration for the Change Payment Proposal in Transaction Code F110

What permissions are necessary in order to perform the task in Figure 12? Figure 14 shows the result of an authorization trace performed using transaction code ST01 during the execution of the task of unlocking an invoice blocked for payment in transaction code F110. In transaction code F110 > Environment > Authorization you learn the significance of the different activity codes used by authorization object F_REGU_BUK.   The object M_REGU_BUK actvt 12 must be assigned to treasury accountants, but the layout of the Blocking Reason in transaction code F110 has to be deselected to allow only an automatic background scheduled release. A manual release from transaction code MRBR should be possible only from SAP BusinessObjects Access Control 10.0’s emergency access management functionality (formerly firefighter). All other fields of transaction F110 change proposal are editable. Thus, a treasury accountant can edit a payment proposal. For example, the accountant could add in other legitimate invoices for payment owing to improved payment terms and conditions from the vendor or to take out a payment owing to disputes or cash flow management where the invoice can be deferred without loss of discounts.

Mitigation Controls

Now I describe mitigation controls over the P2P process. You can use these controls to cover the risk of money loss owing to the price or quantity variance generated by possible errors or conflicts of interest.

Mitigation 1

Using the access risk management component of SAP BusinessObjects Access Control 10.0, you can prevent a conflict of interest by analyzing segregation of duties (SoD) conflicts in your enterprise. To have proper SoD, it would be appropriate to segregate the Unlock Logistic Invoice for Payment task and Payment Execution options (Figure 15). This step avoids the risk that the invoice with Price Difference is unlocked and then wrongly or fraudulently paid by the treasury department.     To mitigate the risks of invoice overpayment, you can use SAP BusinessObjects Process Control standard automated control rule P2P overpaid POs. For more information on automated control rules, go to https://service.sap.com/instguides > SAP BusinessObjects > SAP BusinessObjects Governance, Risk, and Compliance (GRC) > Process Control > Release 3.0 > Delivered Controls and Rules.

Mitigation 2

In the second step of the mitigation phase you use the automated IT-dependent control Define Payment Block Reason for Payment Release. This standard SAP control, shown in Figure 16, prevents an invoice from being unlocked manually in transaction code F110 or in transaction code FBL1N. The layout of the field Pmnt Block is not modifiable. Follow menu path SPRO > Financial Accounting (New) > Accounts Receivable and Accounts Payable > Business Transactions- Release for Payment > Define Payment Block Reason for Payment Release.  

Mitigation 3

Another way to mitigate the risk is to restrict the possibility of releasing a blocked invoice manually using transaction code MRBR. For example, suppose that the unlock task should only be performed automatically or in the background, and that there is no way to launch it manually using transaction MRBR, FBL1N, or F110 as shown in Figure 17. Evaluate the possibility to perform the task of manual release with transaction code MRBR using SAP BusinessObjects Access Control 10.0’s emergency access management component, which is logged and monitored by a controller.   Figure 18 shows how in an SAP system you can only unlock an invoice automatically, removing the real reasons for the block.   If you leave transaction layouts deselected, then how can you remove the cause of the block? If the reason of the block is delta quantity, the IR is automatically unlocked only if a subsequent GR is posted for the missing quantity. If the reason of the block is delta price, the IR is automatically unlocked only if the IR is reversed and a new IR is posted with the same PO price, or a new subsequent credit with the same amount of delta price is posted. This method is the only way to remove the real cause of the block. For example, assume that I have a PO material price of €11,000; that is, €1,000 more than the material master standard price. In Figure 19, I try to use transaction code MIRO to post an IR where the price is €12,000; that is, €1,000 more than the PO 4500000043 price (Figure 19). The invoice is automatically blocked for payment.   What must be done in this case to unlock the invoice automatically and remove the real cause of the block? You can either reverse the invoice and post a new invoice with the same PO price (€11,000) or create a subsequent credit (€1,000) with reference to the same PO 4500000043, as shown in Figure 20. To post a subsequent credit follow menu path Purchasing > Purchase Order > Follow-on Function > Logistic invoice Verification (MIRO). Select Subsequent Credit from the transaction drop-down menu.   Now the PO price is €11,000, and the invoice price is €11,000. Note that there is no price difference between the PO and IR, even if there is a delta of €1,000 with respect to the material master data price. The invoice should be released, but you can release it automatically by selecting the indicator Release Automatically in transaction MRBR (Figure 21).   Only now is it possible to pay logistic invoices automatically using transaction code F110 (Figure 22). No red line items are proposed for payment now.  

Mitigation 4

The last mitigation step proposed is to monitor the price variance between the material master and the PO using the material ledger. If the component SAP-CO-material ledger has been activated, the price difference is tracked on a ledger specifically used for the evaluation of the material (Figure 23).   In the example in Figure 23, the material standard price is €10,000, but the price of goods received is €1,000 more for the same material. The value of the received material has been incorrectly inflated. The material ledger tracks the price difference posting automatically the amount (€1,000 in the example) on the G/L account Loss on Price Difference, in the example the G/L account number is 231500. To detect the G/L account used in you enterprise you can execute transaction OBYC, double-click Transaction Key PRD - Cost (price) differences. It’s important to monitor this G/L account as reported in the financial statements (Figure 24).