Invoice Blocked for Price Variance
An invoice is blocked for price variance when the price on the incoming invoice differs from the purchase order (or goods receipt) price by more than the tolerance configured for the relevant tolerance key. The invoice still posts financially but is held from payment until someone in MRBR releases it or the underlying price is corrected.
Covers why invoice verification blocks a document on price variance rather than quantity, the tolerance key configuration and PO price staleness issues that usually cause it, and the check sequence across MIR4, ME23N and OMR6 needed to tell a legitimate price change from a data entry or tolerance misconfiguration. Also covers the release-without-investigation reflex that defeats the control.
Published 16 Sept 2026· 1,092 words
The business symptom
Accounts payable reports that an invoice has posted but is sitting blocked and cannot be paid, and the vendor is calling or emailing about an overdue payment that finance insists has been entered. The buyer is asked to approve a release without being told why the system stopped it. Sometimes the complaint arrives from the vendor's side first, as a payment query, before anyone internally has looked at the invoice. Finance frequently assumes it is a duplicate invoice or a missing goods receipt, because that is the more familiar block. When someone finally opens the invoice they see it flagged for payment block with a price variance reason, and nobody on the AP team is sure whether it is safe to release, whether the PO price is wrong, or whether the vendor overcharged.
The configuration behind it
- Genuine price variance exceeds the tolerance limit set for tolerance key PP (or the relevant percentage/absolute key) for that company code and vendor tolerance group, and the block is doing exactly what it was configured to do.
- Tolerance keys not maintained for the company code, or maintained with a zero or near-zero limit, so effectively every variance above a trivial amount blocks, even minor rounding differences.
- PO price is stale: a price change was agreed with the vendor or updated in the info record but never pushed into the open purchase order via a price change, so the invoice arrives at the new price and looks like a variance against the old PO condition.
- Small-differences tolerance key (covering minor absolute deltas) is set too tight, so rounding or currency conversion noise on high-volume, low-value lines trips the block repeatedly.
- Invoice verification is set to check against the goods receipt value rather than the PO value, and the GR was posted at a different price (common with moving average price plants or a GR posted before a price change), so the variance is against the wrong reference.
- Currency or exchange rate mismatch between the PO currency and the invoice currency, where the exchange rate used at invoice entry differs from the rate implied on the PO, pushing the calculated variance over the exchange rate tolerance key.
- Vendor invoices in a different price unit or unit of measure than the PO price basis (per each versus per hundred, for example), producing an artificial variance that has nothing to do with the actual agreed price.
- Multiple partial deliveries or invoices against the same PO item accumulate small variances that individually would pass but collectively exceed the tolerance evaluated at the item level.
What to check
- MRBR: list the blocked invoice, note the exact block reason (price variance versus other release reasons) and the variance amount shown.
- MIR4: display the invoice document, open the item detail to see PO price, invoice price, and quantity, and confirm which line triggered the block.
- ME23N: display the purchase order item, check the net price, condition validity dates, and whether a later price change exists that was never applied to this PO.
- MB03 or MIGO display mode: check the price actually posted at goods receipt if the plant is moving average, since GR value may differ from current PO price.
- OMR6: review the tolerance key limits configured for the company code and compare against the actual variance percentage and absolute amount.
- Check the invoice currency and exchange rate entered against the PO currency and rate, and check the price unit and order unit on the PO item versus the invoice line.
How to prove it in the data
Pull the blocked invoice list from MRBR filtered by company code and date range, then for each line compare invoice price, PO net price, and GR price side by side with the variance amount and the applicable tolerance limit. Grouping by vendor or material shows whether the block is a one-off entry error or a recurring pattern against a PO that was never repriced, which is the fastest way to separate a tolerance configuration issue from a purchasing data issue.
Resolution path
If the price genuinely changed and the PO simply was not updated, this is a data fix: correct the PO price with a price change in ME22N, or process a subsequent debit or credit if the goods have already moved, then release the invoice in MRBR once the price is aligned. If the invoice was keyed with the wrong price, quantity, unit of measure, or exchange rate, correct the invoice itself in MIR4 rather than releasing it blind. If the tolerance key limits are the actual problem, either too tight and generating noise or too loose and letting real overcharges through, that is a configuration change in the tolerance key settings, requires a transport, and should not be changed unilaterally by AP since it affects the control environment for every vendor in that company code. If the vendor is consistently invoicing above the agreed price, the fix is commercial: get a credit memo or renegotiate the PO price with purchasing, not a repeated manual release.
The fix people try first (and why it fails)
The reflex is for AP to release the invoice in MRBR to stop the vendor complaint, without checking whether the PO price, the invoice price, or the tolerance setting is the one that is wrong. This clears the immediate payment pressure but pays whatever price the invoice states, which may be an overcharge, and it leaves the underlying mismatch in place so the same vendor's next invoice blocks again. Repeated blind releases also erode the audit value of the control, since a reviewer can no longer distinguish a genuine tolerance breach from routine release-without-review.
Whose problem this is
Accounts payable owns the release decision and the vendor communication. Purchasing owns keeping PO prices current against agreed terms. Finance or controlling owns the tolerance key configuration. The handover note should carry the invoice and PO number, the item, the variance amount and percentage, the tolerance key involved, and whether the determined cause is a stale PO price, a data entry error, or a tolerance setting.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/invoice-blocked-for-price-variance-in-mmERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.