5 Lücken bei der Erkennung doppelter Rechnungen
Die AP-Teams Tausende kosten

Die 4 Wege, auf denen doppelte Rechnungen in Ihre Warteschlange gelangen – und drei davon werden Sie nicht bemerken

Überspringen wir die generische Kategorie „Dateneingabefehler", mit der jeder Artikel beginnt. Sie wissen bereits, dass Tippfehler Probleme verursachen. Die Duplikate, die tatsächlich Geld kosten, sind diejenigen, die auf den ersten Blick unterschiedlich genug aussehen, um jede Prüfung zu umgehen, die Sie haben – aber dieselbe Verpflichtung darstellen.

1. Der „Wir haben das bereits bezahlt"-Erneuter Versand

Ein Lieferant sendet eine Rechnung. Ihre AP-Abteilung verarbeitet sie, plant die Zahlung, alles ist in Ordnung. Drei Wochen später sendet der Lieferant dieselbe Rechnung erneut – diesmal mit dem Vermerk „Zweite Mahnung" oder „Erinnerung". Der AP-Sachbearbeiter, der sie öffnet, ist nicht derselbe, der die ursprüngliche verarbeitet hat. Er erkennt sie nicht. Die Rechnungsnummer ist dieselbe, aber das Datum der Mahnung ist drei Wochen neuer, sodass eine datumsgefilterte Suche sie übersieht. Die Rechnung wird erneut erfasst. Die Zahlung geht doppelt raus.

Das ist nicht selten. Es ist die häufigste Quelle für Duplikate in Unternehmen, die über 200 Rechnungen pro Monat verarbeiten, und es passiert, weil das AR-System des Lieferanten und Ihr AP-System keine Verbindung haben. Ihr Lieferant weiß nicht, dass Sie die Zahlung geplant haben. Sein automatisierter Mahnzyklus feuert unabhängig davon nach 30 Tagen.

2. Die Zwei-Kanal-Kollision

Dieselbe Rechnung, zwei Lieferkanäle. Der Lieferant sendet eine PDF per E-Mail an [email protected] und übermittelt gleichzeitig dieselbe Rechnung per EDI an den elektronischen Eingang Ihres ERP. Der E-Mail-Anhang landet in der manuellen Verarbeitungswarteschlange. Die EDI-Übertragung erstellt automatisch einen Datensatz im System. Zwei verschiedene Sachbearbeiter, zwei verschiedene Verarbeitungswege, eine zugrunde liegende Verpflichtung – und keine Querverbindung zwischen den beiden Warteschlangen, weil sie in verschiedenen Systemen leben.

Dieses Problem wird mit der Modernisierung von Unternehmen schlimmer, nicht besser. Je mehr Kanäle Sie für die Übermittlung von Lieferantenrechnungen öffnen – E-Mail, Portal, EDI, Papierpost –, desto mehr Einstiegspunkte schaffen Sie dafür, dass dieselbe Rechnung doppelt landet. Eine Hybridumgebung, in der PDF- und strukturierte Rechnungsformate nebeneinander existieren, ist besonders anfällig: Der strukturierte Kanal (EDI/XML) geht ohne menschliche Prüfung direkt durch, während die PDF-Kopie im Posteingang eines Sachbearbeiters wartet, um abgetippt zu werden.

3. Die ursprüngliche und die korrigierte Doppelerfassung

Ein Lieferant stellt fest, dass er bei Rechnung Nr. 4521 einen Fehler gemacht hat, und stellt eine korrigierte Version aus – Rechnung Nr. 4521-C, gleicher Betrag, korrigierte Positionen. Der AP-Sachbearbeiter erhält beide. Die ursprüngliche Rechnung kam vor zwei Wochen an und wurde bereits erfasst. Die korrigierte Version trifft jetzt ein. Der Sachbearbeiter sieht das Suffix „-C", versteht, dass es sich um eine Korrektur handelt, und erfasst sie ebenfalls – aber niemand storniert die ursprüngliche Erfassung. Zwei Rechnungen, zwei Zahlungen, eine Verpflichtung.

Was passieren sollte: Die korrigierte Rechnung löst eine Stornierung der ursprünglichen aus, bevor die neue erfasst wird. Was tatsächlich passiert: In den meisten Mid-Market-AP-Workflows gibt es keine automatische Verknüpfung zwischen einer ursprünglichen Rechnung und ihrer korrigierten Version. Das Suffix „-C" ist eine menschliche Konvention, die ERP-Systeme nicht interpretieren. Wenn der Sachbearbeiter vergisst, die ursprüngliche Rechnung manuell zu stornieren – oder wenn ein anderer Sachbearbeiter die ursprüngliche Rechnung bearbeitet hat – geht die Duplikatbuchung durch.

