Understanding the most important Knowledge Base Articles (KBAs) about Tolerance Key, releasing logic and transaction MRBR
I hope you are fine! In my previous blog, I provided information about the ways we have to manage the field “INVFO-ZLSPR”. This is a recurrent topic about the Tolerance Key and its transaction code MRBR.
I´ve been working with different cases related to this matter and usually, our SAP KBAs have the correct answer. However, I noticed some difficulty in understanding them or just finding this in our Knowledge base. I would like to list the main KBAs and explain the issues that these ones can help you to solve.
Do you have a Tolerance Key issue? How can you start your analysis?
The first step is to be sure what is the Tolerance Key that is blocking your invoice. The recommendation is to debug the Function Module MRM_TOLERANCE_CHECK.
You will get in the variable I_TOLSL what is the tolerance key checked. In this example, it is the AP.
Checking other variables you will get further information about the reason and the logic for the blocking:
- PROZ1 = Lower Limit, percentage
- WERT1 = Lower Limit, Absolute
- PROZ2 = Upper Limit, percentage
- WERT2 = Upper Limit, Absolute
The second step is to check if the Purchase Order flag GR-Based IV is set. Believe me, this is determining!
Check in the transaction OMR6 what are the values set to the tolerance key and then check the values used in MIRO. It can explain why the Invoice is being blocked or not blocked and save you time.
There are plenty of KBAs that provide explanations for different issues related to the MRBR transaction. I will list the issues and these ones now.
Important fields and their status:
Sometimes the users are not able to understand the values of the main fields, why the field RBKP-ZLSPR is “Free for Payment”, why RBKP_BLOCKED-ZLSPR_MRM is “A” when BSEG-ZLSPR is set, etc. For these questions, this SAP note explains everything about these fields and the scenarios when they are set:
333930 – MR3M/MIR4: Display of payment block
The differences in how these fields are filled depend and how the Invoice was released (Manually or automatically). Also, when an Invoice is reversed, there is a logic to understand how the fields are kept. These KBAs explain these scenarios:
2448062 – After an invoice is cancelled the payment block remains visible
2465716 – After MRBR execution the invoice-item blocking reason is not deleted
When the Invoices may not be displayed to be released in MRBR:
These are the main reasons for this:
- Invoice is not blocked: The invoice might not be blocked in the first place. Only blocked invoices appear in MRBR for release.
- Invoice is already released: If the invoice was already released (either manually or automatically), it will no longer show up in MRBR.
- User authorization: The user might not have the necessary authorization to see and release the blocked invoices.
- Workflow issues: If the invoice is part of a workflow, it may be locked by the system or another user and hence not available for release in MRBR.
Important: The invoices that are not available in the table RBKP_BLOCKED are not displayed to be released.
Common issues when the Invoices are not released automatically by MRBR
Initially, it is important to understand when the Invoice can be released automatically. For using this option, the blocking reason needs to be active, otherwise, the Invoice will not be proposed to be released. Once the block reason still exists the option needs to be “Release Manually”.
In this case the message M8 654 “There are no invoices that match your selection” is displayed.
In other cases, the Invoice that is expected to be released by MRBR (Release Automatically or Manually) is not being selected because:
- The blocking was manually set in the PO Item (PO Reference Tab), field DRSEG-SPGRQ
- the blocking was set through an FI substitution
- or, the invoice was blocked using transaction FB02.
For these cases, the blocking is not valid on the MM side for Automatic Release.
The `DRSEG-SPGR` field indicates whether a document line item has been blocked for payment. If an invoice is blocked for payment, you must remove the block before the invoice can be paid. For this document, only selecting the “Release Manually” option in the MRBR will work.
For Invoices blocked for payment by FB02, the Invoice needs to be released directly on the FI side by FB02, or transaction code F-44 is used for clearing open items in Vendor Accounts. It is part of the Financial Accounting module.
Also, an authorization issue could be the root cause. For this, I recommend reading this KBA below, which also is recommended when the errors M8657 and M8398 happen:
2103443 – MRBR does not return all the blocked invoices – SAP ERP & S/4 HANA
Important to know is that transaction MRBR only releases Invoices that were blocked due to a tolerance Key which is set in the OMR6, and then the Invoice will be updated in the table RBKP_BLOCKED. Transaction MRBR reads this table.
I recommend these KBAs about this topic:
1790472 – MRBR – Invoices not released automatically – SAP ERP & SAP S/4 HANA
1933251 – MRBR: determination logic for quantity variance – SAP ERP & SAP S/4 HANA
Aren´t all Invoices being displayed when you run MRBR?
There could be several reasons why not all items are returned to be released:
- Date Range: The selection parameters you’ve entered might not cover the date range for all blocked invoices. You need to ensure that the “Posting Date in the Document” covers the date range for all blocked invoices you’re looking to release.
- Document Type: If you have specified a document type in the selection parameters, only blocked invoices of that type will be displayed.
- Company Code/Purchasing Document: If you have specified a specific company code or purchasing document, only blocked invoices for that company or purchase will be displayed.
- Vendor/Customer: If you’ve specified a specific vendor or customer, only their blocked invoices will be displayed.
- Invoice Block Reason: If you’ve specified a specific block reason, only invoices with that block reason will be displayed.
- Processing Status: Only invoices with blocked status are displayed in transaction MRBR. If an invoice has been released or has a different status, it won’t be displayed in MRBR.
Also, some error messages can be displayed as M8657 and M8398. For these ones, some missing authorization to the user could be the reason.
These authorizations determine what actions a user can perform within the system. They can be set at a very granular level, allowing administrators to control access to specific functions, transactions, or even individual fields.
The impact of user authorization on the results of an MRBR transaction could potentially be significant. Here are a few ways it could affect the results access to transactions, access to the MM Invoices, and access to Actions.
These KBAs help to identify some root causes and missing authorization that cause this issue:
2103443 – MRBR does not return all the blocked invoices
2536721 – MRBR no invoice displayed
2103402 – MRBR shows message M8657 after the selection screen
2145211 – MRBR – Missing authorization check in object F_LBA_BEK – SAP ERP & SAP S/4 HANA
The Influence of Purchase Order Flag GR-Based IV
Another common issue is when the Invoice is blocked for Quality inspection. It is expected that an Automatic release is possible. However, this only works when the GR-Based IV flag is set in the Purchase Order. If not, only using the option “Manual release” will work. Further information in this SAP KBA:
1879336 – MRBR – Automatic release not working for quality inspection
Another scenario related to the GR-Based IV flag is reported in this KBA below, where the invoice is blocked due to tolerance Key DW, and because of the flag situation, it was possible to release the Invoice Automatically. This was not expected! The issues related to MRBR are really tricky, don´t you think? 🙂
2523517 – MRBR automatic release DW tolerance
Another similar scenario, now related to the Scheduling Agreement, and guess the reason? Yes, the GR-Based IV flag is the guilty one. My hint is: Always check if the flag is set or not in the Purchase Order, it could avoid the headache of trying to find an explanation for the release process.
3038006 – MRBR automatic release for scheduling agreement invoice
Do you want to know more about the importance of this flag, I invite you to visit this blog:
Determination Logic for Quantity Variance
The “Determination Logic for Quantity Variance” refers to the process of identifying and assessing differences between the quantity of goods received and the quantity of goods invoiced in the logistics invoice verification stage.
The main tolerance key is DQ. The system can be set up to automatically block invoices for payment if the quantity variance exceeds a certain tolerance level. The tolerance levels are usually predefined in the system based on the company’s specific policies and requirements. This way, the system can help prevent payments for incorrect invoice amounts.
In many cases, this logic is not understood. These KBAs below provide important information about this:
1933251 – MRBR: determination logic for quantity variance – SAP ERP & SAP S/4 HANA
2055131 – Invoice posted for more than the quantity delivered and GR-Based IV is set or not
Also, SAP provides good Guided Answers about quantity tolerance, you can go through this in your investigation about the errors:
Determination Logic for Price Variance:
The determination logic for price variance and tolerance key PP works like this:
- When an invoice is received, the system calculates the price variance by comparing the invoiced amount with the purchase order or contract amount.
- The system then checks whether the price variance exceeds the threshold defined by the tolerance key PP.
- If the price variance is within the acceptable range, the invoice is processed normally. If not, the system will automatically block the invoice for payment.
The blocked invoice would typically then be flagged for review so that someone can check the discrepancy and decide whether to release the invoice for payment or take some other action.
These KBAs explain some known causes for some issues where the tool.key PP is not working as expected:
1997545 – MIRO/MIR7: Pricing block not issued accordingly (PP)
2562758 MIRO: PP tolerance key is not checked – SAP ERP & SAP S/4HANA
The invoice is released automatically but this shouldn´t, what is the reason?
The invoices were blocked and when you run MRBR with the Automatically Release flag set, some invoices were released. You want to understand why because according to your understanding, this shouldn´t be released.
Well, there are some reasons, and probably the blocking reason of the invoice is not valid anymore. It can happen if was posted a Goods Receipt or even an Account Maintenance document. This KBA provides further information:
2846141 – MRBR – Invoice is released for payment after account maintenance document or partial goods receipt created
Amount Tolerance issue with AN and AP
Tolerance AN and AP can cause issues when the logic is not understood. Tolerances can be set for h Accounts Payable (AP) and Accounts Receivable (AN):
AP (Accounts Payable) tolerances include:
- Small differences
- Quantity variances
- Price variances
AN (Accounts Receivable) tolerances include:
- Payment differences
- Cash discount
These tolerances are defined in the configuration (SPRO). For AP, they can be found under:
-> Materials Management -> Logistics Invoice Verification -> Incoming Invoice -> Set Tolerance Limits. For AN, they can be found under Sales and Distribution -> Basic Functions -> Credit and Risk Management -> Credit Management/Risk Management Settings -> Define Automatic Credit Control.
This KBA provides more information about the required settings to use these tolerances:
2540351– MIRO: Amount tolerance is not working as expected.
For further information about all tolerance keys available, I recommend you double-check these blogs:
Alright, folks, that’s all for now. I’m off to enjoy a cup of hot cocoa now. Did you enjoy this post?
Don’t keep it to yourself! Go ahead and share it with your colleagues and partners. Sharing is caring, after all 🙂 And of course, drop me a comment below, and let’s chat! Stay awesome, and see you in the next post! 😉