Order Price Unit vs Order Unit: The Variance Nobody Expects

Most purchasing teams never think about the order price unit until an invoice is blocked for a price that is demonstrably right. You order cable by the reel but the vendor prices it per metre; you buy fasteners by the box but the contract is per thousand pieces. SAP stores both units on the purchase order item and a conversion factor between them, and every invoice is checked against the derived quantity, not the one you typed. The price condition never moves, yet the figure SAP divides it against does — so the block reads price variance when the root cause is a unit mismatch. This entry explains what the order unit, the order price unit and the conversion factor each do, and why getting the factor wrong produces the variance nobody expects — the one the flagship guide to this problem traces end to end.

What Each Field Does

Four fields on the purchase order item (table MEPOITEM / EKPO) decide how a vendor’s price is checked against an invoice. The order unit (MEINS, data element BSTME) is the unit you order and receive in. The order price unit (BPRME, data element BBPRM) is the unit the vendor quotes the price against. They are frequently identical — you order in pieces and are priced per piece — but a distributor’s catalog is full of cases where they are not: wire priced per metre and stocked by the reel, bolts priced per thousand and ordered by the box, sheet priced per kilogram and received by the plate.

When the two units differ, SAP needs to know how they relate. That is the job of the conversion factor: BPUMZ is the numerator and BPUMN the denominator that convert the order price unit into the order unit. A separate field, the price unit (PEINH, data element EPEIN), records the quantity the price itself refers to — a price of 42.00 “per 100” carries a price unit of 100. Get any of these three settings wrong and the arithmetic SAP performs at invoice time is wrong, even when the number the vendor billed is exactly right. This is where a unit of measure mismatch stops being a data-hygiene footnote and starts blocking payments.

Why the Order Price Unit Breaks Invoice Matching

The failure is arithmetic, not clerical. SAP does not compare the vendor’s unit price against your contract price directly. It computes the invoice price as the invoice amount divided by the order price quantity, then compares that against the net order price. The order price quantity is itself derived — from the conversion factor times the invoice quantity — so a wrong BPUMZ/BPUMN moves the denominator, which moves the computed invoice price, which trips the price check. SAP states this plainly in the long text of message M8 090 (Please check: order price quantity set automatically): a changed order price quantity creates a price variance, because the invoice price is the invoice amount divided by the order price quantity. The message points at price; the cause is units.

Because the variance is computed, it does not run on the price tolerance key. The percentage comparison behind M8 091 (Quantity more than & % below order price quantity) and M8 092 (Order price quantity exceeded by more than & %) uses the dedicated tolerance keys BR (invoice before goods receipt) and BW (goods receipt before invoice) — not the price key PP. That is why widening PP never clears an order-price-quantity block: you are loosening the wrong gate while the real one keeps firing. These messages are message class M8, and like the rest of invoice verification their type is configurable — commonly a warning that blocks the invoice for payment rather than preventing posting. The result reads as an invoice price variance but is not one.

Messy vs. Trusted: The Same Invoice, Two Ways

Order Price Unit Strategy: Which Unit to Check When

1. Read the message number before touching anything. M8 082 / M8 083 (Price too high (tolerance limit of & % exceeded)) are genuine price-tolerance breaches on key PP. The M8 090–M8 092 range is an order-price-quantity message. They demand opposite fixes.

2. Recompute 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 — and the factor behind it — is the fault, not the price.

3. Compare the units against each other. Check BPRME against MEINS and the BPUMZ/BPUMN factor against the material master and info record. A unit and dimension converter confirms the factor in seconds, and a UNECE Rec 20 unit code validator confirms the unit strings map to valid standard codes so order and price units stay comparable.

4. Fix the factor at the source, not the tolerance. Correct BPUMZ/BPUMN on the PO item and info record so the order price quantity derives correctly. Leave PP, BR and BW strict — they are doing their job.

