Rechnung zur Zahlung gesperrt: Sperrgründe und Freigabe mit MRBR

Eine Rechnung lässt sich in MRBR nicht freigeben, obwohl die automatische Freigabe lief. Der Grund ist, welche Sperre auf ihr liegt — Abweichung, manuelle Zahlsperre oder stochastisch.

Eine Reihe gesperrter Rechnungen liegt in MRBR, und Sie tun das Naheliegende: Sie starten die automatische Freigabe und lassen SAP die Rechnungen klären, deren Abweichungen sich inzwischen erledigt haben. Die meisten gehen durch. Doch eine kommt immer wieder. Der Wareneingang stimmt, der Preis stimmt, die Toleranzprüfung läuft sauber durch — und trotzdem lässt sich die Rechnung nicht freigeben. Was Sie da vor sich haben, ist überhaupt keine Abweichung. Jemand hat eine manuelle Zahlsperre auf sie gesetzt, und die automatische Freigabe ist genau darauf ausgelegt, das zu ignorieren. Das ist der häufigste Grund, warum eine gesperrte Rechnung in SAP sich nicht klären lässt: Der Freigabemechanismus, den Sie laufen lassen, war nie dafür gebaut, die Sperre anzufassen, die sie tatsächlich hält. Eine gesperrte Rechnung richtig freizugeben heißt, zuerst zu wissen, welche von mehreren verschiedenen Sperren auf ihr liegt — denn jede sitzt in einem anderen Feld und wird anders aufgehoben.

Wo eine gesperrte Rechnung sich wirklich versteckt

Die Sperre, die Sie im Zahlungsstatus sehen, ist selten die ganze Geschichte. Dieselbe Rechnung kann an verschiedenen Stellen verschiedene Sperren tragen, und nur eine davon hört auf die automatische Freigabe.

Wo die Sperre liegt	Feld oder Verfahren	Wie sie aufgehoben wird
Zahlsperre im Kopf	INVFO-ZLSPR, in MIRO als „Zahlsperre“ angezeigt	Von Hand in MIRO gesetzt oder vom BAdI MRM_PAYMENT_TERMS geschrieben (Exportparameter E_ZLSPR); die automatische Freigabe rührt sie nie an
Abweichungssperre auf einer Position	DRSEG-SPGRP, automatisch bei einer OMR6-Toleranzüberschreitung gesetzt	Das Verfahren „Wegen Abweichungen gesperrt“ — das einzige, das die automatische Freigabe und RM08RELEASE aufheben
Manuelle Sperre auf der Bestellposition	DRSEG-SPGRQ, von Hand auf der Bestellposition hinterlegt	Das Verfahren „Manuelle Zahlungssperre“; nur von Hand in MRBR aufgehoben
Stochastische Sperre	Zufallsstichprobe, keine Abweichung im Spiel	Das Verfahren „Stochastisch gesperrt“; immer von einer Person freigegeben
Qualitätssperre	Aus einer QM-Prüfung, nicht aus einem Toleranzschlüssel	Wartet auf das Prüfergebnis, nicht auf die Abweichungslogik von MRBR

MRBR gruppiert gesperrte Rechnungen nach diesen drei Verfahren, und die Aktion Rechnung freigeben entfernt die Zahlungssperre der Lieferantenzeile, ändert aber die Positions-Sperrgründe darunter nicht. Lassen Sie die automatische Freigabe laufen, klärt sich nur das Abweichungsverfahren; alles andere bleibt genau dort, wo es war. Die erste Frage ist also nie, wie ich freigebe, sondern was sie hält — eine Toleranzüberschreitung, die eine Maschine neu bewerten kann, eine Entscheidung, die ein Mensch getroffen hat, oder eine Stichprobenregel, die ohnehin immer eine Freigabe von Hand brauchte.

Vorher und nachher: die Freigabe erzwingen vs. den richtigen Sperrgrund aufheben

Gegen den Freigabemechanismus arbeiten	Den richtigen Sperrgrund aufheben
Die automatische Freigabe wieder und wieder auf eine Rechnung angewandt, die sie nie klären konnte	Zuerst das Sperrverfahren bestimmt, dann den passenden Freigabeweg gewählt
Eine manuelle Zahlsperre wie eine Abweichung behandelt und in der Warteschlange sitzen gelassen	Die Zahlsperre im Kopf (ZLSPR) von Hand aufgehoben, denn die automatische Freigabe ignoriert sie planmäßig
Toleranzschlüssel PP in OMR6 geweitet, um eine Abweichungsrechnung durchzudrücken	Die Abweichung an der Quelle behoben und die Rechnung bei streng belassenen Toleranzen freigegeben
Den ganzen Beleg wieder aufgemacht, um einer einzigen markierten Position nachzugehen	Die eine markierte Position behoben; die Sperre der ganzen Rechnung fällt mit ihr
Eine Qualitätssperre an die Kreditorenbuchhaltung eskaliert, als wäre sie ein Zahlungsproblem	Das QM-Prüfergebnis geklärt — worauf die Qualitätssperre gewartet hat

