5 Lücken in der Erkennung doppelter Rechnungen
Die AP-Teams Tausende Kosten
Die Benchmark-Studie von IOFM zeigt, dass Unternehmen mit schwachen Kontrollen etwa 1,5 % ihres gesamten Zahlungsabflusses durch Doppelzahlungen verlieren. Für ein Unternehmen mit einem jährlichen AP-Volumen von 5 Millionen Dollar sind das 75.000 Dollar – nicht einmalig, sondern jedes Jahr. Und doch, wenn man einen AP-Sachbearbeiter fragt, wie er Duplikate erkennt, lautet die Antwort fast immer: „Ich führe einen SVERWEIS auf der Rechnungsnummernspalte aus.“ Die Lücke zwischen diesen beiden Sätzen ist das Thema dieses Artikels.
Wichtigste Erkenntnisse
- Das Duplikat, das Ihr AP-Team jedes Jahr Tausende kostet, sieht nicht wie eine Kopie aus – es kommt mit einer anderen Rechnungsnummer über einen anderen Kanal in einem anderen Monat.
- Ein SVERWEIS auf die Rechnungsnummernspalte übersieht vier von fünf echten Duplikaten, da er nur ein Feld nach dem anderen mit einem Monat Daten vergleicht.
- Extrahieren Sie mit ImageToTable.ai vier Felder aus jeder Rechnung und markieren Sie jede Zeile, die drei von vier Kriterien erfüllt – die manuelle Prüfung reduziert sich von 500 Rechnungen auf 15 markierte Kandidaten.
Die 4 Wege, wie doppelte Rechnungen in Ihre Warteschlange gelangen – und drei davon übersehen Sie
Überspringen wir die übliche Kategorie „Eingabefehler", mit der jeder Artikel beginnt. Sie wissen bereits, dass Tippfehler Probleme verursachen. Die Duplikate, die wirklich Geld kosten, sind die, die an der Oberfläche anders genug aussehen, um alle Ihre Prüfungen zu umgehen – aber dieselbe Verbindlichkeit darstellen.
1. Die „Wir haben bereits bezahlt"-Erinnerung
Ein Lieferant sendet eine Rechnung. Ihre Kreditorenbuchhaltung bearbeitet sie, plant die Zahlung – alles in Ordnung. Drei Wochen später sendet der Lieferant dieselbe Rechnung erneut – diesmal mit dem Vermerk „Zweite Mahnung" oder „Erinnerung". Der Sachbearbeiter, der sie öffnet, hat die Originalrechnung nicht bearbeitet. Er erkennt sie nicht wieder. Die Rechnungsnummer ist gleich, 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 keine Seltenheit. Es ist die häufigste Ursache für Duplikate in Unternehmen, die über 200 Rechnungen pro Monat verarbeiten – und es passiert, weil das Debitorensystem des Lieferanten und Ihr Kreditorensystem nicht miteinander kommunizieren. 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 Zustellwege. Der Lieferant sendet ein PDF per E-Mail an [email protected] und übermittelt gleichzeitig dieselbe Rechnung per EDI an den elektronischen Eingang Ihres ERP-Systems. Der E-Mail-Anhang landet in der manuellen Bearbeitungswarteschlange. Die EDI-Übermittlung erstellt automatisch einen Datensatz im System. Zwei verschiedene Sachbearbeiter, zwei verschiedene Bearbeitungswege, eine zugrundeliegende Verbindlichkeit – und keine Querverbindung zwischen den beiden Warteschlangen, da sie in unterschiedlichen Systemen leben.
Dieses Problem wird mit der Modernisierung von Unternehmen schlimmer, nicht besser. Je mehr Kanäle Sie für die Rechnungseinreichung von Lieferanten öffnen – E-Mail, Portal, EDI, Papierpost – desto mehr Eintrittspunkte schaffen Sie dafür, dass dieselbe Rechnung zweimal landet. Besonders anfällig ist eine Hybridumgebung, in der PDF und strukturierte Rechnungsformate nebeneinander existieren: Der strukturierte Kanal (EDI/XML) läuft ohne menschliche Prüfung durch, während die PDF-Kopie im Posteingang eines Sachbearbeiters darauf wartet, abgetippt zu werden.
3. Die korrigierte Doppelerfassung
Ein Lieferant stellt einen Fehler auf Rechnung Nr. 4521 fest und stellt eine korrigierte Version aus – Rechnung Nr. 4521-C, gleicher Betrag, korrigierte Positionen. Der Kreditorenbuchhalter erhält beide. Das Original kam vor zwei Wochen und wurde bereits erfasst. Die korrigierte Version trifft jetzt ein. Der Buchhalter erkennt das Suffix „-C", versteht es als Korrektur und erfasst auch diese – aber niemand storniert die ursprüngliche Buchung. Zwei Rechnungen, zwei Zahlungen, eine Verpflichtung.
Was passieren sollte: Die korrigierte Rechnung löst eine Stornierung des Originals aus, bevor die neue erfasst wird. Was tatsächlich passiert: In den meisten mittelständischen Kreditoren-Workflows gibt es keine automatische Verknüpfung zwischen Original und Korrektur. Das Suffix „-C" ist eine menschliche Konvention, die ERP-Systeme nicht interpretieren. Wenn der Buchhalter vergisst, das Original manuell zu stornieren – oder ein anderer Buchhalter das Original bearbeitet hat – geht die Doppelzahlung durch.
4. Die monatsübergreifende Wiederholung
Eine Rechnung für eine wiederkehrende Leistung kommt im März für die Februar-Gebühren. Dieselbe Rechnung – gleicher Bestellbezug, gleicher Betrag – trifft im April erneut ein, weil der Lieferant sein Abrechnungssystem umgestellt und alle offenen Rechnungen mit neuen Nummern neu ausgestellt hat. Ihre März-Buchung liegt im März-Konto. Ihre April-Buchung ist eine neue Transaktion. Ein SVERWEIS auf die Rechnungsnummer findet keine Übereinstimmung, weil die Nummern unterschiedlich sind. Ein SVERWEIS auf den Betrag findet eine exakte Übereinstimmung – aber das tut auch jede andere monatliche Rechnung dieses Lieferanten.
Monatsübergreifende Duplikate sind manuell am schwersten zu erkennen, weil sie den natürlichen Rhythmus der Kreditorenarbeit ausnutzen: Jeder Monatsdurchlauf wird isoliert bearbeitet. Niemand vergleicht die Rechnungen dieses Monats mit dem bezahlten Konto des Vormonats, es sei denn, etwas löst diese Prüfung gezielt aus. Und der Auslöser – eine Doppelzahlung, die das Konto belastet – kommt oft 30 bis 60 Tage nach der zweiten Buchung.
Ein Muster in allen obigen Szenarien: Das Duplikat sieht nicht identisch aus. Unterschiedliche Rechnungsnummern, unterschiedliche Daten, unterschiedliche Kanäle, unterschiedliche Monate. Ihre Dublettenprüfung sucht nach Klonen. Die wahren Gefahren sind Fast-Klone – und die laufen einfach durch.
Warum Ihre Dublettenprüfung in der Tabelle ständig fehlschlägt – 5 konkrete Fehlermodi
Wenn Sie eine manuelle Dublettenprüfung eingerichtet haben – und die meisten AP-Teams haben das –, sieht sie wahrscheinlich so aus: eine gemeinsame Excel-Datei oder Google-Tabelle mit allen erfassten Rechnungen und eine regelmäßige VLOOKUP- oder bedingte Formatierungsregel, die Zeilen hervorhebt, in denen die Rechnungsnummer mehrfach vorkommt. Der Instinkt ist richtig. Trotzdem werden die meisten Dubletten übersehen. Hier genau, wo es scheitert.
Fehler 1: Inkonsistenz im Rechnungsnummernformat
Lieferant A verwendet „INV-004521". Lieferant B verwendet „4521". Lieferant C verwendet „INV4521-2026-03". Ein VLOOKUP, das 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 dem kopiert, was ihm zuerst auffällt, gelangt dieselbe Rechnung unter drei verschiedenen Kennungen in Ihre Tabelle, und Ihre Dublettenprüfung sieht drei eindeutige Datensätze.
Fehler 2: Abweichungen beim Lieferantennamen
„Acme Industrial Supply Inc." versus „Acme Industrial Supply" versus „Acme Ind Supply". Selbst innerhalb der Rechnungen eines einzigen Lieferanten kann der Firmenname im Kopf von der Zahlungsempfängerangabe in den Zahlungsanweisungen abweichen. Ihr VLOOKUP auf den Lieferantennamen liefert keine Übereinstimmung – aber der zugrunde liegende Lieferant ist identisch. Die APQC-Benchmarks nennen eine schlechte Pflege des Lieferantenstammdatensatzes als Hauptursache für Doppelzahlungen: Wenn derselbe Lieferant unter mehreren Datensätzen existiert, sieht eine auf eine Lieferanten-ID beschränkte Dublettenprüfung den anderen Eintrag nie.
Fehler 3: Beträge, die übereinstimmen sollten – es aber nicht ganz tun
Rechnung Nr. 4521 weist einen Gesamtbetrag von 1.247,50 € aus. Die korrigierte Version – Rechnung Nr. 4521-C mit einem korrigierten Posten – weist 1.247,53 € aus. Eine Differenz von drei Cent. Ihr VLOOKUP auf die Spalte „Betrag" liefert keine Übereinstimmung. Die Rechnungen repräsentieren dieselbe Verbindlichkeit bis auf 0,002 %, aber Ihre Formel behandelt sie als völlig unabhängig. Dies passiert ständig bei Steueranpassungen, Rundungsdifferenzen und Teilgutschriften, die den Gesamtbetrag um Centbeträge verschieben.
Fehler 4: PO-Referenz-Konflikt
Sie prüfen auf Duplikate, indem Sie die PO-Nummer abgleichen – das funktioniert, bis es nicht mehr funktioniert. Ein Lieferant sendet zwei Rechnungen zur selben Bestellung, weil die Bestellung zwei separate Lieferungen abdeckte. Beide sind berechtigt. Das Duplikat ist die dritte Rechnung zu dieser Bestellung – eine erneute Ausstellung der ersten – und sie hat dieselbe PO-Referenz. Ihre PO-basierte Prüfung markiert alle drei als potenzielle Duplikate und erzwingt eine manuelle Prüfung jeder Zeile, anstatt das einzelne tatsächliche Duplikat zu isolieren. Der PO-Abgleich erkennt gleichzeitig zu viel und zu wenig.
Fehler 5: Die zeitliche Blindstelle
Ihre Duplikatprüfung läuft auf den Daten des aktuellen Monats. Sie berücksichtigt weder das bezahlte Hauptbuch des Vormonats, noch den abgeschlossenen Batch des letzten Quartals oder die archivierte Datei des Vorjahres. 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, zu dem das Geld bereits seit über 60 Tagen weg ist. Die Rückholung einer Doppelzahlung nach 60 Tagen ist exponentiell schwieriger: Der Lieferant hat sie möglicherweise bereits in seinem Hauptbuch verbucht, das ACH-Stornierungsfenster ist geschlossen, und das Gespräch wandelt sich von „Bitte erstatten Sie dies" zu „Lassen Sie uns eine Gutschrift aushandeln."
Diese fünf Fehler haben eine gemeinsame Ursache: Ein Tabellenkalkulations-Duplikatcheck vergleicht jeweils eine Spalte mit einem einzelnen Datenbatch. Echte Duplikate erfordern einen Mehrfeldvergleich (Rechnungsnummer, Lieferant, Betrag, Bestellung) über mehrere Zeiträume hinweg. Eine einzelne VLOOKUP-Spalte kann das nicht leisten – und keine noch so komplexe Formelverschachtelung wird die Architektur reparieren.
Eine 4-Felder-Erkennungsebene, die mit Ihren vorhandenen Mitteln funktioniert
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 Bestellnummer. Nicht ein exakt abgeglichenes Feld. Vier gemeinsam verglichene Felder, bei denen eine Übereinstimmung in drei von vier Fällen eine Prüfmarkierung auslöst.
So lautet Ihre Erkennungslogik:
- Extrahieren Sie diese vier Felder aus jeder eingehenden Rechnung – ob PDF, Scan, Foto einer Papierrechnung oder E-Mail-Anhang.
- Hängen Sie die vier Felder jeder Rechnung als neue Zeile in eine Master-Tabelle an – Google Sheets oder Excel, je nachdem, was Ihr Team bereits verwendet.
- Markieren Sie jede Zeile, bei der drei oder mehr der vier Felder mit einer vorhandenen Zeile übereinstimmen. Verwenden Sie bedingte Formatierung: heben Sie die übereinstimmenden Zeilen gelb hervor und markieren Sie sie zur manuellen Prüfung.
- Prüfen Sie nur markierte Zeilen. Alles andere – die über 95 % der Rechnungen, die keine Markierung auslösen – fließt direkt zur Genehmigung, ohne Duplikatprüfung.
Warum die Drei-von-Vier-Übereinstimmung funktioniert, wenn die Einzelfeld-Übereinstimmung versagt:
- Rechnungsnummernformat variiert → aber Lieferantenname und Betrag stimmen überein → markiert.
- Lieferantenname ist inkonsistent → aber Rechnungsnummer und Betrag stimmen überein → markiert.
- Betrag weicht um drei Cent ab (korrigierte Rechnung) → aber Rechnungsnummer (teilweise), Lieferantenname und Bestellnummer stimmen überein → markiert.
- Monatsübergreifende Wiederholung mit anderer Rechnungsnummer → Lieferantenname, Betrag und Bestellnummer stimmen überein → markiert – vorausgesetzt, Ihre Tabelle enthält die Zeilen des Vormonats und des vorherigen Quartals.
Die Schwelle von drei Übereinstimmungen ist bewusst gewählt. Zwei Treffer (gleicher Lieferant, gleicher Betrag) markieren jede wiederkehrende monatliche Rechnung als Fehlalarm. Vier Treffer erfassen nur exakte Klone – die am einfachsten zu erkennen und am seltensten sind. Drei-von-vier ist der Goldlöckchen-Bereich: empfindlich genug für Fast-Klone, spezifisch genug, um den Prüfer nicht mit Rauschen zu überfluten.
Der Engpass ist natürlich Schritt 1: diese vier Felder zuverlässig aus Dutzenden oder Hunderten von Rechnungs-PDFs pro Woche zu extrahieren. Manuelles Eintippen ist die Ursache für die Dateneingabefehler.
Hier ändert KI-Extraktion die Spielregeln. Statt jede PDF zu öffnen und vier Felder einzutippen, laden Sie den Rechnungsstapel hoch und geben die vier gewünschten Spaltennamen an – Rechnungsnummer, Lieferantenname, Gesamtbetrag, Bestellnummer. Die KI liest jedes Dokument, findet die entsprechenden Werte unabhängig von ihrer Position auf der Seite und gibt eine strukturierte Tabelle mit einer Zeile pro Rechnung aus. Sie kopieren diese Tabelle in Ihre Haupttabelle, und die bedingte Formatierung erledigt den Rest.
Sie ersetzen nicht Ihren Workflow. Sie fügen einen Extraktionsschritt vor dem Schritt ein, den Sie bereits tun. Ihr ERP, Ihr Genehmigungs-Workflow, Ihr Zahlungsplan – alles unverändert. Was sich ändert: Der AP-Sachbearbeiter, der früher 10 Minuten pro Rechnung für die Eingabe und weitere 5 Minuten für SVERWEISE aufgewendet hat, braucht jetzt 10 Sekunden pro Rechnung für die Extraktion und 30 Sekunden für die Prüfung nur der markierten Zeilen. Der Rest ist automatisiert.
Probieren Sie es selbst aus – laden Sie eine Beispielrechnung hoch und sehen Sie, wie die vier Felder in Sekunden extrahiert werden:
Dateien werden sicher verarbeitet und nicht gespeichert.
Dieser Ansatz funktioniert, weil er nicht schlauer sein will als der AP-Sachbearbeiter. Er automatisiert den repetitiven Teil – Dokumente lesen und Felder eintippen – und belässt den Beurteilungsteil – „Ist das wirklich 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 Rechnungsgenehmigungs-Automatisierung besprochen haben, ersetzen die effektivsten Automatisierungsstrategien nicht den Workflow. Sie ersetzen den Datenaufbereitungsschritt, der ihn speist.
Wann der Algorithmus Ihnen den Vortritt lassen sollte
Der Drei-von-Vier-Abgleich markiert verdächtige 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 automatische Erkennung zwar ein Muster korrekt identifiziert, aber menschliches Urteilsvermögen zur Interpretation erforderlich ist.
Die Drei-Cent-Differenz
Rechnung #4521: 1.247,50 €. Rechnung #4521-C: 1.247,53 €. Drei Felder stimmen überein, der Betrag weicht um 0,03 € ab. Markiert.
Es handelt sich hierbei mit hoher Wahrscheinlichkeit um ein Duplikat – aber „hohe Wahrscheinlichkeit" reicht nicht aus, um eine Zahlung rückgängig zu machen. Die drei Cent könnten eine steuerliche Rundungsanpassung sein, die die korrigierte Version zu einem legitimen Ersatz macht. Es könnte sich um eine Währungsumrechnungsschwankung handeln, wenn die Originalrechnung in Euro ausgestellt und die korrigierte Version zu einem leicht abweichenden Kurs umgerechnet wurde. Die Aufgabe des Algorithmus ist es, das Paar aufzudecken. Ihre Aufgabe ist es zu prüfen, ob der Lieferant die ursprüngliche Rechnung ersetzen wollte, und wenn ja, den ursprünglichen Eintrag vor der Verarbeitung der Korrektur zu stornieren. 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 Bestellung
Ein Baustofflieferant liefert Material in drei Teillieferungen zur Bestellung #7842. Jede Lieferung erzeugt eine separate Rechnung: #INV-112, #INV-113, #INV-114. Gleicher Lieferant, gleiche Bestellung, unterschiedliche Rechnungsnummern, unterschiedliche Beträge. Der Drei-von-Vier-Abgleich markiert alle, da Lieferant und Bestellung bei jedem Paar übereinstimmen. Aber alle drei sind legitim.
Dies ist das häufigste Fehlalarm-Szenario, und genau deshalb verwendet der Vier-Feld-Ansatz eine bedingte Formatierung plus manuelle Prüfung anstelle einer automatischen Blockierung. Der Algorithmus hebt das Muster hervor. Sie erkennen es als legitime Teillieferung – und löschen die Markierungen in zwei Sekunden. Hätten Sie eine Regel konfiguriert, die Bestellungen mit mehreren Rechnungen automatisch blockiert, hätten Sie drei legitime Zahlungen aufgehalten und drei Lieferanten anrufen müssen, um den Grund zu erklären.
Der Lieferant, der das Rechnungsnummernformat geändert hat
Ein Lieferant migriert sein ERP. Das alte Rechnungsformat war „ACME-YYMM-####". Das neue Format ist eine fortlaufende achtstellige Zahl: „00004521". Die erste Rechnung im neuen System trifft für eine wiederkehrende monatliche Gebühr ein. Gleicher Lieferant, gleicher Betrag, gleiche Bestellung – aber das Rechnungsnummernformat ist nicht wiederzuerkennen. Der Drei-von-Vier-Abgleich erwischt sie, weil die anderen drei Felder übereinstimmen. Ohne diese Querprüfung würde Ihre Tabellenkalkulation eine neue Rechnungsnummer sehen und sie durchlassen.
Dieses Szenario ist besonders gefährlich im Zusammenhang mit den E-Rechnungsverpflichtungen, 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 aufgrund von Vorschriften (z. B. Frankreichs Anforderung einer eindeutigen fortlaufenden Nummer ohne Lücken). Eine Kreditorenbuchhaltung, die sich ausschließlich auf den Rechnungsnummernabgleich verlässt, wird diese formatgewechselten Rechnungen als neue Datensätze behandeln, selbst wenn sie dieselbe wiederkehrende Verpflichtung wie die PDF-Version vom Vormonat darstellen.
Währungs- und Wechselkursnuancen
Ein internationaler Lieferant stellt in EUR in Rechnung. Ihr System erfasst den USD-Gegenwert zum Wechselkurs des Verarbeitungsdatums. Dieselbe Rechnung trifft erneut ein – vielleicht über einen anderen Kanal – und wird an einem anderen Datum mit einem leicht abweichenden Wechselkurs verarbeitet. Die USD-Beträge weichen um ein paar Dollar ab. Lieferantenname stimmt überein. Bestellnummer stimmt überein. Rechnungsnummer stimmt überein. Der Betrag ist ähnlich, aber nicht identisch.
Der Algorithmus sollte dies melden – 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 zu 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 unterschiedliche Rechnungen handelt.
Das Prinzip: Die automatisierte Erkennung ist ein Triage-Werkzeug, keine Entscheidungsmaschine. Ihre Aufgabe ist es, 500 Rechnungen auf 15 Prüfkandidaten zu reduzieren. Die endgültige Entscheidung über jeden Kandidaten erfordert Kontext – Lieferantenhistorie, Vertragsbedingungen, Lieferpläne – der in Ihrem Kopf und in Ihrer E-Mail lebt, nicht in den Rechnungsfeldern.
Deshalb ist es auch praktischer, Rechnungsfelder in eine Tabelle zu extrahieren, anstatt die Erkennungslogik in eine Black-Box-AP-Plattform einzubetten. Sie sehen die Daten, Sie sehen, welche drei Felder übereinstimmten, Sie sehen die ursprüngliche Zeile direkt über der markierten Zeile – und Sie können in Sekunden eine Entscheidung treffen, basierend auf allem, was Sie über diesen Lieferanten wissen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Dublettenprüfung 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 Dublettenprüfung fragt, ob Sie diese Rechnung bereits 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 Bestellung und Wareneingang nicht geändert haben. Der 3-Wege-Abgleich bestätigt das Was. Die Dublettenprüfung bestätigt das Wie oft.
Kann mein ERP das automatisch?
Die meisten Mittelstands-ERPs – QuickBooks, Xero, NetSuite – haben eine einfache Dublettenprüfung, die nur nach exakten Rechnungsnummern innerhalb desselben Lieferantendatensatzes sucht. QuickBooks markiert eine Rechnung, wenn dieselbe Kombination aus Lieferant und Rechnungsnummer bereits existiert. Das erfasst exakte Dubletten – dieselbe Rechnung zweimal mit derselben Nummer erfasst – und übersieht alles andere, was wir besprochen haben: Formatvarianten, kanalübergreifende Einreichungen, Original-plus-Korrektur-Paare und monatsübergreifende Wiederholungen mit anderen Nummern. Wenn Ihr Dublettenproblem auf exakte Nummernübereinstimmungen beschränkt ist, deckt Ihr ERP das bereits ab. Wenn Sie diesen Artikel lesen, ist das wahrscheinlich nicht der Fall.
Ab wie vielen Rechnungen lohnt sich das für ein Team?
Die Rechnung ist einfach. Bei 200 Rechnungen pro Monat und einer geschätzten Dublettenrate von 0,5 % (konservativ für Teams ohne automatische Kontrollen) ergibt das eine Dublette pro Monat. Liegt der durchschnittliche Rechnungswert in Ihrem Unternehmen über 800 €, amortisiert sich eine Dublette pro Monat bereits durch die eingesparte Extraktionszeit – noch bevor die Personalkosten für manuelle VLOOKUP-Prüfungen berücksichtigt sind. 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 „Extrahieren und Markieren“ mit steigendem Volumen zunehmend wertvoller.
Was ist, wenn ein Lieferant dieselbe Rechnung in zwei verschiedenen Währungen sendet?
Der Drei-von-Vier-Abgleich beherrscht keine automatische Währungsumrechnung – aber die Lösung ist einfach. Fügen Sie ein fünftes Feld zu Ihrer Extraktion hinzu: Währung. Stimmen Rechnungsnummer, Lieferantenname und Bestellnummer überein, unterscheidet sich aber das Währungsfeld, behandelt das System dies als potenzielle Dublette, die geprüft werden muss. Die meisten internationalen Lieferanten fakturieren in einer einzigen Währung, daher ist dieser Grenzfall selten – aber wenn er auftritt, macht das Währungsfeld den Unterschied zwischen Erkennen und Übersehen.
Funktioniert das auch bei wiederkehrenden Abonnementrechnungen?
Dies ist die kniffligste Kategorie. Ein SaaS-Abonnement mit demselben Anbieter, demselben Betrag und derselben Bestellnummer jeden Monat löst in jedem Zyklus einen Drei-von-Vier-Treffer aus – das würde Rauschen erzeugen. 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 außerhalb Ihres Prüf-Workflows, ohne dass die Erkennung nicht wiederkehrender Duplikate desselben Lieferanten deaktiviert wird.
Wie verändert E-Rechnung die Duplikaterkennung?
E-Rechnungsvorschriften – wie Frankreichs Anforderung ab 2026, Deutschlands gestaffelte Einführung und das breitere Peppol-Netzwerk-Framework – verringern einige Duplikationsrisiken, indem sie jeder Rechnung eine eindeutige, behördlich registrierte Kennung zuweisen. Aber sie beseitigen das Problem nicht. Ein Lieferant kann dennoch eine korrigierte E-Rechnung senden, die die ursprüngliche ersetzt. Eine PDF-Kopie kann weiterhin parallel zur strukturierten XML-Version eingehen, insbesondere von kleineren Lieferanten, die noch nicht unter die Vorschrift fallen. Und grenzüberschreitende Rechnungen – wenn ein Land eine Vorschrift hat und das andere nicht – erzeugen genau das Zwei-Kanal-Kollisionsszenario, das wir zuvor beschrieben haben. Das Compliance-Framework erfasst die Duplikatsversion der Steuerbehörde. Ihr AP-Team muss weiterhin seine eigenen Duplikate erkennen.