4. Die monatsübergreifende Wiederholung

Eine Rechnung für einen wiederkehrenden Service trifft im März für die Februargebühren ein. Dieselbe Rechnung – gleiche PO-Referenz, gleicher Betrag – trifft im April erneut ein, weil der Lieferant sein Abrechnungssystem migriert und alle offenen Rechnungen unter neuen Nummern neu ausgestellt hat. Ihre März-Erfassung liegt im März-Hauptbuch. Ihre April-Erfassung ist eine neue Transaktion. Eine VLOOKUP-Funktion in der Rechnungsnummerspalte findet keine Übereinstimmung, weil die Nummern unterschiedlich sind. Eine VLOOKUP-Funktion beim Betrag findet eine exakte Übereinstimmung – aber das tut auch jede andere wiederkehrende Monatsrechnung dieses Lieferanten.

Monatsübergreifende Duplikate sind manuell am schwersten zu erkennen, weil sie den natürlichen Rhythmus der AP-Arbeit ausnutzen: Jede Monatscharge wird isoliert verarbeitet. Niemand vergleicht die Rechnungen dieses Monats mit dem bereits bezahlten Hauptbuch des Vormonats, es sei denn, etwas löst diese Prüfung gezielt aus. Und der Auslöser – eine doppelte Zahlung, die die Bank freigibt – trifft oft 30 bis 60 Tage nach der zweiten Erfassung ein.

Warum die Duplikatprüfung Ihrer Tabelle ständig fehlschlägt – 5 konkrete Fehlerursachen

Wenn Sie eine manuelle Duplikatprüfung aufgebaut haben – und die meisten AP-Teams haben das – sieht sie wahrscheinlich so aus: eine gemeinsame Excel-Datei oder Google Sheet mit allen erfassten Rechnungen und eine regelmäßige VLOOKUP-Funktion oder bedingte Formatierungsregel, die Zeilen hervorhebt, in denen die Rechnungsnummer mehr als einmal vorkommt. Das ist der richtige Ansatz. Aber er übersieht die meisten Duplikate. Hier genau, wo es scheitert.

Fehler 1: Inkonsistente Rechnungsnummernformate

Lieferant A verwendet „INV-004521.“ Lieferant B verwendet „4521.“ Lieferant C verwendet „INV4521-2026-03.“ Eine VLOOKUP-Funktion, die nach „INV-004521“ sucht, findet „4521“ nicht – obwohl beide dasselbe Dokument darstellen. Schlimmer noch: Derselbe Lieferant kann sein eigenes Format variieren: „INV-4521“ im PDF-Kopf, „4521“ in der E-Mail-Betreffzeile, „INV4521“ im EDI-Feed. Wenn Ihr AP-Sachbearbeiter die Rechnungsnummer aus der ersten Quelle übernimmt, die er sieht, gelangt dieselbe Rechnung unter drei verschiedenen Kennungen in Ihre Tabelle – und Ihre Duplikatprüfung sieht drei eindeutige Datensätze.

Fehler 2: Abweichende Lieferantennamen

„Acme Industrial Supply Inc.“ gegenüber „Acme Industrial Supply“ gegenüber „Acme Ind Supply.“ Selbst innerhalb der Rechnungen eines einzelnen Lieferanten kann der Firmenname im Kopf von der Zahlungsempfänger-Bezeichnung in den Zahlungsanweisungen abweichen. Ihre VLOOKUP-Funktion auf den Lieferantennamen liefert keine Übereinstimmung – aber der zugrunde liegende Lieferant ist identisch. Die APQC-Benchmarks kennzeichnen eine schlechte Pflege der Lieferantenstammdaten als Haupttreiber für Doppelzahlungen: Wenn derselbe Lieferant unter mehreren Datensätzen existiert, sieht eine auf eine Lieferanten-ID begrenzte Duplikatprüfung den anderen Eintrag nie.

Fehler 3: Beträge, die übereinstimmen sollten – es aber nicht ganz tun

