Order Price Quantity Variance: M8 090, 091, 092
SAP messages M8 090, 091 and 092 block an invoice for an order price quantity variance. Why the price is fine, how keys BR and BW decide it, and how to fix the factor.
An invoice for a part you buy by the reel, but the vendor prices per metre, lands in your MIRO queue. SAP first nudges you with a warning that it set the order price quantity for you; then, on the same document, it blocks the invoice outright under Order price quantity exceeded by more than & %. You pull the purchase order and check the figure against the contract — and the unit price matches to the cent. Nothing on the price condition has moved. Yet SAP is holding the whole invoice for payment, and the message talks about quantity, which is somehow worse, because the quantity reconciles cleanly against the goods receipt you already posted. You are now one wrong assumption away from opening a vendor dispute over an invoice that is correct. The number at fault is not on the invoice and not on the price condition — it is a conversion factor buried on the PO item, and this is how to find it and stop it from recurring.
Where order price quantity variance actually hides
The messages all point at quantity or price, but they are all downstream of one derived figure: the order price quantity SAP computes for itself.
| Where it hides | What you see | What actually moved |
|---|---|---|
| Posting warning in MIRO | `Please check: order price quantity set automatically` (M8 090) | SAP derived the order price quantity from the PO conversion factor × invoice quantity and wrote it into the Quantity OPUn field |
| Payment block at posting | `Order price quantity exceeded by more than & %` (M8 092) | The derived order price quantity exceeded the upper limit; the invoice blocks with reason order price quantity variance |
| Lower-side check | `Quantity more than & % below order price quantity` (M8 091) | The derived quantity fell below the order price quantity by more than the allowed percentage |
| PO item conversion | An invoice that is correct to the cent still blocks | A transposed BPUMZ / BPUMN factor on the item inflated or shrank the order price quantity |
| Tolerance config in OMR6 | Widening key PP releases nothing | The variance runs on keys BR and BW, not the price key PP |
SAP says it plainly in the M8 090 long text: a changed order price quantity creates a price variance, because the invoice price is the invoice amount divided by the order price quantity. That one sentence is why a units fault wears a price label — the same misdiagnosis the flagship guide to this problem traces across SAP, Dynamics 365 and Business Central.
Before and after: chasing the price vs. fixing the factor
| Chasing the price | Fixing the factor |
|---|---|
| Buyer opens a dispute over a price the vendor billed correctly | Invoice released once the conversion factor is corrected — no vendor contact needed |
| Key PP widened to stop the blocks | PP, BR and BW all left strict; the BPUMZ / BPUMN factor fixed instead |
| Each M8 092 worked one invoice at a time, forever | Factor corrected once at the item; every future invoice posts clean |
| Quantity OPUn overwritten by hand on the document | The factor set so the order price quantity derives correctly on its own |
| The variance logged as a recurring price error in reporting | Recorded as a unit-conversion fix, where it belongs |
Trace the message to the factor — do not just raise the tolerance
- 1Read the message number, not just the block
Please check: order price quantity set automatically(M8 090) is a warning that SAP derived the quantity for you.Order price quantity exceeded by more than & %(M8 092) is the block. Both are message class M8, whose type is configurable — commonly a warning that blocks the invoice for payment rather than preventing posting. They are not price-tolerance messages, so do not treat them as one. - 2Recompute the invoice price the way SAP does
Divide the invoice amount by the order price quantity in the Quantity OPUn field. If the amount is right but the quotient is wrong, the order price quantity is the fault — not the price condition.
- 3Work out which comparison base applies
If goods receipt posted first, SAP compares against the order price quantity recorded at goods receipt (key BW). If the invoice arrived first, it compares against the invoice quantity × the PO conversion factor (key BR). Knowing which document led tells you which figure to trust.
- 4Check the PO item's conversion factor
Compare the order price unit (BPRME) against the order unit (MEINS), and the BPUMZ / BPUMN factor that converts between them, against the material master and info record. A single transposed numerator and denominator produces a phantom variance. The order price unit glossary entry explains each field, and a unit and dimension converter confirms the factor in seconds.
- 5Fix the factor, not the tolerance
Correct BPUMZ / BPUMN on the PO item and info record so the order price quantity derives correctly, then leave the tolerance keys BR, BW and PP strict. They are doing their job.
Build an order-price-quantity checklist into your invoice matching
Why identity resolution is the real fix
An order price quantity variance is an identity problem wearing a price label: SAP cannot line up the unit the vendor priced in with the unit you order, receive and pay in, so it derives a quantity and divides against it. Fix one invoice in MRBR and the next one for the same item fails identically, because the factor on the record is still wrong. The durable fix is to resolve each supplier item to one trusted record whose order unit, order price unit and conversion factor are known and consistent, then check every invoice line against it — which is exactly what reconciling invoices against trusted catalog data does, and why the block stops recurring instead of being released over and over.
Related
Free tool
Unit and Dimension Converter
Confirm a BPUMZ / BPUMN conversion factor and check a per-unit price divides against the right quantity.
Tool
Price List Diff
Compare an old and new supplier file to catch a changed unit or factor before it reaches an invoice.
Tool
UNECE Rec 20 Unit Code Validator
Check that unit strings map to valid standard codes so order and price units stay comparable.
Guide
The Error Says Price. The Cause Is Units.
The flagship: the same root cause across SAP, Dynamics 365 and Business Central.
Guide
SAP Price Variance Tolerance Is Not Working
When the block really is a price-tolerance breach on key PP — M8 082 and M8 083.
Guide
Invoice Quantity Greater Than Goods Receipt (M8 081)
The quantity-variance sibling, on keys DQ and DW rather than BR and BW.
Playbook
Map Supplier Attributes to Your Schema
Map supplier units and conversion factors onto one canonical product model.
Glossary
Order Price Unit vs Order Unit
BPRME, MEINS and the BPUMZ / BPUMN factor — this guide's glossary pair.
FAQ
What is an order price quantity variance in SAP?
An order price quantity variance is a mismatch between the order price quantity SAP expects and the one it derives at invoice time — not a mismatch in the price itself. SAP calculates the invoice price as the invoice amount divided by the order price quantity, and it derives that quantity from the PO conversion factor multiplied by the invoice quantity. When the factor is wrong, the derived quantity moves, the computed invoice price moves with it, and SAP raises a message in the M8 090 to M8 092 range, blocking the invoice with the reason order price quantity variance even though the agreed price never changed.
What does SAP compare the order price quantity against?
It depends on which document posts first. When goods receipt is posted before the invoice, SAP compares against the order price quantity recorded at goods receipt. When the invoice arrives before goods receipt, it compares against the invoice quantity multiplied by the PO conversion factor. Those are the two bases named in the M8 091 and M8 092 long texts, and they are why the variance is checked on two separate tolerance keys — BR when the invoice comes first, BW when the goods receipt does.
Why will raising the price tolerance not clear an M8 092 block?
Because the order price quantity variance behind M8 092 does not run on the price tolerance key PP. It runs on BR (invoice before goods receipt) or BW (goods receipt before invoice), both maintained separately in OMR6. Raising PP loosens the price gate while the order-price-quantity gate keeps firing, so M8 092 keeps blocking with the reason order price quantity variance. Correct the conversion factor on the PO item instead; the tolerance is not the problem.
Can a correct invoice trigger an order price quantity variance?
Yes, and it is the most common cause. A transposed or wrong BPUMZ/BPUMN conversion factor on the PO item produces a phantom order price quantity variance on an invoice whose amount is exactly right. Per the M8 090 long text, a changed order price quantity creates a price variance, because the invoice price is the invoice amount divided by the order price quantity — so the message surfaces as a price block while the real fault is the unit conversion underneath it.
Where do I release an invoice blocked for order price quantity variance?
Blocked invoices are released in transaction MRBR, and the tolerance keys behind the block are maintained in OMR6 per company code. But releasing the block only clears the one invoice in front of you, and the entire invoice is blocked for payment even if only one item shows the variance. Until you fix the BPUMZ/BPUMN factor on the item, every future invoice for that part blocks the same way, so release is a workaround and the factor correction is the fix.
REVIEW-NOTES
- Accuracy. Every message (M8 090, M8 091, M8 092), tolerance key (BR, BW, PP), field (BPRME, MEINS/BSTME via the paired glossary, BPUMZ, BPUMN, PEINH, Quantity OPUn) and transaction (MIRO, MRBR, OMR6) traces to the brief appendix and this file’s VERIFIED DATA block. SAP ampersand placeholders are preserved verbatim (
& %percentage in M8 091 / M8 092). Message type is described as configurable (accuracy rule 2). No short text is paraphrased as another, and the M8 090 spine sentence is quoted as the long text, not as a short text. M8 081 is not quoted here, so no SE91 spot-check applies to this file. - Inline links used (all verified present or external): external
https://getclaro.ai/by-use-case/invoice-reconciliation(diagnosis→fix turn, in “Why identity resolution is the real fix”); flagship/resources/guides/error-says-price-cause-is-units/; tool/resources/tools/unit-dimension-converter/; glossary pair/resources/glossary/order-price-unit/; plus permitted/resources/glossary/tolerance-key/. All exist in the repo as of writing.invoice-price-varianceandsap-price-variance-tolerance-not-workingare reached via Related Card only, not inline. - Related composition is the Template B mix: 3 tools, 3 guides (flagship + two ERP-error siblings), 1 playbook, 1 glossary (the pair). All eight destinations exist, so the cards are live, not deferred.
- relatedSlugs omitted per owner instruction (the audit-checked field); Related is authored as Cards only.
- DE/IT CTA localisation remains an open decision (SCHEMA-NOTES §4); it does not affect this English guide, whose
book-demoCTA auto-renders the brief’s heading and button.
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