SAP Price Variance Tolerance Is Not Working: Why
Your SAP price-variance tolerance is blocking the wrong invoices, or none at all. The usual causes: the limits, the message type, or the wrong tolerance key.
You set a price-variance tolerance in SAP so the system would catch an overbilled invoice, and now an invoice has posted at a price well above the purchase order — paid, cleared, no block, no message. Or the opposite: every invoice lands blocked, including the ones that match the contract to the cent, and your AP team releases them by hand all day. Either way the verdict in the room is the same — “the tolerance isn’t working.” It almost always is working, on the key and the limits it was actually given, which are rarely the ones you assume. A price-variance check in SAP is not one switch. It is a tolerance key, a pair of limits held per company code, and a message type that can be quietly turned down to a note that never blocks. When any one of those is set wrong, the check does exactly what it was configured to do — and from the outside it looks broken.
Where the tolerance is actually decided
The check you think is failing is spread across three places, plus a fourth where it is confused with a different check entirely.
| Where it lives | Transaction | What it controls — and how it fails silently |
|---|---|---|
| Price-variance limits (key PP) | OMR6 (per company code) | The upper and lower limits. Set to `Do not check`, or set too wide, and a real overbilling passes by design |
| Message type for M8 082–085 | OMRM | The type is configurable. Turned into an information message, SAP logs the variance but never blocks |
| The variance itself | — | May be an order-price-quantity breach (M8 090–092) on keys BR / BW, not a PP price breach at all |
| Upper vs. lower limit | OMR6 | Above the upper limit blocks for payment; below the lower limit only issues a message — no block |
| Release of what is blocked | MRBR (RM08RELEASE) | Not where blocking is decided, but a standing mass release can mask that PP is firing correctly |
Before you touch a single limit, settle which of these five is in play. A tolerance that lets everything through and a tolerance that blocks everything are often the same misconfiguration read from opposite ends — and neither is fixed where people look first.
Before and after: a tolerance that only looks broken
| Tolerance looks broken | Tolerance set to actually check |
|---|---|
| Overbilled invoice posts and pays — limits left at `Do not check` | Upper limit on key PP set to a real value, so the overbilling blocks for payment |
| M8 083 downgraded to an information message in OMRM — logs, never blocks | Message type restored to one that blocks the invoice for payment on breach |
| Correct invoices all block — the breach is really order-price-quantity on BR / BW | Conversion factor corrected at the source; PP left strict, BR / BW handled separately |
| PP widened to stop the blocks, so genuine errors now slip through too | PP left strict; the one phantom variance fixed at the purchase-order item instead |
| AP releases the same variance in MRBR every month | Root cause fixed once; the next invoice on that PO posts clean |
Diagnose the key before you widen it — do not just loosen the tolerance
- 1Read the message number, not just the block
Price too high (tolerance limit of & & exceeded)(M8 082, an absolute amount-and-currency limit) andPrice too high (tolerance limit of & % exceeded)(M8 083, a percentage limit) are genuine price-variance breaches on key PP;Price too low (below tolerance limit of & &)(M8 084) andPrice too low (below tolerance limit of & %)(M8 085) are the lower-side versions. Messages in the M8 090 to M8 092 range are not price messages at all. They need opposite fixes. - 2Confirm PP is even checking
In OMR6 for the company code, check that the PP upper limit is not set to
Do not checkand not set absurdly wide. A tolerance that never blocks usually has nothing wrong with it except the number it was given. - 3Check the message type in OMRM
SAP issues message M8 083, whose type is configurable — commonly a warning that blocks the invoice for payment rather than preventing posting. If it was changed to a non-blocking information message, it records the variance but never holds the invoice. M8 516’s long text confirms that message types 082–085 are changeable in Customizing for Invoice Verification.
- 4Confirm it is a price breach, not units
SAP computes the invoice price as invoice value divided by invoice quantity and compares it against the net order price. Recompute it by hand; if the amount is right but the quotient is wrong, the fault is an order-price-quantity variance (M8 090 to M8 092), which runs on keys BR and BW — see the error says price, the cause is units. You can also compare the invoiced price against the agreed price file to rule the price itself in or out first.
- 5Fix the source, not the gate
Correct the limit, restore the message type, or fix the conversion factor. To force a block on any variance, set the absolute upper limit to zero with
Check limitselected — do not widen PP to make a block go away.
Build a price-variance tolerance checklist into your invoice verification
Why identity resolution is the real fix
A tolerance that “isn’t working” is rarely a broken limit; it is a check comparing two numbers that were never on the same footing — a price measured against a quantity, a unit, or a contract that no longer line up. Loosen the gate and real errors pass; tighten it and correct invoices jam. The durable fix is to resolve every invoice line to one trusted record whose price, units, and conversion factors are known and consistent, so the tolerance compares like with like and only fires on a genuine overbilling — which is the whole job of reconciling each invoice line against trusted catalog data. Set identity right once and the tolerance stops crying wolf.
Related
Free tool
Price List Diff
Compare an invoiced price against the agreed price file to confirm whether the price itself actually moved.
Tool
Margin and Markup Calculator
Check what a tolerated price variance really costs once it reaches margin.
Tool
Unit and Dimension Converter
Confirm a conversion factor when a price block turns out to be an order-price-quantity problem.
Guide
The Error Says Price. The Cause Is Units.
The flagship: when a price block is really an order-price-quantity variance on keys BR / BW.
Guide
Order Price Quantity Variance: M8 090, 091, 092
The messages and keys behind a variance that looks like price but is quantity.
Guide
SAP M8 534 Balance Not Zero: BD, Not AP
Why small differences need tolerance key BD, not the amount keys people reach for.
Playbook
Map Supplier Attributes to Your Schema
Resolve supplier prices, units, and conversion factors onto one canonical product model.
Glossary
Invoice Price Variance Explained
The M8 082–085 message family and what SAP is actually comparing when it blocks.
FAQ
What is a price-variance tolerance in SAP?
A price-variance tolerance is the limit SAP uses to decide whether the price on a supplier invoice differs too much from the net order price to pay without review. It is held on tolerance key PP, maintained per company code in transaction OMR6, with an upper and a lower limit that can each be absolute (an amount and currency) or a percentage. SAP computes the invoice price as the invoice value divided by the invoice quantity and compares it against the net order price. Exceed the upper limit and the whole invoice is blocked for payment; fall below the lower limit and SAP issues a message but does not block.
Why is my SAP price tolerance not blocking an overbilled invoice?
There are three common causes. First, the limits on key PP are set to Do not check, or set so wide that a real overbilling still falls inside them, so the check passes by design. Second, the message type for the relevant message was changed in Customizing to a non-blocking information message, so SAP logs the variance but never blocks. Third, the breach is below the lower limit rather than above the upper one, and the lower side only issues a message. Check OMR6 for the limits and OMRM for the message type before concluding the tolerance is broken.
What is the difference between tolerance keys PP and BR or BW?
Key PP is the price-variance key: it compares the invoice price against the net order price. Keys BR and BW are order-price-quantity keys: BR applies when the invoice arrives before goods receipt and BW when goods receipt comes first, and both compare the order price quantity rather than the price itself. An order-price-quantity breach surfaces through messages M8 090 to M8 092 and runs on BR or BW, not on PP, so widening PP will never clear it. Identifying which key is actually firing is the first step, because the two problems need opposite fixes.
How do I force SAP to block any price variance?
Set the absolute upper limit for the key to zero with Check limit selected in OMR6 for that company code. With a zero upper limit and the check active, any variance above the order price exceeds the limit and SAP blocks the invoice for payment. Setting all limits for a key to Do not check does the opposite: it accepts any variance. Remember that the entire invoice is blocked for payment even if only one item shows a variance, so a zero tolerance across a busy company code will route a large share of invoices to manual release.
Where do I release an invoice that the tolerance blocked?
Blocked invoices are released in transaction MRBR, Release Blocked Invoices; the background release program is RM08RELEASE. Releasing an invoice there clears the payment block so the document can be paid, but it does nothing about the root cause, so the next invoice on the same purchase order blocks the same way. If you are releasing the same variance repeatedly, the durable fix is to correct the limit, the message type, or the conversion factor behind it rather than to keep releasing by hand.
REVIEW-NOTES
- Hub wiring, partly deferred. This is an ERP-error guide, so it links inline to the flagship
error-says-price-cause-is-units(exists) and Card-links the cluster siblingssap-order-price-quantity-variance,sap-balance-not-zero-m8-534and the glossaryinvoice-price-variance. Those three siblings do not exist yet — they are Card links only (not audit-checked), so the build stays green, but they are live broken links until the siblings ship. Re-check on the final cross-link commit (brief Workflow step 6); the paired glossaryinvoice-price-varianceshould link back here. - Accuracy trace. Every message number (M8 082/083/084/085 price-variance, M8 090–092
order-price-quantity, M8 516 confirming types 082–085 are configurable) and every key (PP for
price; BR/BW for order price quantity) and transaction (OMR6 limits, OMRM message control, MRBR /
RM08RELEASE release) traces to the brief appendix. Ampersand placeholders preserved:
& &(amount+currency) on 082/084,& %(percentage) on 083/085. Message type stated as configurable, never as “SAP throws M8 083”. “Invoice price differs from order price” is deliberately not used as a short text (it is a paraphrase of the M8 083 long text). M8 081 is not quoted, so no SE91 spot-check applies to this file.
Claro
Stop maintaining this by hand
Claro keeps product and supplier data trusted as catalogs change — matching, deduplication, enrichment, and validated write-back into the systems you already run.
Book a demo