Rechnung #4521 weist eine Summe von $1.247,50 auf. Die korrigierte Version – Rechnung #4521-C mit korrigierter Position – weist $1.247,53 auf. Eine Differenz von drei Cent. Ihre VLOOKUP-Funktion auf der Betragsspalte liefert keine Übereinstimmung. Die Rechnungen repräsentieren dieselbe Verpflichtung mit einer Abweichung von 0,002 %, aber Ihre Formel behandelt sie als völlig unabhängig. Das passiert ständig bei Steueranpassungen, Rundungsdifferenzen und Teilgutschriften, die die Summe um Centbeträge verschieben.

Fehler 4: PO-Referenz stimmt nicht überein

Sie prüfen auf Duplikate, indem Sie die PO-Nummer abgleichen – und das funktioniert, bis es nicht mehr funktioniert. Ein Lieferant sendet zwei Rechnungen zur selben PO, weil die PO zwei separate Lieferungen abdeckte. Beide sind legitim. Das Duplikat ist die dritte Rechnung zu dieser PO – eine erneut ausgestellte Kopie der ersten – und sie trägt dieselbe PO-Referenz. Ihre PO-basierte Prüfung kennzeichnet alle drei als mögliche Duplikate und erzwingt eine manuelle Prüfung jeder Zeile, statt das einzelne tatsächliche Duplikat zu isolieren. Die PO-Erkennung erkennt gleichzeitig zu viel und zu wenig.

Fehler 5: Der zeitliche blinde Fleck

Ihre Duplikatprüfung läuft auf den Daten dieses Monats. Sie berücksichtigt weder die bezahlten Konten des Vormonats, die abgeschlossene Charge des letzten Quartals noch die archivierte Datei des letzten Jahres. Ein Duplikat, das eine Monatsgrenze überspannt – Original im März, Wiederholung im April – bleibt unsichtbar. Die meisten Teams entdecken solche Fälle erst beim vierteljährlichen Bankabgleich, wenn das Geld bereits seit über 60 Tagen ausgezahlt ist. Die Rückforderung einer Doppelzahlung nach 60 Tagen ist exponentiell schwieriger: Der Lieferant hat sie möglicherweise bereits in seiner Buchhaltung verbucht, das ACH-Rückbuchungsfenster ist geschlossen, und das Gespräch wechselt von „Bitte erstatten Sie dies" zu „Lassen Sie uns eine Gutschrift aushandeln."

Eine 4-Felder-Erkennungsebene, die mit dem arbeitet, was Sie bereits haben

Die gute Nachricht: Sie müssen keine AP-Automatisierungsplattform kaufen, um das zu beheben. Sie brauchen eine Fähigkeit, die Sie derzeit nicht haben – die zuverlässige Extraktion von vier Feldern aus jeder Rechnung – und eine Prozessänderung, die nichts kostet.

Die vier Felder sind: Rechnungsnummer, Lieferantenname, Gesamtbetrag und PO (Bestellung). Nicht ein einziges Feld wird exakt abgeglichen. Vier Felder werden gemeinsam verglichen, wobei eine Übereinstimmung bei drei von vier Feldern ein Prüf-Flag auslöst.

So sieht Ihre Erkennungslogik aus:

Deshalb funktioniert der Drei-von-Vier-Abgleich, wenn der Einzelfeld-Abgleich scheitert:

• Das Rechnungsnummernformat variiert → aber Lieferantenname und Betrag stimmen überein → markiert.
• Der Lieferantenname ist inkonsistent → aber Rechnungsnummer und Betrag stimmen überein → markiert.
• Der Betrag weicht um drei Cent ab (korrigierte Rechnung) → aber Rechnungsnummer (teilweise), Lieferantenname und PO (Bestellung) stimmen überein → markiert.
• Wiederholung über Monatsgrenzen mit anderer Rechnungsnummer → Lieferantenname, Betrag und PO (Bestellung) stimmen überein → markiert – vorausgesetzt, Ihre Tabelle enthält die Zeilen des letzten Monats und des vorherigen Quartals.

Die Schwelle von drei Übereinstimmungen ist bewusst gewählt. Zwei Übereinstimmungen (gleicher Lieferant, gleicher Betrag) markieren jede wiederkehrende Monatsrechnung als Fehlalarm. Vier Übereinstimmungen erfassen nur exakte Klone – die am einfachsten zu erkennen und am seltensten sind. Drei von vier ist der Goldlöckchen-Bereich: empfindlich genug, um Fast-Klone zu erfassen, spezifisch genug, um Ihren Prüfer nicht in Rauschen zu ertränken.

Der Engpass ist natürlich Schritt 1: das zuverlässige Extrahieren dieser vier Felder aus Dutzenden oder Hunderten von Rechnungs-PDFs pro Woche. Die manuelle Eingabe ist genau das, was die Dateneingabefehler überhaupt erst verursacht.

