Tolerance Keys: How an ERP Decides a Price Is Wrong

A tolerance key is the SAP setting that decides whether an invoice value is close enough to the purchase order to pay. All 15 keys, and why BD is not AP.

A supplier invoice lands in the matching queue, and before anyone has read a line of it, the ERP has already decided the price is wrong and held the document for payment. The setting that made that call is a tolerance key. In SAP, a tolerance key is a configuration record — maintained per company code in transaction OMR6 — that defines how far an invoice value may drift from the purchase order before the system raises a message or blocks the invoice. There are fifteen of them, one for each kind of variance SAP checks: price, quantity, order price quantity, small rounding differences, blanket-order amounts, and dates. Get the keys and their limits right and genuine errors stop at the door; get them wrong and the system either waves bad invoices through or blocks correct ones for a variance that never mattered.

Definition

A tolerance key tells SAP’s invoice verification how much deviation to tolerate for one specific type of variance, and what to do when the deviation is larger than that. Each key carries a lower and an upper limit, expressed as an absolute amount, a percentage, or both. Below the lower limit the system issues a message but lets the invoice through; above the upper limit it blocks the invoice for payment. Setting every limit on a key to Do not check makes SAP accept any variance of that type. Keys are maintained per company code in OMR6, so two company codes on the same instance can police the same supplier differently.

The fifteen keys fall into a few families:

Variance type	Tolerance keys
Price variance	PP (price), PC (contract price), PS (estimated price), KW (condition value)
Quantity variance	DQ (exceed amount: quantity variance), DW (quantity variance when GR quantity is zero)
Amount per item and blanket order	AN (item without order reference), AP (item with order reference), LA (blanket PO amount), LD (blanket PO time limit)
Order price quantity (percentage)	BR (IR before GR), BW (GR before IR)
Special behaviour	VP (moving average price), BD (form small differences), ST (date variance, value × days)

Two keys do not simply block. VP guards the moving average price rather than a purchase-order comparison, and BD — form small differences automatically — prevents posting entirely rather than blocking for payment, because its job is to absorb a rounding difference into a dedicated account instead of holding up the document. Every other key, when its upper limit is breached, blocks the invoice for payment under one of SAP’s blocking reasons.

Why tolerance keys break invoice matching

Tolerance keys fail in both directions: too loose and real price increases post unnoticed, too strict or misassigned and correct invoices pile up in the block queue. The most expensive failures are not wrong limits at all — they are the wrong key doing a job it cannot do, or a key nobody maintained.

Symptom	Tolerance-key cause	What actually happened
Correct invoices blocked over a few cents	AP maintained where BD was needed	AP can only block; it has no mechanism to post the rounding difference
Every invoice without a goods receipt is blocked	DW not maintained	If DW is absent, SAP blocks any invoice posted before its GR
Real price increases post without a flag	PP limits too wide or set to Do not check	No variance is ever raised, so the band accepts the error
A price block on an invoice billed at the agreed price	PP tripped by a shifted order price quantity	The cause is the unit, not the price — checked on BR/BW, not PP
One wrong line freezes a 40-line invoice	Any key breached on a single item	The whole invoice blocks for payment, not just the line

The fourth row is the one that wastes the most time. SAP computes the invoice price as invoice amount divided by the order price quantity, so a wrong unit of measure or conversion factor moves that quotient and trips the price key even though the vendor billed exactly the agreed figure — the mechanism is traced step by step in the error says price, the cause is units.

Messy vs. trusted: what the right tolerance key changes

Tolerance keys left to guesswork	Tolerance keys set against trusted data
AP widened to absorb cent differences, so larger errors slip through too	BD posts small differences automatically while AP stays strict
PP loosened to clear a unit-driven block	PP left strict; the conversion factor fixed at source so no variance computes
DW left unmaintained, so every pre-GR invoice blocks	DW maintained, so only genuine quantity variances block
One wrong line silently freezes the whole invoice for days	Lines verified before posting, so clean lines are never held hostage
Limits copied blindly between company codes	Limits reviewed per company code against real variance history

Tolerance key strategy: which key to use when

1

Match the key to the variance

Price belongs on PP, with PC for a contract price and PS for an estimated price. Quantity belongs on DQ and DW, order price quantity on BR and BW, and genuine rounding on BD. Choosing the right key is most of the work — a mis-assigned key produces blocks that no limit can tune away.
2

Decide block versus message with the limits

Below the lower limit SAP only issues a message; above the upper limit it blocks. To force a block on any variance at all, set the absolute upper limit to zero with Check limit selected. To accept any variance, set every limit to Do not check.
3

Keep BD for small differences, never AP

Maintain BD so cent-level rounding posts to the Expense/Income from Small Differences account instead of blocking. Leave AP strict — it is there to catch genuinely wrong amounts, not to swallow rounding.
4

Maintain DW even if you never expect pre-GR invoices