Den richtigen Sperrgrund aufheben — nicht einfach die automatische Freigabe laufen lassen

1

Zuerst das Sperrverfahren bestimmen

Öffnen Sie die Rechnung in MRBR und lesen Sie, welches Verfahren sie hält: Wegen Abweichungen gesperrt, Manuelle Zahlungssperre oder Stochastisch gesperrt. Nur das erste kommt für die automatische Freigabe infrage. Alles Weitere hängt davon ab, diese eine Lesung richtig zu treffen.
2

Bei einer Abweichungssperre zuerst die Abweichung beheben, dann freigeben

Eine Preisabweichung auf dem Toleranzschlüssel PP, eine Mengenabweichung oder ein Einheitenproblem, das sich als Preis liest, klären sich alle, sobald die zugrunde liegende Zahl korrigiert ist. Was SAP beim Sperren vergleicht, definiert das Glossar Preisabweichung in der Rechnungsprüfung; eine Preisabweichungstoleranz, die nicht zu greifen scheint, ist wieder eine andere Lösung, und zeigt die Meldung auf Preis, obwohl die Zahl stimmt, liegt die Ursache meist in den Einheiten darunter (englische Fassung: the error says price, the cause is units). Den alten gegen den neuen Lieferantenpreis mit einem Preislisten-Diff abzugleichen zeigt oft, welche Zahl sich bewegt hat.
3

Eine manuelle Zahlsperre von Hand aufheben

Die Zahlsperre im Kopf in INVFO-ZLSPR („Zahlsperre“) wurde bewusst gesetzt — in MIRO oder programmatisch durch das BAdI MRM_PAYMENT_TERMS über dessen Parameter E_ZLSPR —, also entfernt kein automatischer Lauf sie. Nutzen Sie die Aktion Rechnung freigeben in MRBR, und denken Sie daran, dass sie nur die Zahlungssperre der Lieferantenzeile entfernt: Sie ändert keinen Positions-Sperrgrund (DRSEG-SPGRP für eine automatische Abweichung, DRSEG-SPGRQ für einen manuellen) darunter. Trägt eine Position zusätzlich einen Abweichungsgrund, begleicht das Aufheben der Kopfsperre allein die Rechnung nicht.
4

Prüfen, wer freigeben darf

Die Freigabe ist über die Berechtigungsobjekte M_RECH_SPG (Sperrgrund) und M_RECH_EKG (Einkäufergruppe) gesichert. Eine Freigabe, die still nichts bewirkt, ist oft eine fehlende Berechtigung, keine festhängende Rechnung.
5

Die Hintergrundfreigabe nur für Abweichungen einplanen

RM08RELEASE hebt planmäßig Sperren auf, deren Abweichungen sich inzwischen erledigt haben — ein Wareneingang, der endlich gebucht wurde, eine Preiskondition, die korrigiert wurde. Es hebt nie eine manuelle oder stochastische Sperre auf, also verlassen Sie sich nicht als Allheilmittel für die ganze Warteschlange darauf; diese beiden Verfahren brauchen weiterhin einen Menschen, und eine Rechnung, die auf eine automatische Freigabe wartet, die sie nicht sehen kann, altert still in der Kreditorenbuchhaltung.

Eine Freigabe-Checkliste in die Rechnungsprüfung einbauen

Das Sperrverfahren ist bestimmt — Wegen Abweichungen gesperrt, Manuelle Zahlungssperre oder Stochastisch gesperrt — bevor eine Freigabe versucht wird
Abweichungssperren werden an der Quelle behoben (Preis, Menge, Datum), nicht durch Weiten der OMR6-Toleranzen freigegeben
Eine manuelle Zahlsperre im Kopf (INVFO-ZLSPR) wird von Hand aufgehoben, nie der automatischen Freigabe überlassen
Die Positions-Sperrgründe werden gelesen — DRSEG-SPGRP (automatisch) und DRSEG-SPGRQ (manuell) —, da Rechnung freigeben die Lieferantenzeile klärt, aber diese nicht
Qualitätssperren werden auf das QM-Prüfergebnis geleitet, nicht als Toleranzabweichung behandelt
Die Freigabeberechtigung (M_RECH_SPG, M_RECH_EKG) ist für den bestätigt, der MRBR ausführt
RM08RELEASE ist nur für Abweichungssperren eingeplant, manuelle und stochastische Sperren werden von einer Person bearbeitet

Warum Identitätsauflösung die eigentliche Lösung ist

