SAP Dublettenprüfung: doppelte Rechnungen erkennen, die die Standardprüfung übersieht

SAP hat eine eingebaute Dublettenprüfung – aber sie hängt am Referenzfeld, greift erst beim Buchen und kennt nur, was schon in SAP steht. Wo sie zuverlässig ist, wo sie blind bleibt und wie eine Prüfung vor SAP die teuren Fälle abfängt.

Fast jedes SAP-System prüft auf doppelte Rechnungen – und trotzdem gehören Doppelzahlungen zu den häufigsten und teuersten Fehlern im Rechnungseingang. Das ist kein Widerspruch, sondern eine Frage des Wann und Woran: Die SAP-Standardprüfung ist gut in dem, was sie prüft, aber sie prüft spät und an einem Feld, das genau dann versagt, wenn es darauf ankommt.

Was die SAP-Standard-Dublettenprüfung kann

In der Logistik-Rechnungsprüfung (Transaktion MIRO) und in der Finanzbuchhaltung (FB60) ist eine Dublettenprüfung eingebaut. Ist im Lieferantenstamm das Kennzeichen „Prüfung Doppelerfassung" gesetzt, vergleicht SAP eine neue Rechnung mit den bereits erfassten und schlägt bei Übereinstimmung Alarm – über die Meldungen der Klasse M8 (etwa 108 und 462).

Verglichen wird, je nach Customizing, eine Kombination aus Buchungskreis, Lieferant, Währung, Referenz (der Rechnungsnummer im Feld Referenz/XBLNR), Rechnungsdatum und Betrag. Für sauber und einheitlich erfasste Rechnungen desselben Lieferanten funktioniert das zuverlässig. Als letzte Instanz vor dem Buchen ist die Prüfung wertvoll und sollte in jedem System aktiv sein.

Wo sie blind bleibt

Die Grenzen liegen nicht im Vergleich selbst, sondern in seinen Voraussetzungen:

• Sie hängt am Referenzfeld. Die Rechnungsnummer muss in die Referenz gelangen – und zwar identisch. Ein Tippfehler, führende Nullen, ein Leerzeichen oder eine andere Schreibweise, und SAP hält zwei Einreichungen für zwei verschiedene Belege. Gerade bei manueller Erfassung ist das der Normalfall, nicht die Ausnahme.
• Sie greift erst beim Buchen. Geprüft wird im Moment der Erfassung in SAP. Was auf dem Weg dorthin passiert – zwei Personen, zwei Kanäle, zwei Erfassungen – sieht SAP nicht.
• Sie kennt nur, was schon in SAP steht. Kommt dieselbe Rechnung als E-Mail-PDF *und* per Post, und erfasst sie jemand parallel in einem Vorsystem oder per Papierweg, entstehen zwei Vorgänge, die SAP nie nebeneinander sieht.
• Das Kennzeichen ist optional. Ist „Prüfung Doppelerfassung" im Lieferantenstamm nicht oder uneinheitlich gesetzt, findet gar keine Prüfung statt – still.
• Mahnung und erneute Rechnung. Eine Zahlungserinnerung mit denselben Beträgen oder eine erneut geschickte Rechnung mit leicht geänderter Nummer läuft an der referenzgebundenen Prüfung vorbei.

Das Muster ist immer dasselbe: Die SAP-Prüfung fängt die sauberen Dubletten. Die teuren sind die unsauberen – und genau die entstehen, bevor SAP überhaupt beteiligt ist.

Warum der Zeitpunkt über die Kosten entscheidet

Eine Dublette, die vor der Erfassung gestoppt wird, kostet nichts. Eine Doppelzahlung, die durchläuft, wird zum Rückholfall: Die zweite Zahlung ist ohne Rechtsgrund geleistet und nach § 812 BGB zurückzufordern – ein Anspruch, der nach § 195 BGB verjährt und bei einem insolventen Lieferanten ganz verloren sein kann. Zwischen „gar nicht erst entstanden" und „mühsam zurückgeholt" liegt der gesamte Aufwand, um den es geht. Deshalb ist die entscheidende Frage nicht, *ob* geprüft wird, sondern *wann*.

Der zweite Anker: Prüfung vor der Buchung

Wirksam wird die Dublettenerkennung, wenn sie vor SAP ansetzt und nicht am Referenzfeld hängt. Eine vorgelagerte Eingangsprüfung bildet aus Lieferant, Rechnungsnummer und Betrag einen Fingerabdruck und gleicht jede eingehende Rechnung dagegen ab – kanal- und formatübergreifend, unabhängig davon, ob die Nummer später sauber ins Referenzfeld getippt wird. Taucht derselbe Fingerabdruck ein zweites Mal auf, wird die Einreichung gesperrt, bevor ein zweiter Buchungsvorgang entsteht.

Das ersetzt die SAP-Prüfung nicht, sondern ergänzt sie: SAP bleibt die letzte Instanz beim Buchen, die vorgelagerte Prüfung fängt die Fälle ab, die es dort nie hin schaffen sollten. Dieselbe Logik, die Doppelzahlungen grundsätzlich verhindert, greift damit schon am Eingang – und zahlt auf das ein, was eine belastbare Dunkelverarbeitung überhaupt erst erlaubt: automatisch buchen, aber nur, was wirklich sauber ist.

Fazit

Die SAP-Standard-Dublettenprüfung ist ein Boden, keine Decke. Sie prüft zuverlässig, aber spät und am Referenzfeld – und übersieht damit genau die Konstellationen, aus denen Doppelzahlungen tatsächlich entstehen: zwei Kanäle, uneinheitliche Nummern, Erfassung außerhalb von SAP. Eine der SAP-Buchung vorgelagerte Prüfung schließt diese Lücke, ohne dass es dafür ein SAP-Projekt braucht – was für die Anbindung nötig ist, ist überschaubar. Dieser Beitrag ordnet ein und ersetzt keine steuerliche Beratung.