An unmaintained DW is not an open gate; it blocks every invoice posted without a goods receipt. Set it deliberately rather than leaving it blank.
5

Review per company code against real data

Keys live per company code in OMR6, so reconcile each limit against actual price and unit history before you trust it — a price list diff confirms whether a change is real, and a margin and markup calculator shows what a given tolerance would let through in margin terms.

Guide

The Error Says Price. The Cause Is Units.

Why a price-variance block so often traces back to a unit or conversion factor, across SAP, Dynamics 365, and Business Central.

Guide

SAP M8 534 Balance Not Zero: BD, Not AP

Clear a balance-not-zero error by maintaining key BD instead of widening AP.

Glossary

Invoice Price Variance Explained

The M8 082 to M8 085 message family, and the absolute-versus-percentage split that runs on key PP.

Glossary

What Is a Blocked Invoice?

The four blocking reasons, and the rule that blocks the whole invoice for one varying line.

Tool

Price List Diff

Compare an old and new supplier price file to confirm whether a change is real before you touch a tolerance limit.

Playbook

Map Supplier Attributes to Your Schema

Map supplier units, prices, and conversion factors onto one canonical model so a tolerance key checks trustworthy values.

FAQ

What is a tolerance key in SAP?

A tolerance key is an SAP invoice-verification setting, maintained per company code in transaction OMR6, that defines how far an invoice value may deviate from the purchase order for one type of variance before the system reacts. Each key has a lower and an upper limit: below the lower limit SAP issues a message but lets the invoice through; above the upper limit it blocks the invoice for payment. There are fifteen keys in total.

What is the difference between tolerance keys BD and AP?

AP — amount for an item with an order reference — can only block an invoice; it has no way to post a difference. BD, form small differences automatically, posts the rounding gap to the Expense/Income from Small Differences account through account determination event DIF, with the item-amount checks maintained in OMRH and OMRI. Teams reach for AP when they actually need BD, which is why cent-level differences keep blocking invoices that should simply post.

Which tolerance key controls price variance in SAP?

Price variance runs on key PP, with PC for a contract price and PS for an estimated price. When the computed invoice price exceeds the upper limit on the relevant key, SAP blocks the invoice for payment with blocking reason price. KW handles a variance from the condition value, and VP guards the moving average price separately rather than comparing against a purchase order.

Does a tolerance key block the whole invoice or just the line that varies?

The whole invoice. SAP blocks the entire invoice for payment even if only one item on it shows a variance, so a single line that trips one tolerance key holds up every other line on the document. The block is released in transaction MRBR once the variance is corrected or accepted.

How do I stop a tolerance key from checking a variance, or force it to block everything?

To accept any variance of that type, set every limit on the key to Do not check. To block on any variance at all, set the absolute upper limit to zero with Check limit selected. One trap: if key DW is not maintained, SAP blocks every invoice posted without a goods receipt, so an unmaintained key is not the same as an open one.

How does Claro help with invoice tolerance and price checks?

A tolerance key only decides whether an invoice value sits inside a band — it cannot tell you whether the band was set against the right price or the right unit. Claro checks every invoice line against a trusted catalog and the agreed price list before it reaches the ERP, resolving each item to one record with known units and conversion factors, so the variance SAP sees is a real one and clean lines are never blocked for a phantom difference.

REVIEW-NOTES

Every key and behaviour traces to the brief appendix / task data. All 15 keys (AN, AP, BD, BR, BW, DQ, DW, KW, LA, LD, PC, PP, PS, ST, VP) and their meanings come from the verified OMR6 list. Verified behaviours used: upper-limit breach blocks the invoice for payment except BD (prevents posting) and VP (guards moving average price); Do not check accepts any variance; the entire invoice is blocked even for one varying line; below the lower limit a message, above the upper limit a block; absolute upper limit = zero with Check limit forces a block; unmaintained DW blocks pre-GR invoices; AP only blocks while BD posts to Expense/Income from Small Differences via event DIF with OMRH/OMRI; release is in MRBR; blocking reasons are quantity, price, quality, date (quality from QM, not a tolerance key — not attributed to a key here). Nothing outside the supplied data was introduced.
Related composition note. Template A specifies 3 glossary + 2 tools + 1 playbook/comparison. This entry’s explicit pairing instruction (Card-link the flagship error-says-price-cause-is-units and the pair guide sap-balance-not-zero-m8-534) takes precedence for this page, so the 6 cards are 2 guides + 2 glossary + 1 tool + 1 playbook. The second required tool link is satisfied inline (tools/price-list-diff and tools/margin-markup-calculator), keeping at least two tool links across the page.
No deferred links. All inline markdown links point to pages confirmed to exist. Cluster siblings (invoice-price-variance, blocked-invoice, sap-balance-not-zero-m8-534) are Card-only, so no audit-checked link depends on an unshipped page.