What Is a Blocked Invoice?
A blocked invoice is one an ERP holds from payment until it is released. Learn SAP's four blocking reasons, the whole-invoice rule, and how to clear it.
A blocked invoice is a supplier invoice an ERP has posted but deliberately holds so it cannot be paid until someone releases it. The document and its accounting entries exist; what is withheld is the payment. In SAP’s invoice verification there are exactly four reasons an invoice is blocked — quantity, price, quality, and date — and the rule that surprises most teams is that the entire invoice is blocked for payment even if only one line item shows a variance. A block is a control working as designed, not a system fault: it catches a figure that failed a tolerance check, or a hold a buyer set on purpose, and it stops the money from leaving until a person confirms the figure is right or corrects the data underneath it.
Definition
A blocked invoice carries a payment block that the ERP sets at the moment the invoice is posted. In SAP, the header payment block lives in the INVFO-ZLSPR field — labelled Pmnt Block on the MIRO entry screen — while the reason for a line-level block is written to DRSEG-SPGRP when a tolerance is breached automatically, or to DRSEG-SPGRQ when a buyer sets a manual block on the purchase-order item. The block indicator itself is configured as a Blocking Key in transaction OBB8. Posting still succeeds: the document and its account movements are written, but the payment program skips the invoice until the block is removed.
SAP recognises exactly four reasons to block an invoice in verification, and they do not all come from the same place.
| Blocking reason | What sets it | Where it comes from |
|---|---|---|
| Quantity | Invoice quantity outside the allowed quantity tolerance | Tolerance keys (e.g. DQ, DW) in OMR6 |
| Price | Invoice price outside the allowed price tolerance | Tolerance key PP in OMR6 |
| Quality | Goods under a QM inspection that is not yet cleared | A QM inspection lot — not a tolerance key |
| Date | Delivery or invoice date varies beyond the date tolerance | Tolerance key ST in OMR6 |
Three of the four — quantity, price, and date — are driven by tolerance keys maintained per company code in transaction OMR6, and the message SAP issues when a limit is breached has a configurable type, commonly a warning that blocks the invoice for payment rather than one that prevents posting. The fourth, quality, is different.
Why a blocked invoice holds up more than one line
A block is cheap to create and expensive to ignore, because of how its scope and its release behave. The reason an invoice was blocked is rarely visible from the payment run alone, and the different block types clear in different ways.
| What you see | What is actually happening | Consequence |
|---|---|---|
| The whole invoice is held for one bad line | SAP blocks the entire invoice for payment even if only one item shows a variance | Every correct line on the document waits for payment too |
| Automatic release runs but the invoice stays blocked | Automatic release clears only variance blocks; a manual header block in INVFO-ZLSPR is not released by it | AP assumes the block cleared; it never does |
| A release does not stick | Releasing the vendor line removes the header payment block but does not change the item reasons in DRSEG-SPGRP / DRSEG-SPGRQ | The item reason survives and can re-block the invoice |
| A block appears with no variance at all | The invoice was stochastically blocked by random sampling | Nothing is wrong; it still needs a manual release |
While the invoice sits blocked, the clock on any early-payment discount keeps running, so a block held for a few days to chase an invoice price variance that turns out to be correct can quietly cost the discount it was meant to protect. Worse, a block that reads as a price problem is often a units problem instead — the invoice price moved because the quantity it was divided by moved, which is exactly the error that says price when the cause is units. Chasing the vendor over either one wastes the time the block was supposed to save.
Before and after: a blocked-invoice queue vs. a clean match
| Blocked invoices worked by hand | Blocked invoices on trusted catalog data |
|---|---|
| A buyer emails the vendor about a block that is really an internal data fault | The variance is traced to the catalog record before anyone contacts the vendor |
| Each invoice is released one at a time, forever | The price or conversion factor is fixed once, so it stops re-blocking |
| Automatic release is assumed to have cleared a manual header block | Header and item blocks are read separately, so nothing is assumed cleared |
| The early-payment discount is lost while the invoice waits | Clean matches release in time to keep the discount |
| A tolerance is widened to stop the blocks, hiding real errors | Tolerances stay strict; the source data is corrected instead |
How to clear and prevent blocked invoices across a supplier catalog
- 1Read the reason before the block
Identify which of the four reasons applies and whether the block is at header level (
INVFO-ZLSPR) or item level (DRSEG-SPGRPfor an automatic tolerance breach,DRSEG-SPGRQfor a manual hold). The reason determines the fix; the block alone does not. - 2Release deliberately in MRBR
Transaction
MRBRgroups invoices by blocking procedure —Blocked due to variances,Manual payment block, andStochastically blocked. Automatic release, run by programRM08RELEASE, clears only the first; a manual or stochastic block waits for a person. - 3Trace a variance block to its data
Recompute the blocked figure the way SAP does and check the unit behind it. A wrong order-price-unit conversion factor produces a phantom variance on an invoice that is otherwise correct — a unit and dimension converter confirms the factor in seconds.
- 4Compare the price file behind a price block
When the block is a price variance, compare the price file that drove the invoice against the version in force to see exactly which line moved. A price list diff surfaces the changed figure without hand-checking every row.
- 5Fix at the source, not at the tolerance
Write the corrected price, quantity, or conversion factor back to the record so every future invoice inherits it, and leave the
OMR6tolerances strict. Widening a limit releases one invoice and accepts real errors on all the rest.
Related
Glossary
Invoice Price Variance Explained
The price-tolerance breach behind most price blocks — what the invoice price is compared against, and why it moves.
Glossary
Tolerance Keys: How an ERP Decides a Price Is Wrong
The 15 OMR6 keys that set quantity, price, and date blocks, and why BD behaves unlike the rest.
Glossary
What Is Three-Way Matching?
How the PO, goods receipt, and invoice are compared — the check that produces a block when they disagree.
Tool
Price List Diff
Compare an old and new supplier file to find the changed line that is blocking an invoice for a price variance.
Tool
Unit and Dimension Converter
Confirm a conversion factor so a price block that is really a units problem can be cleared at the source.
Guide
Releasing Blocked Invoices in SAP (MRBR)
The step-by-step: header payment block vs. item reasons, the three blocking procedures, and what automatic release will and will not clear.
FAQ
What does it mean when an invoice is blocked for payment?
It means the ERP has posted the invoice but set a payment block, so the document and its accounting entries exist while the payment program skips it until someone releases the block. The vendor is not paid, but the invoice is not rejected either. A block is a deliberate control, usually set because a figure failed a tolerance check or a buyer held the line on purpose.
What are the four invoice blocking reasons in SAP?
SAP invoice verification blocks an invoice for one of four reasons: quantity, price, quality, or date. Quantity, price, and date are driven by tolerance keys maintained per company code, so a figure outside the allowed limit sets the block automatically. Quality is the exception — it comes from a QM inspection lot that has not been cleared, not from a tolerance key, so it is cleared through inspection rather than by changing a limit.
Does one bad line block the whole invoice?
Yes. In SAP the entire invoice is blocked for payment even if only one item on it shows a variance. Every other line on the document — however correct — waits for payment until the single flagged line is released or corrected. This is why a blocked invoice is rarely a problem with the whole document; it is usually one line, one figure, or one conversion factor holding up everything else.
Why doesn't automatic release clear my blocked invoice?
Automatic release applies only to invoices blocked due to variances. A manual header payment block is not cleared by automatic release, and neither is a stochastic block, so an invoice held by one of those sits blocked no matter how many times the release job runs. Releasing the vendor line removes the header payment block but does not change the item-level blocking reasons, which can re-block the invoice on a later run.
Which transaction releases a blocked invoice in SAP?
Transaction MRBR, Release Blocked Invoices, is where blocks are reviewed and released. It groups invoices by blocking procedure — blocked due to variances, manual payment block, or stochastically blocked — and lets you release them manually or run the background release program, RM08RELEASE, which only clears the variance-blocked group. Release the block only once the figure behind it is confirmed correct or the source data is fixed.
How does Claro help with blocked invoices?
Claro resolves each invoice line to a trusted catalog record, so the price, quantity, and unit a block is tested against are known before verification. When a variance is real, Claro shows which source figure moved; when it is a data fault — a wrong conversion factor or a stale price-list version — it is corrected at the record so the invoice stops re-blocking. Fewer blocks reach MRBR, and those that do carry their evidence.
REVIEW-NOTES
- Related card count resolved to exactly 6. Template A specifies 3 glossary + 2 tools + 1 playbook/comparison, but the task also requires the glossary↔guide pair (
releasing-blocked-invoices-mrbr) as a Card. The 6th slot is therefore the pair guide rather than a playbook/comparison. The flagship (error-says-price-cause-is-units) is linked inline in the body instead of as a 7th card, which keeps the count at 6 and still links the hub. Confirm this trade-off is acceptable, or swap the mix. - Live broken link until sibling ships. The Related Card to
/resources/glossary/releasing-blocked-invoices-mrbr/(actuallyguides/releasing-blocked-invoices-mrbr) points at a guide that does not exist yet. Per SCHEMA-NOTES §5 the audit does not check<Card href>, so the build stays green, but the link is live-broken until that guide ships.relatedSlugsis omitted (as instructed), so nothing audit-checked references it. Re-verify after the P2 guide batch. - Card href path: the mrbr card uses
/resources/guides/releasing-blocked-invoices-mrbr/— confirm the guide ships in theguides/collection (it is a guide in the backlog), so the path is correct once it exists. - No accuracy flags. Every field (
INVFO-ZLSPR,DRSEG-SPGRP,DRSEG-SPGRQ, Blocking Key /OBB8), transaction (MIRO,MRBR,OMR6), program (RM08RELEASE), the four blocking reasons (quantity/price/quality/date, quality from a QM inspection not a tolerance key), the three MRBR blocking procedures, the whole-invoice-blocking rule, and the tolerance keys named (DQ, DW, PP, ST) trace to the brief appendix. No M8 short text is quoted, so no SE91 spot-check is needed.
Claro
See how Claro handles this in production
This concept is one piece of keeping a catalog trusted. See how Claro resolves identity, enriches missing attributes, and validates every update before it reaches your PIM or ERP.
Learn more