MRBR ist der Ort, an dem gesperrte Rechnungen auftauchen, aber nicht der Ort, an dem sie entstehen. Die meisten Abweichungssperren gehen auf eine Sache zurück: Die Rechnungsposition und die Bestellposition lösen sich nicht auf denselben Artikel, dieselbe Einheit oder denselben vereinbarten Preis auf, also berechnet SAP eine Differenz und hält die Zahlung. Geben Sie eine frei, reißt der nächste Lieferantenbeleg dieselbe Lücke wieder auf. Die dauerhafte Lösung ist, jede Rechnungsposition gegen einen vertrauenswürdigen Datensatz zu prüfen — den vereinbarten Preis, die richtige Einheit, den korrekten Umrechnungsfaktor —, bevor sie überhaupt in die Sperrwarteschlange gelangt, und genau das leistet der Abgleich jeder Rechnungsposition gegen vertrauenswürdige Katalogdaten. Dieselbe Mechanik trägt die englische Fassung dieses Leitfadens: Eine Sperre ist das Symptom zweier Datensätze, die gleich sein sollten und es nicht sind — löst man sie einmal auf, berechnet sich die Abweichung gar nicht erst, und MRBR wird wieder zur Ausnahmeliste statt zur täglichen Pflicht.

Kostenloses Tool

Preislisten-Diff

Alten und neuen Lieferantenpreis abgleichen, um zu sehen, welche Zahl sich bewegt hat, bevor sie eine Rechnung sperrt.

Tool

Marge- und Aufschlagsrechner

Prüfen, was ein freigegebener, aber falscher Preis mit der Marge macht, bevor Sie ihn zur Zahlung klären.

Tool

UNECE-Rec-20-Einheitencode-Validator

Bestätigen, dass Einheiten auf gültige Standardcodes abbilden, damit Bestell- und Preiseinheit vergleichbar bleiben.

Leitfaden

SAP „Preis zu hoch: Toleranzgrenze überschritten“

M8 082 / M8 083, Toleranzschlüssel PP und die OMR6-Einstellungen hinter einer Preissperre.

Leitfaden

Mengeneinheit nicht in Basismengeneinheit umrechenbar

Wenn SAP eine Rechnung sperrt, weil ein Umrechnungsfaktor im Materialstamm fehlt.

Leitfaden (englisch)

Releasing Blocked Invoices in SAP (MRBR)

Die englische Schwesterfassung: ZLSPR vs. SPGRP / SPGRQ und warum die automatische Freigabe eine manuelle Sperre nicht anrührt.

Playbook

Lieferantenattribute auf Ihr Schema abbilden

Lieferanteneinheiten, -preise und -umrechnungsfaktoren auf ein kanonisches Produktmodell auflösen.

Glossar

Was ist eine Preisabweichung in der Rechnungsprüfung?

Die Nachrichtenfamilie M8 082–085 und was SAP beim Sperren einer Rechnung eigentlich vergleicht.

FAQ

Was heißt es, dass eine Rechnung zur Zahlung gesperrt ist?

Eine zur Zahlung gesperrte Rechnung ist eine Rechnung, die SAP gebucht hat, aber nicht bezahlt: Der Beleg und seine Kontobewegungen werden gebucht, der Beleg trägt jedoch ein Sperrkennzeichen und kann erst beglichen werden, wenn ihn jemand freigibt. Die Rechnungsprüfung kennt vier Sperrgründe — Menge, Preis, Qualität und Datum. Die Qualität kommt aus einer QM-Prüfung, nicht aus einem Toleranzschlüssel; die anderen drei stammen aus den je Buchungskreis in OMR6 gepflegten Toleranzgrenzen. Die gesamte Rechnung wird zur Zahlung gesperrt, auch wenn nur eine Position abweicht.

Warum hebt die automatische Freigabe meine gesperrte Rechnung nicht auf?

Die automatische Freigabe hebt nur eines der drei MRBR-Sperrverfahren auf: Wegen Abweichungen gesperrt. Trägt die Rechnung eine manuelle Zahlungssperre oder wurde sie stochastisch gesperrt, rührt kein automatischer Lauf sie an — das schließt das Hintergrundprogramm RM08RELEASE ein. Eine manuelle Zahlsperre im Kopf muss insbesondere von Hand aufgehoben werden. Bevor Sie irgendeine Toleranz weiten, öffnen Sie die Rechnung in MRBR und prüfen Sie, welches Verfahren sie tatsächlich hält.

Was ist der Unterschied zwischen der Zahlsperre im Kopf und einem Positions-Sperrgrund?

Die Zahlsperre im Kopf liegt in INVFO-ZLSPR, in MIRO als Zahlsperre angezeigt, und wird entweder von Hand oder durch das BAdI MRM_PAYMENT_TERMS über dessen Exportparameter E_ZLSPR gesetzt. Ein Positions-Sperrgrund liegt auf der Zeile: DRSEG-SPGRP wird automatisch gesetzt, wenn eine Position eine Toleranz überschreitet, und DRSEG-SPGRQ ist ein manueller Sperrgrund, der auf der Bestellposition hinterlegt wird. Die Aktion Rechnung freigeben entfernt die Zahlungssperre der Lieferantenzeile, ändert aber diese Positions-Sperrgründe nicht.

