Releasing Blocked Invoices in SAP (MRBR)

A run of blocked invoices is sitting in MRBR, and you do the obvious thing: start automatic release and let SAP clear the ones whose variances have since resolved. Most of them go. But one keeps coming back. The goods receipt matches, the price matches, the tolerance check passes — and still the invoice will not release. What you are looking at is not a variance at all. Someone set a manual payment block on it, and automatic release is built to ignore exactly that. This is the most common reason a blocked invoice refuses to clear in SAP: the release mechanism you are running was never designed to touch the block that is actually holding it. Releasing a blocked invoice correctly means first knowing which of several different blocks is on it, because each one lives in a different field and clears a different way.

Where a blocked invoice actually hides

The block you can see in the payment status is rarely the whole story. The same invoice can carry different blocks in different places, and only one of them answers to automatic release.

MRBR groups blocked invoices by these three procedures, and the Release Invoice action removes the vendor-line payment block but does not change the item-level reasons underneath it. Run automatic release and only the variance procedure clears; everything else stays exactly where it was. So the first question is never how do I release it but what is holding it — a tolerance breach a machine can reassess, a decision a person made, or a sampling rule that was always going to need a human to sign off.

Before and after: fighting the release vs. clearing the right block

Release the right block — do not just run automatic release

1. 1
   Identify the blocking procedure first

   Open the invoice in MRBR and read which procedure holds it: Blocked due to variances, Manual payment block, or Stochastically blocked. Only the first is a candidate for automatic release. Everything after this depends on getting this one reading right.

2. 2
   For a variance block, fix the variance, then release

   A price variance on tolerance key PP, a quantity variance, or a unit problem that reads as price all clear once the underlying figure is corrected. If the message points at price but the number is right, the cause is usually the units beneath the price; a price tolerance that never seems to work is a different fix again. Comparing the supplier’s old and new file with a price list diff often shows which figure moved.

3. 3
   For a manual payment block, release it by hand

   The header payment block in INVFO-ZLSPR (Pmnt Block) was set deliberately — in MIRO, or programmatically by the BAdI MRM_PAYMENT_TERMS through its E_ZLSPR parameter — so no automatic run removes it. Use the Release Invoice action in MRBR, and remember it removes the vendor-line payment block only: it does not change any item-level reason (DRSEG-SPGRP for an automatic variance, DRSEG-SPGRQ for a manual one) underneath. If a line also carries a variance reason, clearing the header block alone will not settle the invoice.

4. 4
   Check who is allowed to release

   Releasing is gated by authorization objects M_RECH_SPG (blocking reason) and M_RECH_EKG (purchasing group). A release that silently does nothing is often a missing authorization, not a stuck invoice.

5. 5
   Schedule background release only for variances

   RM08RELEASE clears blocks whose variances have since resolved, on a schedule — a goods receipt that finally posted, a price condition that was corrected. It will never clear a manual or stochastic block, so do not lean on it as a catch-all for the whole queue; those two procedures still need a person to work through them, and an invoice left waiting on automatic release that cannot see it ages quietly in AP.

Build a release checklist into your invoice verification

• The blocking procedure is identified — Blocked due to variances, Manual payment block, or Stochastically blocked — before any release is attempted
• Variance blocks are resolved at source (price, quantity, date), not released by widening OMR6 tolerances
• A manual header payment block (INVFO-ZLSPR) is released by hand, never left for automatic release to clear
• Item-level reasons are read — DRSEG-SPGRP (automatic) and DRSEG-SPGRQ (manual) — since Release Invoice clears the vendor line but not these
• Quality blocks are routed to the QM inspection result, not treated as a tolerance variance
• Release authorization (M_RECH_SPG, M_RECH_EKG) is confirmed for whoever runs MRBR
• RM08RELEASE is scheduled for variance blocks only, with manual and stochastic blocks handled by a person

Why identity resolution is the real fix

MRBR is where blocked invoices surface, but it is not where they are caused. Most variance blocks trace back to one thing: the invoice line and the purchase order line do not resolve to the same item, the same unit, or the same agreed price, so SAP computes a difference and holds the payment. Release one and the next supplier feed reopens the same gap. The durable fix is to reconcile every invoice line against one trusted record — the agreed price, the right unit, the correct conversion — before it ever reaches the block queue, which is the whole job of invoice reconciliation against trusted catalog data. A block is a symptom of two records that should be the same and are not; resolve them once and most variances never compute, so the release queue mostly empties itself and MRBR goes back to being an exception list rather than a daily chore.

Related

FAQ

REVIEW-NOTES

• Glossary pair deferred to the wiring commit. The paired glossary entry glossary/blocked-invoice is created in this same batch and may not exist at build time, so it appears only as a <Card> (not audit-checked), never as an inline markdown link. Once it ships, add the inline cross-link (and have blocked-invoice link back here) in the final cross-link commit — brief Workflow step 6. For the same reason relatedSlugs is omitted: several Related cards (incl. blocked-invoice) are not yet guaranteed present, and relatedSlugs is audit-checked.
• No accuracy flags. Every transaction (MIRO, MRBR, OMR6, OMRM, RM08RELEASE), field (INVFO-ZLSPR, DRSEG-SPGRP, DRSEG-SPGRQ, E_ZLSPR / BAdI MRM_PAYMENT_TERMS), blocking procedure (Blocked due to variances, Manual payment block, Stochastically blocked), blocking reason (quantity, price, quality from QM, date), tolerance key (PP), and authorization object (M_RECH_SPG, M_RECH_EKG) traces to the brief appendix. No M8 short text is quoted verbatim here, so no SE91 spot-check is required for this file. No invented strings or statistics.
• DE/IT CTA localisation remains the open decision in SCHEMA-NOTES §4; it does not affect this English piece, whose book-demo CTA renders the brief’s heading and button verbatim.