Veröffentlicht am · Aktualisiert am · 9 Min. Lesezeit
Inhalt
Eine doppelt gebuchte Eingangsrechnung erzeugt einen zweiten offenen Posten, und der kann im nächsten Zahlungslauf bezahlt werden. Ein doppelt importierter Kontoauszug bucht Zahlungseingänge zweimal. Beides lässt sich vermeiden, wenn die Dublettenprüfung auf mehreren Ebenen ansetzt. Diese Seite zeigt, wie Dubletten entstehen, was jede Prüfebene erkennt und übersieht, was ERP-Systeme im Standard prüfen, am Beispiel von Microsoft Dynamics 365 Finance & Operations (F&O) und SAP S/4HANA, und was ORIMIZE Intelligent Invoice Capture (IIC) und ORIMIZE Intelligent Banking Suite (IBS) ergänzen, gleich mit welchem ERP Sie arbeiten.
Warum kommen Rechnungen und Kontoauszüge doppelt?
Dubletten entstehen selten durch einen einzelnen Fehler. Meist kommt derselbe Beleg über zwei Wege:
- E-Mail und Post. Der Lieferant schickt die Rechnung per E-Mail und zusätzlich auf Papier, die Papierrechnung wird gescannt.
- Mahnung mit Rechnung. Eine Zahlungserinnerung enthält die ursprüngliche Rechnung noch einmal als Anhang.
- E-Rechnung plus PDF-Kopie. Seit 2025 müssen Unternehmen E-Rechnungen empfangen können. Für Umsätze bis Ende 2026, bei einem Vorjahresumsatz bis 800.000 Euro auch für Umsätze bis Ende 2027, dürfen Aussteller noch Papierrechnungen und, mit Zustimmung des Empfängers, PDF-Rechnungen verschicken (§ 27 Abs. 38 UStG). In dieser Übergangszeit kommt zur XRechnung manchmal zusätzlich ein PDF (E-Rechnungspflicht).
- Mehrere Postfächer. Die Rechnung geht an das Rechnungspostfach und an den Ansprechpartner, der sie weiterleitet.
- Kontoauszug über zwei Kanäle. Der Auszug kommt automatisch per EBICS, und jemand lädt ihn zusätzlich aus dem Bankportal hoch.
- Erneuter Export. Eine Datei wird aus Portal, Bank oder Vorsystem noch einmal exportiert, etwa nach einem Fehler.
Vier Ebenen der Dublettenprüfung
Keine einzelne Prüfung findet alle Dubletten. Jede Ebene vergleicht etwas anderes und hat eigene blinde Flecken:
| Ebene | Was verglichen wird | Erkennt | Übersieht |
|---|---|---|---|
| 1. Gleiche Datei | Prüfsumme der Datei, etwa SHA-256 | dieselbe Datei aus zweitem Postfach, erneuten Upload, doppelten Abruf | Scan der Papierrechnung, PDF-Kopie neben der E-Rechnung, jede neu erzeugte Datei mit gleichem Inhalt |
| 2. Gleicher Inhalt | fachliche Merkmale des Belegs, bei Kontoauszügen etwa Konto, Auszugsnummer, Zeitraum und Salden | denselben Auszug als neue Datei oder aus einem zweiten Kanal | Fassungen, die sich in einem geprüften Merkmal unterscheiden |
| 3. Gleiche Rechnungsnummer je Kreditor | Rechnungsnummer gegen bereits erfasste oder gebuchte Rechnungen | Rechnung per E-Mail und Post, E-Rechnung plus PDF, Rechnung im Mahnungsanhang | abweichend erfasste Nummern, falsch zugeordneten Kreditor, doppelte Kreditorenkonten |
| 4. Unscharf: Betrag und Datum | ähnliche Beträge, Daten und Kreditoren | Dubletten mit Tippfehler in der Rechnungsnummer | meldet auch wiederkehrende Beträge wie Miete oder Abonnements; taugt als Hinweis, nicht als Sperre |
Für einen belastbaren Prozess kombinieren Sie die Ebenen. Die erste fängt technische Dubletten ab, bevor jemand Zeit in den Beleg steckt. Die dritte fängt fachliche Dubletten ab, und sie liegt in der Regel im ERP. Die vierte eignet sich als Kontrollbericht vor dem Zahlungslauf.
Was das ERP im Standard prüft
Die dritte Ebene bringen gängige ERP-Systeme selbst mit. Wie sie heißt und wann sie greift, unterscheidet sich je System. Zwei Beispiele:
SAP S/4HANA: Prüfung auf doppelte Rechnungen
In SAP aktivieren Sie die Prüfung auf doppelte Rechnungen („Check double invoice“) im Lieferantenstamm auf Buchungskreisebene. Laut SAP Learning vergleicht SAP dann Referenzbelegnummer, Buchungskreis, Lieferant, Währung und Belegdatum und warnt, wenn eine identische Rechnung erfasst wird; ist die Referenzbelegnummer leer, vergleicht SAP zusätzlich den Betrag in Belegwährung (SAP Learning). Die Prüfung wirkt also nur für Lieferanten, bei denen sie eingeschaltet ist, und setzt eine sauber erfasste Referenz voraus.
Dynamics 365 Finance: bereits verwendete Rechnungsnummer
Dynamics 365 Finance prüft Rechnungsnummern über den Parameter „Check the invoice number used“ (deutsch „Verwendete Rechnungsnummer prüfen“) auf der Registerkarte Rechnung der Kreditorenkontenparameter. Microsoft Learn beschreibt zwei Ablehnungsoptionen:
- „Reject duplicates within fiscal year“. Finance prüft beim Buchen der Rechnung anhand des Buchungsdatums auf doppelte Rechnungen (Microsoft Learn).
- „Reject duplicate“. Ist zusätzlich in der Funktionsverwaltung das Feature aktiv, das die Übermittlung an den Workflow bei einer bereits gebuchten Rechnungsnummer verbietet, erhält der Einreichende eine Warnung und kann die Nummer korrigieren, bevor die Rechnung in den Workflow geht (Microsoft Learn).
Die Prüfung setzt damit beim Einreichen in den Workflow oder beim Buchen an, verglichen wird mit gebuchten Rechnungen. Bis dahin kann eine Dublette bereits erfasst, kontiert und zur Freigabe verschickt sein. Prüfen Sie in einer Testumgebung, wie sich die gewählte Option mit Ihren Kreditoren, Geschäftsjahren und Journalen verhält.
Wer Microsofts Zusatzlösung Invoice capture nutzt, erhält dort eine Prüfung auf doppelte Dateien per Prüfsumme. Eine Prüfung, ob eine Rechnung mit derselben Nummer schon eingegangen ist, gibt es dort laut Learn nicht; sie lässt sich über eine eigene Erweiterung bei der Übergabe an Finance umsetzen (Microsoft Learn).
Kontoauszüge in Dynamics 365 Finance: Konto, Auszugs-ID und Zeitraum
Beim Import über die Erweiterte Bankabstimmung prüft Finance die Kombination aus AccountNo, StatementID, FromDate und ToDate. Stimmt sie mit einem vorhandenen Auszug überein, gilt der Auszug als Dublette und wird nicht importiert. Die Validierung prüft zusätzlich, ob der Anfangssaldo dem Endsaldo des vorherigen Auszugs entspricht, ob sich Zeiträume für dasselbe Bankkonto überschneiden und ob Anfangssaldo plus Zeilen den Endsaldo ergeben (Microsoft Learn).
Wann der Standard genügt: Kommen Rechnungen über einen einzigen Kanal und Kontoauszüge nur auf einem Weg ins ERP, decken die Prüfungen des ERP die häufigsten Fälle ab. Sie sind Teil des ERP, eine Zusatzlösung brauchen Sie dafür nicht.
Was ORIMIZE ergänzt
ORIMIZE arbeitet mit SAP, Microsoft Dynamics 365, DATEV und weiteren ERP-Systemen. Die folgenden Prüfungen laufen auf der ORIMIZE-Plattform, bevor ein Beleg an Ihr ERP geht.
IIC: Dieselbe Datei wird einmal verarbeitet
ORIMIZE IIC holt Rechnungen aus Microsoft-365-Postfächern und SharePoint ab und nimmt Uploads aus dem ERP und über die REST-API an. Jede Datei wird mit SHA-256-Prüfsumme gespeichert. Kommt dieselbe Datei in ORIMIZE erneut an, verarbeitet IIC sie nicht noch einmal und berechnet sie nicht doppelt: Eine Rechnung zählt einmal, im Monat ihrer ersten Datenerfassung (Preise).
Was IIC nicht prüft: IIC erkennt dieselbe Datei, nicht dieselbe Rechnung in einer anderen Datei. Ein Scan der Papierrechnung, die PDF-Kopie neben der XRechnung oder eine neu erzeugte Rechnung im Mahnungsanhang sind neue Dateien. Eine Prüfung gleicher Rechnungsnummern über verschiedene Dateien gehört nicht zu den Funktionen von IIC. Für diesen Fall ist die Prüfung in Ihrem ERP die Absicherung. Schalten Sie sie deshalb ein, in Dynamics 365 Finance etwa über „Check the invoice number used“, in SAP über die Prüfung auf doppelte Rechnungen im Lieferantenstamm.
Zwei Funktionen helfen trotzdem, bevor gezahlt wird:
- Kreditorabgleich. IIC gleicht den Rechnungssteller mit den Kreditoren aus Ihrem ERP ab und vergibt einen Konfidenzwert. Als Treffer gilt nur ein Kandidat mit hoher Sicherheit und klarem Abstand zum nächsten. Ein sauber zugeordneter Kreditor ist die Grundlage jeder kreditorbezogenen Prüfung, auch der im ERP.
- Stammdatenabgleich in Dynamics 365. Weichen importierte Rechnungs- oder Kreditorendaten vom Kreditorenstamm ab, zeigt IIC in Dynamics das Symbol „Abweichung Stammdatenabgleich“, etwa bei Bankdaten, Name, USt-IdNr. oder Anschrift. Der Stammdatenabgleich zeigt nur die abweichenden Felder und übernimmt ausgewählte Werte erst, wenn Sie bestätigen.
IBS: Kontoauszüge zweifach geprüft
ORIMIZE IBS erkennt doppelte Kontoauszüge zweifach: an der SHA-256-Prüfsumme der Datei und am Inhalt des Auszugs, also IBAN beziehungsweise Konto, Auszugsnummer oder -ID, Zeitraum, Währung, Anfangs- und Endsaldo sowie Anzahl der Buchungen. Geprüft wird je Unit und Umgebung. Kommt derselbe Auszug erneut, etwa einmal per EBICS und einmal per Upload, wird er nicht ein zweites Mal verarbeitet. Damit erkennt IBS auch einen neu exportierten Auszug, solange der Inhalt übereinstimmt. Wie IBS Kontoauszüge darüber hinaus zuordnet, beschreibt Kontoauszüge automatisch verbuchen.
Ein Hinweis aus der Praxis mit Dynamics 365: Setzen Sie einen bereits verarbeiteten Auszug in Dynamics mit Status zurücksetzen zurück, bleibt das erzeugte Journal bestehen. Prüfen Sie vorhandene Journale, bevor Sie erneut verarbeiten (Academy).
Wer prüft was? Beispiel Dynamics 365 Finance
| Ebene | Dynamics 365 Finance Standard | ORIMIZE |
|---|---|---|
| 1. Gleiche Datei | in Microsofts Invoice capture per Prüfsumme | IIC und IBS per SHA-256-Prüfsumme |
| 2. Gleicher Inhalt (Kontoauszug) | AccountNo, StatementID, FromDate und ToDate beim Import; Salden und Zeiträume bei der Validierung | IBS: IBAN, Auszugsnummer, Zeitraum, Währung, Salden und Anzahl der Buchungen |
| 3. Gleiche Rechnungsnummer | Parameter „Check the invoice number used“ | keine eigene Prüfung; Kreditorabgleich und Stammdatenabgleich unterstützen |
| 4. Unscharf | auf den zitierten Learn-Seiten nicht beschrieben | nicht Teil der hier beschriebenen Funktionen |
Mit SAP sieht die Aufteilung ähnlich aus: Die dritte Ebene übernimmt die Prüfung auf doppelte Rechnungen in SAP, die erste und für Kontoauszüge die zweite Ebene übernimmt ORIMIZE.
Gebuchte Rechnungen und Kontoauszüge lassen sich in ORIMIZE nicht löschen, nur mit Begründung stornieren. Warum das zählt, beschreibt der Beitrag GoBD im automatisierten Rechnungseingang: Storno statt Löschen.
Checkliste: Dubletten vermeiden
- Ein zentraler Eingang. Ein Rechnungspostfach je Gesellschaft, das automatisch abgeholt wird. Wer Rechnungen an persönliche Adressen bekommt, verweist den Lieferanten auf dieses Postfach.
- Lieferanten informieren. Bitten Sie darum, jede Rechnung nur einmal und nur an diese Adresse zu senden: die E-Rechnung ohne zusätzliche PDF-Kopie, Mahnungen ohne erneut angehängte Rechnung.
- Papier prüfen, bevor es gescannt wird. Ist dieselbe Rechnung schon digital eingegangen, wird der Ausdruck nicht noch einmal erfasst.
- Prüfung im ERP einschalten und testen. In Dynamics 365 Finance „Check the invoice number used“ auf eine Ablehnungsoption stellen und bei Bedarf das Feature für den Workflow aktivieren; in SAP die Prüfung auf doppelte Rechnungen für alle Lieferanten aktivieren. Das Verhalten in einer Testumgebung prüfen.
- Rechnungsnummern einheitlich erfassen. Ohne zusätzliche Präfixe, Leerzeichen oder Datumsanteile, damit gleiche Nummern auch gleich verglichen werden.
- Kreditorenstamm sauber halten. Doppelte Kreditorenkonten für denselben Lieferanten unterlaufen jede kreditorbezogene Prüfung.
- Ein produktiver Weg je Bankkonto. Kontoauszüge kommen auf genau einem Weg produktiv ins System, ein zweiter Kanal dient nur als Ausfallweg.
- Vor dem Zahlungslauf prüfen. Offene Posten nach gleichem Kreditor, Betrag und Datum durchsehen. Das ist die vierte Ebene als Kontrollbericht.
- Gebuchte Dubletten stornieren, nicht löschen.
Mehr zu Prüfung und Zuordnung vor der Buchung zeigt Matching & Validierung, den ganzen Weg vom Postfach bis zur Buchung Rechnungseingang automatisieren. Begriffe wie Dublette, Storno und GoBD erklärt das Lexikon. In einer Demo zeigen wir, wie IIC und IBS mit Dubletten umgehen.
Quellen
- Microsoft Learn: Vendor invoices overview, https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/vendor-invoices-overview
- Microsoft Learn: Vendor invoice dates, https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/vendor-invoice-dates
- Microsoft Learn: Invoice capture received files, https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/invoice-capture-rec-files
- Microsoft Learn: Reconcile bank statements by using advanced bank reconciliation, https://learn.microsoft.com/en-us/dynamics365/finance/cash-bank-management/reconcile-bank-statements-advanced-bank-reconciliation
- SAP Learning: Explaining Supplier Master Data Fields Relevant for Payables Management, https://learning.sap.com/courses/explaining-payables-management-master-data/explaining-supplier-master-data-fields-relevant-for-payables-management_c9fa0ac7-354f-45f5-a3f1-3e2964393059
- Bundesministerium der Justiz: § 27 Umsatzsteuergesetz, Allgemeine Übergangsvorschriften, https://www.gesetze-im-internet.de/ustg_1980/__27.html
Stand: Oktober 2026.