Hier verändert KI-Extraktion die Gleichung. Statt jedes PDF zu öffnen und vier Felder einzutippen, laden Sie den Stapel Rechnungen hoch und geben die vier gewünschten Spaltennamen an – Rechnungsnummer, Lieferantenname, Gesamtbetrag, PO (Bestellung). Die KI liest jedes Dokument, findet die entsprechenden Werte unabhängig davon, wo sie auf der Seite stehen, und gibt eine strukturierte Tabelle mit einer Zeile pro Rechnung aus. Sie kopieren diese Tabelle in Ihre Master-Tabelle, und die bedingte Formatierung erledigt den Rest.

Probieren Sie es selbst aus – laden Sie eine Beispielrechnung hoch und sehen Sie, wie die vier Felder in Sekundenschnelle extrahiert werden:

Dieser Ansatz funktioniert, weil er nicht versucht, klüger zu sein als der AP-Sachbearbeiter. Er automatisiert den repetitiven Teil – das Lesen von Dokumenten und das Eintippen von Feldern – und überlässt den Beurteilungsteil – „Ist das tatsächlich ein Duplikat oder eine legitime zweite Rechnung?" – genau dort, wo er hingehört: bei der Person, die die Lieferantenbeziehung versteht. Wie wir im Framework zur Automatisierung der Rechnungsfreigabe besprochen haben, ersetzen die effektivsten Automatisierungsstrategien nicht den Workflow. Sie ersetzen den Schritt der Datenaufbereitung, der in diesen Workflow einfließt.

Wenn der Algorithmus Ihnen den Vortritt lassen sollte

Der Drei-von-Vier-Abgleich markiert die verdächtigen Zeilen. Was er nicht kann – und auch nicht versuchen sollte – ist, die endgültige Entscheidung zu treffen. Hier sind die Grenzfälle, in denen die automatisierte Erkennung ein Muster korrekt identifiziert, aber menschliches Urteilsvermögen erforderlich ist, um es zu interpretieren.

Der Unterschied von drei Cent

Rechnung #4521: 1.247,50 $. Rechnung #4521-C: 1.247,53 $. Drei Felder stimmen überein, der Betrag weicht um 0,03 $ ab. Markiert.

Dabei handelt es sich höchstwahrscheinlich um ein Duplikat – aber „höchstwahrscheinlich" reicht nicht aus, um eine Zahlung zu stornieren. Die drei Cent könnten eine Steuerrundungsanpassung sein, die die korrigierte Version zu einem legitimen Ersatz macht. Es könnte eine Währungsumrechnungsschwankung sein, wenn der ursprüngliche Betrag in EUR angegeben und die korrigierte Version zu einem leicht abweichenden Kurs umgerechnet wurde. Die Aufgabe des Algorithmus ist es, das Paar aufzuzeigen. Ihre Aufgabe ist es zu prüfen, ob der Lieferant beabsichtigt hat, die ursprüngliche Rechnung zu ersetzen, und wenn ja, den ursprünglichen Eintrag zu stornieren, bevor Sie die Korrektur verarbeiten. Wenn Sie die Absicht nicht feststellen können, klärt ein 60-sekündiger Anruf oder eine E-Mail an den Lieferanten die Sache.

Mehrere legitime Rechnungen zu einer PO (Bestellung)

Ein Baulieferant liefert Materialien in drei Sendungen zur PO (Bestellung) #7842. Jede Sendung erzeugt eine separate Rechnung: #INV-112, #INV-113, #INV-114. Gleicher Lieferant, gleiche PO (Bestellung), unterschiedliche Rechnungsnummern, unterschiedliche Beträge. Der Drei-von-vier-Abgleich markiert alle, weil Lieferant und PO (Bestellung) bei jedem Paar übereinstimmen. Aber alle drei sind legitim.

Dies ist das häufigste Fehlalarm-Szenario, und genau deshalb verwendet der Vier-Felder-Ansatz bedingte Formatierung plus menschliche Prüfung statt automatischer Blockierung. Der Algorithmus hebt das Muster hervor. Sie erkennen es als legitime Teillieferung – und löschen die Markierungen in zwei Sekunden. Wenn Sie eine Regel konfiguriert hätten, die jede PO (Bestellung) mit mehreren Rechnungen automatisch blockiert, hätten Sie drei legitime Zahlungen zurückgehalten und drei Lieferanten anrufen müssen, um zu erklären, warum.