5. Catch it before the next file lands. Diff the incoming supplier price file against the last one with a price list diff so a changed unit or factor is flagged before it ever reaches an invoice, and map supplier units onto one model with the attribute-mapping playbook.

Related

FAQ

What is the difference between order unit and order price unit in SAP? +

The order unit (field MEINS, data element BSTME) is the unit you order and receive in — pieces, boxes, reels. The order price unit (field BPRME) is the unit the vendor’s price is quoted against — per metre, per thousand pieces, per kilogram. They are often the same, but when a supplier prices in one unit and you transact in another, SAP stores both on the purchase order item and a conversion factor between them.

What do BPUMZ and BPUMN do? +

BPUMZ is the numerator and BPUMN the denominator of the factor that converts the order price unit into the order unit. Together they tell SAP how many order units one priced quantity represents — for example, one price unit of 100 pieces mapped onto a box of 25. If the numerator and denominator are transposed or wrong, the conversion is wrong, and every invoice checked against it inherits the error.

Why does a wrong order price unit show up as a price variance? +

Because SAP computes the invoice price as the invoice amount divided by the order price quantity, and the order price quantity is derived from the conversion factor. Per message M8 090, a changed order price quantity creates a price variance, because the invoice price is the invoice amount divided by the order price quantity. The quotient moves even though the agreed price never did, so the block reads price variance while the fault sits in the units.

Which tolerance keys cover order price quantity variance? +

Order price quantity variance runs on its own keys, not the price key PP. BR applies when the invoice arrives before goods receipt, and BW when goods receipt comes first. Because these are separate from PP, widening the price tolerance does not clear an order-price-quantity block — the message M8 092, which blocks with the reason order price quantity variance, keeps firing until the conversion factor is corrected.

How is the order price quantity derived when there is no goods receipt yet? +

When the invoice arrives before goods receipt, SAP compares against the invoice quantity multiplied by the PO conversion factor. When goods receipt comes first, it compares against the order price quantity recorded at goods receipt. That is why BR and BW are two distinct keys: the comparison base is different depending on which document lands first, and a wrong conversion factor skews both.

How does Claro help with order price unit mismatches? +

Claro resolves each supplier item to one canonical record whose order unit, order price unit and conversion factor are known and consistent, then checks every invoice line against that trusted record. Where a supplier prices in a different unit than you transact in, Claro maps the units and validates the factor on ingestion, so a transposed BPUMZ/BPUMN is caught at the source instead of surfacing as a phantom price block weeks later in MIRO.

REVIEW-NOTES

• Accuracy. Every field (MEINS/BSTME, BPRME/BBPRM, BPUMZ, BPUMN, PEINH/EPEIN, Quantity OPUn), message (M8 082, M8 083, M8 090, M8 091, M8 092) and tolerance key (PP, BR, BW) traces to the brief appendix. SAP ampersand placeholders are preserved verbatim (& % percentage in M8 091/M8 092/M8 083). Message type is described as configurable per accuracy rule 2; no message short text is paraphrased as another. M8 081 is not quoted, so no SE91 spot-check applies to this file.
• Related composition — deliberate substitution. Template A specifies 3 glossary + 2 tools + 1 playbook/comparison. This entry’s owner instruction also requires the designated glossary↔guide pair (sap-order-price-quantity-variance) as a Card. To keep exactly 6 cards, the “1 playbook/comparison” slot is filled by that guide-pair Card; the playbook map-supplier-attributes-to-schema is instead linked inline in the Strategy section so it is still referenced. Flag for Matteo if the literal 3+2+1 mix is preferred over including the pair card.
• Deferred / live-broken link. The sap-order-price-quantity-variance guide does not exist yet. Per SCHEMA-NOTES §3, <Card href> is not audit-checked, so the build stays green, but the card is a live broken link until that guide ships in the P2 English batch. Re-verify on the final cross-link commit (brief Workflow step 6); the guide should link back here.
• relatedSlugs omitted per instruction (audit-checked field; this entry links some not-yet-existing siblings only via Card).