The Error Says Price. The Cause Is Units.
An ERP blocks an invoice for a price variance, but the price is correct. The real fault is the unit the price is measured against — in SAP, Dynamics 365, and Business Central.
An invoice lands in your matching queue with a price-variance block. You open it, pull the purchase order, and check the figure against the contract — and the price is exactly what you agreed. Nothing on the price condition has moved. Yet the system is holding the invoice for payment under blocking reason price variance, and a buyer is already drafting an email to the vendor about a discrepancy that isn’t theirs. This is the most misdiagnosed block in invoice verification, and often it is not a pricing problem at all. The amount is correct. What moved is the unit the price is measured against — an order price quantity, a conversion factor, a rounding rule. SAP, Microsoft Dynamics 365, and Microsoft Dynamics 365 Business Central each surface the same root cause in a different place, and each one points you at the price field while the fault sits in the units. Here is how to tell them apart and fix the right thing.
Where the price block is really a unit problem
The giveaway is always the same: the price condition is untouched, but the figure SAP divides it against has moved. Each system shows that differently.
| System | What you see | What actually moved |
|---|---|---|
| SAP ECC / S/4 | `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 |
| SAP tolerance check | Invoice blocked for payment, reason price variance (tolerance key PP) | The invoice price is invoice amount ÷ order price quantity, so a shifted order price quantity moves the price with no price change |
| SAP PO master data | `Order price quantity exceeded by more than & %` (M8 092) | A wrong BPUMZ / BPUMN conversion inflated the order price quantity on the PO item |
| Dynamics 365 F&O / SCM | Unit price match = Failed, red match icon — no error text | A unit changed on the line and trade-agreement prices were not recalculated for the new unit |
| Business Central | Quantity reads 4.99998 instead of 5 | A rounding-precision setting turned a whole-unit receipt into a fraction, skewing the per-unit value |
In every row the price condition is intact; the denominator under it moved. SAP says so itself 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. The percentage comparison behind M8 091 and M8 092 runs on its own tolerance keys — BR when the invoice arrives before goods receipt, BW when goods receipt comes first — not on the price key PP, which is exactly why widening PP never clears it.
Before and after: chasing the price vs. fixing the unit
| Chasing the price | Fixing the unit |
|---|---|
| Buyer opens a dispute over a price the vendor billed correctly | Invoice released once the order price quantity is corrected — no vendor contact needed |
| Tolerance key PP widened to stop the blocks | PP left strict; the BPUMZ / BPUMN conversion fixed so the variance never computes |
| Dynamics 365 line re-priced by hand to clear the red icon | A trade agreement maintained for the unit on the line so the price resolves on its own |
| Business Central receipt posted at 4.99998 and written off as a quirk | Quantity Rounding Precision set to 1 so five pieces receive as five |
| Each blocked invoice worked one at a time, forever | The conversion factor fixed once at the item — every future invoice posts clean |
Trace the variance to the unit — do not just raise the tolerance
- 1Read the message, not just the block
A block alone tells you nothing about the cause.
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-tolerance breaches. The M8 090 to M8 092 range is an order-price-quantity message. They need opposite fixes. - 2Recompute the invoice price the way SAP does
Divide the invoice amount by the order price quantity. If the amount is right but the quotient is wrong, the order price quantity is the fault — not the price.
- 3Check the PO item's units against each other
Compare the order price unit (BPRME) with 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 on an invoice that is otherwise correct. A unit and dimension converter confirms the factor in seconds.
- 4In Dynamics 365, read the right column
Look at the Unit price match status, not the invoice total. A Failed there while Price total match shows Passed points straight at the per-unit figure and the unit behind it.
- 5In Business Central, check the item's UoM setup
Confirm Qty. per Unit of Measure (the base unit must be 1) and Quantity Rounding Precision. A non-integer received quantity is a precision setting, not a miscount.
Build a unit-integrity checklist into your invoice matching
Why identity resolution is the real fix
A price variance that is really a unit variance is an identity problem in disguise: the system cannot line up the unit the vendor priced in with the unit you stock, order, and pay in. Fix one invoice and the next conversion factor fails the same way. The durable fix is to resolve each item to one trusted record whose units and conversion factors are known and consistent, so the price is always divided by the right quantity — which is the whole job of invoice reconciliation against trusted catalog data. This is the same wedge that stops margin leakage in supplier price files and the misattributed costs behind duplicate SKUs corrupting pricing: get identity and units right once, and the downstream arithmetic stops lying.
Related
Free tool
Unit and Dimension Converter
Confirm a BPUMZ / BPUMN conversion factor and check that 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
Margin Leakage in Supplier Price Files
The UOM mismatches and mis-mapped SKUs that erode margin before anyone notices.
Guide
How Duplicate SKUs Corrupt Pricing
The catalog identity errors that attach the right price to the wrong record.
Guide
The Real Cost of a Price Update
What manual price-file and invoice-exception handling actually costs in time and margin.
Playbook
Map Supplier Attributes to Your Schema
Map supplier units and conversion factors onto one canonical product model.
Glossary
What Is Unit of Measure (UOM)?
Base, order, and packaging units, and the conversion factors that link them.
FAQ
What is an order price quantity variance in SAP?
It is a mismatch between the order price quantity SAP expects and the one derived 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, so when that quantity is derived from a conversion factor (PO conversion factor times invoice quantity) and the factor is wrong, the quotient moves even though the agreed price never changed. SAP flags it with messages in the M8 090 to M8 092 range and can block the invoice with the reason order price quantity variance.
Why does SAP block an invoice for a price variance when the price is correct?
Because SAP compares the invoice price it computes — invoice value divided by order price quantity — against the net order price, not the raw price condition you negotiated. If the order price quantity is wrong, the computed invoice price differs from the order price and SAP blocks the invoice for payment with blocking reason price variance, even though the amount the vendor billed is exactly right. The message points at price; the fault is in the units underneath it.
Does Dynamics 365 recalculate the price when the unit changes on an order?
No. Microsoft states that when a unit is changed on a purchase order, trade agreement prices are not recalculated according to unit conversion definitions. In Microsoft’s own words: “If no price is found for the unit, the system doesn’t apply a price. The unit conversion can’t be used to recalculate the price into another unit. Theoretically, the price for one box of ten might not equal ten times the price of one box.” The workaround is to maintain a trade agreement for every unit you expect on order lines. There is no error message — the line simply surfaces as a Failed unit price match.
Why does Business Central receive five pieces as 4.99998?
It is a unit-of-measure rounding effect, not a counting error. Microsoft’s own example is receiving five of six pieces from a box of six, which “would lead to a receipt of 4.99998 pieces, rather than five.” The fix is to set Quantity Rounding Precision to 1 on the item so the quantity rounds to a whole piece. A fractional received quantity then feeds a per-unit value that looks wrong on the invoice, which is how a units setting shows up as a pricing discrepancy.
Should I widen the tolerance to stop these blocks?
No. Widening the price tolerance (tolerance key PP in SAP, or the price-total tolerance in Dynamics 365) releases the one invoice in front of you and silently accepts real price errors on every other invoice afterwards. The order-price-quantity messages run on their own keys — BR when the invoice arrives before goods receipt, BW when goods receipt comes first — so widening PP does not even clear them. Fix the conversion factor at the source instead; the block is doing its job.
REVIEW-NOTES
- Hub wiring deferred (not a content error). This flagship is the cluster hub and will link to
the ERP-error sibling guides (
sap-order-price-quantity-variance,sap-price-variance-tolerance-not-working,sap-uom-conversion-not-possible,business-central-vs-d365-finance-matching). Those pages do not exist yet, so to keep the readiness audit green the Related cards and the three inline body links currently point only at pages that already exist. When the sibling guides ship in the batches, re-wire Related + inline to point at them (brief Workflow step 6, the final cross-link commit). Each sibling guide should also link back here. - No accuracy flags in this piece. Every message number (M8 082, M8 083, M8 090–092), field
(BPRME, MEINS, BPUMZ, BPUMN, Quantity OPUn), tolerance key (PP, BR, BW), the Microsoft
unit/price statement, and the Business Central 4.99998 example trace to the brief appendix. SAP
ampersand placeholders (
& &amount+currency,& %percentage) are preserved. M8 081 is not quoted here, so no SE91 spot-check is needed for this file. - DE/IT CTA localisation is still an open decision (see SCHEMA-NOTES §4); it does not affect
this English pilot, whose
book-demoCTA renders the brief’s heading and button verbatim.
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