Der Lieferant, der das Rechnungsnummernformat geändert hat

Ein Lieferant migriert sein ERP. Sein altes Rechnungsformat war „ACME-YYMM-####." Das neue Format ist eine fortlaufende achtstellige Nummer: „00004521." Die erste Rechnung im neuen System trifft für eine wiederkehrende monatliche Gebühr ein. Gleicher Lieferant, gleicher Betrag, gleiche PO (Bestellung) – aber das Rechnungsnummernformat ist nicht wiederzuerkennen. Der Drei-von-vier-Abgleich erkennt es, weil die anderen drei Felder übereinstimmen. Ohne diese Querprüfung sieht Ihre Tabellenkalkulation eine neue Rechnungsnummer und lässt sie durch.

Dieses Szenario ist besonders gefährlich angesichts der E-Rechnungsvorschriften, die in ganz Europa eingeführt werden. Wenn Lieferanten von PDF auf strukturierte XML-Formate über Peppol-Netzwerke umstellen, ändern sich ihre Rechnungsnummerierungsschemata oft – manchmal aus regulatorischen Gründen (z. B. Frankreichs Anforderung einer eindeutigen fortlaufenden Nummer ohne Lücken). Ein AP-Team, das sich ausschließlich auf den Abgleich der Rechnungsnummern verlässt, behandelt diese formatgewechselten Rechnungen als neue Datensätze, selbst wenn sie dieselbe wiederkehrende Verpflichtung darstellen wie die PDF-Version vom letzten Monat.

Währungs- und Wechselkursnuancen

Ein internationaler Lieferant stellt in EUR in Rechnung. Ihr System erfasst den USD-Gegenwert zum Wechselkurs am Verarbeitungsdatum. Dieselbe Rechnung trifft erneut ein – möglicherweise über einen anderen Kanal – und wird an einem anderen Datum mit einem leicht abweichenden Wechselkurs verarbeitet. Die USD-Beträge unterscheiden sich um ein paar Dollar. Lieferantenname stimmt überein. PO (Bestellung) stimmt überein. Rechnungsnummer stimmt überein. Der Betrag ist ähnlich, aber nicht exakt.

Der Algorithmus sollte dies kennzeichnen – und er tut es, weil drei Felder exakt übereinstimmen. Die manuelle Prüfung bestätigt, dass es sich um dieselbe EUR-Rechnung handelt, die zweimal unter unterschiedlichen Wechselkursen verarbeitet wurde. Sie stornieren den zweiten Eintrag. Ohne die Mehrfeldprüfung hätten die unterschiedlichen USD-Beträge einen Einzelfeldvergleich davon überzeugt, dass es sich um verschiedene Rechnungen handelt.

Aus diesem Grund ist es auch praktischer, Rechnungsfelder in eine Tabellenkalkulation zu extrahieren, als Erkennungslogik in eine Black-Box-AP-Plattform einzubetten. Sie können die Daten sehen, Sie können sehen, welche drei Felder übereinstimmten, Sie können die ursprüngliche Zeile direkt über der markierten Zeile sehen – und Sie können in Sekundenschnelle eine Entscheidung treffen, basierend auf allem, was Sie über diesen Lieferanten wissen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Duplikaterkennung und 3-Wege-Abgleich?

Der 3-Wege-Abgleich prüft, ob eine Rechnung mit einer Bestellung und einem Wareneingang übereinstimmt – und bestätigt, dass Sie für etwas bezahlen, das Sie bestellt und erhalten haben. Die Duplikaterkennung fragt, ob Sie diese Rechnung bereits zuvor bezahlt haben. Sie schützen vor unterschiedlichen Risiken. Ein Lieferant kann eine perfekt abgestimmte Rechnung senden, die den 3-Wege-Abgleich besteht – und sie drei Wochen später erneut senden, und sie besteht erneut, weil sich PO und Wareneingang nicht geändert haben. Der 3-Wege-Abgleich bestätigt das Was. Die Duplikaterkennung bestätigt das Wie oft.

Kann mein ERP das automatisch?

