SAP MIRO: invoice blocked for price variance, and how to release it in MRBR
SAP MIRO invoice blocked for payment price variance, how to release in MRBR
Also searched as
- SAP invoice blocked due to price variance MIRO
- SAP MRBR release blocked invoices
- SAP tolerance keys OMR6 PP PE DQ
Short answer
MIRO blocks an invoice for payment when its price or quantity differs from the PO or goods receipt by more than the tolerance limits defined in OMR6. The invoice posts, but it carries a payment block reason (R for price) until someone releases it in MRBR or corrects the underlying data. Release only after confirming which side is wrong.
Applies to: SAP ECC 6.0 and S/4HANA, logistics invoice verification (MIRO, MIR7, MRBR)
Find and release a blocked invoice
- 1In MIRO or MIR4, display the invoice and open the Payment tab. A payment block reason such as R (invoice verification) indicates a stochastic or tolerance block. Note the item and the PO.
- 2Open MRBR (Release Blocked Invoices). Select the block reason (price, quantity, date, manual, stochastic) and enter the company code and a date range, then execute.
- 3Review the list: for each invoice check the invoiced price against the PO price (ME23N) and the goods receipt quantity (MIGO or ME23N PO history).
- 4If the vendor is right and the PO price is outdated, correct the PO price via a price change, then release the invoice. If the vendor is wrong, reject it and ask for a credit note instead of releasing.
- 5Select the invoice and use the Release function. The payment block is removed from RBKP and the item becomes payable in the next payment run (F110).
- 6If you need to prevent the same block next time, check the tolerance keys in OMR6 for the company code and compare the limits with the real deviation.
- 7Use MR8M only to cancel an invoice document, not to clear a block. Cancelling and reposting is the wrong tool for a tolerance block.
How tolerance keys decide a block
In OMR6 (SPRO > Materials Management > Logistics Invoice Verification > Invoice Block > Set Tolerance Limits) each tolerance key has absolute and percentage limits, upper and lower. Key PP is the price variance on a purchase order item, DQ is quantity variance when there is no goods receipt reference, and BD and BR cover form-of-delivery date and order price quantity variance. If a key has no limit set, the system treats any variance as blocking, which surprises people after a new company code is created.
The check happens when you post in MIRO. Variances inside the tolerance post normally, those outside are posted with a block on the item. Stochastic block (a random sample, key ST) is separate: it blocks a share of invoices regardless of variance, so a block on a perfectly matching invoice may just be the sample.
-- Blocked invoice headers and item block flags
SELECT BELNR, GJAHR, LIFNR, RBSTAT, ZLSPR
FROM RBKP WHERE ZLSPR = 'R';
Choosing between release, price correction and rejection
Release is correct when the invoice is legitimate and the difference is small or already agreed, for example a surcharge agreed by phone. A release does not change the PO, so the same variance will recur on the next invoice.
If the vendor price has genuinely changed, update the PO price or the info record and conditions first. That makes the next invoice match, and avoids the repeated manual work. For long-term prices, fix the source: info record, outline agreement or scheduling agreement conditions in ME12 or ME32L.
If the invoice is wrong, do not release it. Request a credit memo, and post it with MIRO as a credit memo or subsequent debit/credit with the right tolerance handling. Keep the audit trail: who released what and why.
Quantity blocks and the GR/IR link
A quantity block (reason Q or a manual block) usually means the invoiced quantity exceeds the goods received. The system compares against EKBE history for the item. If goods are still on the dock and not yet booked, the invoice is correctly blocked until the goods receipt is posted in MIGO, at which point MRBR will let it go.
Large amounts of blocked invoices usually signal a receiving process issue, not an accounting one. Look at the pattern by plant before changing tolerances.
Authorizations and controls
Release in MRBR is protected by authorization object M_RECH_BUK (company code) and the invoice release activity. Segregation of duties matters here: the person who enters invoices should not be the person who releases variance blocks. Review the authorization with your internal auditors rather than relaxing it to clear a backlog.
Common pitfalls
- !Releasing invoices in bulk to clear a backlog without checking each variance.
- !Setting wide tolerances in OMR6 to stop blocks, which lets overbilling through unseen.
- !Leaving a tolerance key undefined, which makes every variance blocking for that company code.
- !Cancelling and reposting the invoice with MR8M instead of releasing it, creating extra documents and duplicate-invoice warnings.
- !Treating a stochastic block as a data problem when it is a random sample by design.
How an ERP-grounded AI assistant handles this
A grounded assistant can build the review list for you: pull blocked invoices from RBKP and RSEG, compare each invoice price against the PO price and goods receipt quantity in EKPO and EKBE, and group them by cause such as price, quantity or sample. It shows the query behind each number. Releasing in MRBR remains a human action under your authorization concept.
Frequently asked questions
Why is my invoice blocked in MIRO even though it posted?
Because the variance against the PO or goods receipt exceeded a tolerance in OMR6, SAP posts the invoice but sets a payment block on it. It remains unpaid until it is released in MRBR or the underlying data is corrected. A stochastic block can also hold invoices that matched exactly.
What is the difference between MRBR and MR8M?
MRBR releases invoices that carry a payment block so they can be paid. MR8M cancels an invoice document entirely, reversing its postings. Use MRBR for tolerance and quantity blocks, and MR8M only when the invoice itself must be undone.
How do I stop the same price variance recurring?
Fix the source of the price: update the info record, contract or scheduling agreement conditions so future POs carry the new price. Widening tolerance limits hides the symptom and also lets real overbilling through, so treat it as a last resort for small, understood differences.
Which table shows the block reason on an invoice?
The invoice header table RBKP holds the document status and payment block, and RSEG holds item data including the item-level block indicators for price, quantity and date. Use SE16N or an ABAP query to list blocked invoices with these fields when you need a quick overview.
Related
SAP GR/IR clearing account balance: reconcile with MB5S and clear with MR11
The GR/IR clearing account holds the value of goods received but not yet invoiced, and invoices not yet matched with receipts. It should trend to zero per PO item. Reconcile it with MB5S, find the PO items that are stuck, and clear true differences with MR11 or automatic clearing in F.13, after correcting the cause.
How-toSAP ME21N: why the release strategy is not determined on a purchase order
When a purchase order saves without a release strategy, no strategy in the release group matched the PO's characteristic values. Compare the PO header values (value, document type, purchasing group, plant) against the value ranges in the strategy classification (CL24N), and check that the release group and code are active for the PO document type.
How-toSAP open purchase orders report: ME2N, ME2M, ME2L and the underlying tables
Use ME2N for a flexible open PO list, ME2M by material and ME2L by vendor, with the selection parameter Still to be delivered. The open quantity is the scheduled quantity in EKET minus goods received in EKBE, excluding deleted and delivery-completed items. For custom reports, read EKKO, EKPO, EKET and EKBE.
Error fixSAP M7 021: Deficit of SL Stock Quantity
M7 021 fires during a goods issue, delivery, or confirmation when SAP checks the unrestricted-use (SL) stock for the exact plant, storage location and batch combination and finds less than what you are trying to post out. Fix the entry (batch, storage location, quantity) first; only enable negative stock or downgrade the message to a warning if the business genuinely needs to post ahead of a receipt.
Error fixSAP IDoc Status 51: Application Document Not Posted
Status 51 tells you the IDoc reached the application layer and failed to post, but the status text itself is not the error - the real cause sits in the status record's long text or the linked application log. Fix the underlying data or configuration, then reprocess the IDoc through BD87 rather than editing the status.
Error fixSAP Short Dump TIME_OUT: Maximum Runtime Exceeded
A TIME_OUT runtime error means a dialog (or RFC) work process ran longer than the maximum allowed runtime, controlled by profile parameter rdisp/max_wprun_time (600 seconds by default). The fix is almost always to move the long-running work to background processing or tune the underlying program, not to raise the timeout.
AI for ERPAI for SAP S/4HANA, Running On-Prem or in Your Private Cloud
Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.
AI for ERPAI for SAP Business One, Without Sending Your Books to a Public API
Add AI to SAP Business One without sending customer data or financials to a public API. Service Layer and DI API integration, sized for an SMB budget.
Stuck on SAP ECC / S/4HANA?
Talk to engineers who work inside SAP ECC / S/4HANA every week, and who build private AI that answers these questions from your own ERP data.