Welche Transaktion gibt gesperrte Rechnungen frei, und welche Berechtigung braucht sie?

MRBR, Rechnungen freigeben, ist die Transaktion; RM08RELEASE ist das Hintergrundprogramm, das dieselbe Logik planmäßig ausführt. Die Freigabe ist über zwei Berechtigungsobjekte gesichert: M_RECH_SPG für den Sperrgrund und M_RECH_EKG für die Einkäufergruppe. Eine Freigabe, die scheinbar nichts bewirkt, ist oft eine fehlende Berechtigung und keine festhängende Rechnung — prüfen Sie diese Objekte, bevor Sie annehmen, die Sperre selbst sei das Problem.

Soll ich die Toleranz in OMR6 erhöhen, damit keine Rechnungen mehr gesperrt werden?

Nein. Die OMR6-Toleranzen werden je Buchungskreis gesetzt, und die gesamte Rechnung wird zur Zahlung gesperrt, auch wenn nur eine Position abweicht — ein Weiten eines Schlüssels wie PP, um die heutige Rechnung freizubekommen, akzeptiert still echte Preisfehler auf jeder folgenden Rechnung. Beheben Sie stattdessen die zugrunde liegende Abweichung an der Quelle: den falschen Preis, die falsche Menge oder den Umrechnungsfaktor dahinter. Bei einer manuellen oder stochastischen Sperre ist OMR6 ohnehin irrelevant, denn das sind gar keine Abweichungssperren.

REVIEW-NOTES

Hub-Verdrahtung teils aufgeschoben. Dies ist die deutsche Entsprechung der englischen releasing-blocked-invoices-mrbr. Inline verweist sie nur auf existierende Seiten: die deutschen Geschwister glossary/preisabweichung und guides/sap-preis-zu-hoch-toleranzgrenze (bevorzugt), die englischen Fallbacks guides/error-says-price-cause-is-units und guides/releasing-blocked-invoices-mrbr (im Ankertext als englisch gekennzeichnet) und das Tool tools/price-list-diff. Alle wurden vor dem Schreiben auf Existenz geprüft. Die Related-Karten zu den deutschen Geschwistern sind reine <Card href>-Links (nicht audit-geprüft); sie zeigen auf existierende Seiten. relatedSlugs ist bewusst weggelassen (nicht alle Karten sind garantiert vorhanden, und das Feld ist audit-geprüft). translations ist bewusst nicht gesetzt (wird zentral verlinkt, Brief Workflow Schritt 6) — die englische Schwester sollte zurückverlinken.
Genauigkeits-Nachweis. Vier Sperrgründe: Menge, Preis, Qualität, Datum — Qualität aus QM-Prüfung, nicht aus Toleranzschlüssel. Ganze Rechnung gesperrt, auch bei nur einer abweichenden Position. Felder: INVFO-ZLSPR (Zahlsperre im Kopf, in MIRO „Zahlsperre“), DRSEG-SPGRP (Positions-Sperrgrund, automatisch bei Toleranzüberschreitung), DRSEG-SPGRQ (manueller Sperrgrund auf der Bestellposition), E_ZLSPR (BAdI MRM_PAYMENT_TERMS), Sperrkennzeichen (OBB8 nicht im Fließtext zitiert, da nicht benötigt). Transaktionen: MIRO, MRBR, OMR6, OMRM (nur im Umfeld), RM08RELEASE. MRBR-Sperrverfahren verbatim: „Wegen Abweichungen gesperrt“, „Manuelle Zahlungssperre“, „Stochastisch gesperrt“ — automatische Freigabe nur für das erste; manuelle Kopf-Zahlsperre nicht durch automatische Freigabe aufgehoben (Kern). „Rechnung freigeben“ entfernt Zahlungssperre der Lieferantenzeile, ändert keine Positions-Sperrgründe. Berechtigungsobjekte: M_RECH_SPG, M_RECH_EKG. Alles aus dem Brief-Appendix. Kein M8-Kurztext wird verbatim zitiert, daher kein SE91-Abgleich nötig. Keine erfundenen Strings oder Statistiken.
CTA. Kein CTA-Abschnitt im Body — die Layout-CTA wird aus language: "de" + cta: "book-demo" gerendert („Schluss mit der manuellen Pflege“ / „Demo buchen“). Falls resolveCta() wider Erwarten noch nicht lokalisiert ist (offene Frage in SCHEMA-NOTES §4), muss das zentral behoben werden, nicht in dieser Datei.