Die meisten Mid-Market-ERP-Systeme – QuickBooks, Xero, NetSuite – verfügen über eine grundlegende Duplikaterkennung, die auf exakte Übereinstimmungen der Rechnungsnummer innerhalb desselben Lieferantendatensatzes prüft. QuickBooks kennzeichnet eine Rechnung, wenn dieselbe Kombination aus Lieferant und Rechnungsnummer bereits existiert. Das erfasst exakte Duplikate – dieselbe Rechnung, zweimal mit derselben Nummer eingegeben – und übersieht alles andere, was wir besprochen haben: Formatvarianten, kanalübergreifende Einreichungen, Original-plus-korrigierte-Paare und monatsübergreifende Wiederholungen mit unterschiedlichen Nummern. Wenn Ihr Duplikatproblem auf exakte Nummernübereinstimmungen beschränkt ist, ist Ihr ERP bereits ausreichend. Wenn Sie diesen Artikel lesen, ist das wahrscheinlich nicht der Fall.

Wie viele Rechnungen muss ein Team verarbeiten, bevor sich das lohnt?

Die Rechnung ist einfach. Bei 200 Rechnungen pro Monat und einer geschätzten Duplikatrate von 0,5 % (konservativ für Teams ohne automatisierte Kontrollen) ergibt das ein Duplikat pro Monat. Wenn der durchschnittliche Rechnungswert in Ihrem Unternehmen über $800 liegt, amortisiert sich ein Duplikat pro Monat die Extraktionszeit um ein Vielfaches – noch bevor die eingesparte Personalzeit für manuelle VLOOKUP-Funktionen berücksichtigt wird. Unter 50 Rechnungen pro Monat ist die manuelle Prüfung jeder Rechnung wahrscheinlich immer noch schneller als die Einrichtung eines automatisierten Workflows. Zwischen 50 und 200 wird der Ansatz mit Extraktion und Kennzeichnung mit steigendem Volumen zunehmend wertvoller.

Was, wenn ein Lieferant dieselbe Rechnung in zwei verschiedenen Währungen sendet?

Der Drei-von-Vier-Abgleich behandelt die Währungsumrechnung nicht automatisch – aber die Lösung ist unkompliziert. Fügen Sie Ihrem Extraktionsschema ein fünftes Feld hinzu: Währung. Wenn Rechnungsnummer, Lieferantenname und PO (Bestellung) übereinstimmen, sich das Währungsfeld jedoch unterscheidet, behandelt das System dies als potenzielles Duplikat, das geprüft werden muss. Die meisten internationalen Lieferanten fakturieren in einer einzigen Währung, daher ist dieser Randfall selten – aber wenn er auftritt, macht das Währungsfeld den Unterschied zwischen Erkennen und Übersehen.

Funktioniert das bei wiederkehrenden Abonnementrechnungen?

Dies ist die kniffligste Kategorie. Ein SaaS-Abonnement mit demselben Anbieter, demselben Betrag und derselben PO (Bestellung) jeden Monat löst in jedem Zyklus einen Drei-von-Vier-Abgleich aus – das würde zu Rauschen führen. Die Lösung: Fügen Sie Ihrer Tabelle ein Flag-Feld für wiederkehrende Rechnungen hinzu. Für Lieferanten, die Sie als wiederkehrend markiert haben, unterdrücken Sie das Duplikat-Flag, wenn das Rechnungsdatum in den erwarteten Abrechnungszyklus fällt (z. B. gleicher Monat, gleicher Betrag, gleicher Anbieter = erwartete wiederkehrende Belastung, kein Duplikat). So bleiben wiederkehrende Rechnungen aus Ihrer Prüfwarteschlange, ohne die Erkennung nicht-wiederkehrender Duplikate desselben Lieferanten zu deaktivieren.

Wie verändert die E-Rechnung die Duplikaterkennung?

E-Rechnungsvorschriften – wie Frankreichs Anforderung für 2026, die schrittweise Einführung in Deutschland und der breitere Peppol-Netzwerkrahmen – verringern einige Duplikatrisiken, indem jede Rechnung eine eindeutige, staatlich registrierte Kennung erhält. Sie beseitigen das Problem jedoch nicht vollständig. Ein Lieferant kann weiterhin eine korrigierte E-Rechnung senden, die die ursprüngliche ersetzt. Eine PDF-Kopie kann weiterhin neben der strukturierten XML-Version eintreffen, insbesondere von kleineren Lieferanten, die noch nicht unter die Vorschrift fallen. Und grenzüberschreitende Rechnungen – bei denen ein Land eine Vorschrift hat und das andere nicht – erzeugen genau das Zwei-Kanal-Kollisionsszenario, das wir zuvor beschrieben haben. Der Compliance-Rahmen erfasst die Duplikatsversion der Steuerbehörde. Ihr AP-Team muss weiterhin seine eigene erkennen.