5 Lücken in der Duplikaterkennung von Rechnungen
Die AP-Teams Tausende Kosten
Die Benchmark-Studie von IOFM zeigt, dass Unternehmen mit schwachen Kontrollen rund 1,5 % ihres gesamten Zahlungsabflusses durch Doppelzahlungen verlieren. Bei einem Unternehmen mit einem jährlichen AP-Volumen von 5 Millionen Dollar sind das 75.000 Dollar – nicht einmalig, sondern jedes Jahr. Fragt man einen AP-Sachbearbeiter, 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 der Kern dieses Artikels.
Wichtige 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 verdächtige 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 jede Ihrer Prüfungen zu umgehen – aber in Wirklichkeit dieselbe Verbindlichkeit darstellen.
1. Der „Haben wir schon bezahlt"-Erneute Versand
Ein Lieferant sendet eine Rechnung. Ihre Kreditorenbuchhaltung bearbeitet 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 Sachbearbeiter, der sie öffnet, hat die ursprüngliche nicht bearbeitet. Er erkennt sie nicht wieder. 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 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 Zustellkanäle. 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 Querprüfung zwischen den beiden Warteschlangen, da sie in verschiedenen 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 Einstiegspunkte 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) geht ohne menschliche Prüfung direkt 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 gibt 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 sieht das „-C“-Suffix, erkennt die 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 „-C“-Suffix 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 – wird die Dublette durchgewunken.
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-Hauptbuch. 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 Dubletten 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 bereits bezahlten Vormonats-Hauptbuch, es sei denn, etwas löst diese Prüfung gezielt aus. Und der Auslöser – eine doppelte Zahlung, die das Konto belastet – kommt oft 30 bis 60 Tage nach der zweiten Buchung.
Ein Muster in allen obigen Szenarien: Die Dublette sieht nicht identisch aus. Unterschiedliche Rechnungsnummern, unterschiedliche Daten, unterschiedliche Kanäle, unterschiedliche Monate. Ihre Dublettenprüfung sucht nach Klonen. Die wirklichen Bedrohungen sind Fast-Klone – und die laufen einfach durch.
Warum Ihre Dublettenprüfung in der Tabelle immer wieder fehlschlägt – 5 konkrete Fehlerquellen
Wenn Sie eine manuelle Dublettenprüfung eingerichtet haben – und die meisten AP-Teams tun 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 Ansatz ist richtig. Aber er übersieht die meisten Dubletten. 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 er zuerst sieht, gelangt dieselbe Rechnung unter drei verschiedenen Kennungen in Ihre Tabelle – und Ihre Dublettenprüfung sieht drei eindeutige Datensätze.
Fehler 2: Abweichungen bei 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 legitim. Das Duplikat ist die dritte Rechnung zu dieser Bestellung – eine erneute Ausstellung der ersten – und sie trägt dieselbe PO-Referenz. Ihre PO-basierte Prüfung markiert alle drei als potenzielle Duplikate und erzwingt eine manuelle Prüfung jeder Zeile, anstatt das eine tatsächliche Duplikat zu isolieren. Der PO-Abgleich erkennt gleichzeitig zu viel und zu wenig.
Fehler 5: Die zeitliche Blindstelle
Ihre Duplikatsprü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 teilen eine gemeinsame Ursache: Eine Tabellenkalkulations-Duplikatsprüfung 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 tiefe 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 dies zu beheben. Sie benötigen 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, in 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 ohne Duplikatsprüfung direkt zur Freigabe.
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 Grenze von drei Übereinstimmungen ist bewusst gewählt. Zwei Treffer (gleicher Lieferant, gleicher Betrag) markieren jede wiederkehrende monatliche Rechnung als falsch positiv. Vier Treffer (exakte Übereinstimmung in allen Feldern) erfassen nur exakte Klone – die am einfachsten zu erkennenden und seltensten Duplikate. Drei-von-vier ist die Goldlöckchen-Zone: empfindlich genug für Fast-Klone, spezifisch genug, um den Prüfer nicht im 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. Manuelles Eintippen verursacht überhaupt erst 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ürs Eintippen und weitere 5 Minuten für SVERWEISE brauchte, benötigt 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 Automatisierung der Rechnungsgenehmigung besprochen haben, ersetzen die effektivsten Automatisierungsstrategien nicht den Workflow. Sie ersetzen den Datenaufbereitungsschritt, der ihn speist.
Wann der Algorithmus Ihnen den Vortritt lassen sollte
Drei-von-vier-Abgleich markiert verdächtige Zeilen. Was er nicht kann – und nicht versuchen sollte – ist die endgültige Entscheidung zu treffen. Hier sind die Grenzfälle, in denen die automatisierte Erkennung zwar ein Muster 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.
Dies ist mit hoher Wahrscheinlichkeit ein Duplikat – aber „hohe Wahrscheinlichkeit" reicht nicht aus, um eine Zahlung rückgängig zu machen. 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 das Original in EUR angegeben und die korrigierte Version zu einem leicht abweichenden Kurs zurückgerechnet wurde. Die Aufgabe des Algorithmus ist es, das Paar aufzudecken. Ihre Aufgabe ist es zu prüfen, ob der Lieferant beabsichtigt hat, das Original zu ersetzen, und wenn ja, den ursprünglichen Eintrag vor der Verarbeitung der Korrektur zu stornieren. Wenn Sie die Absicht nicht ermitteln 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 Sendungen zur Bestellung #7842. Jede Sendung 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 der Grund, warum der Vier-Feld-Ansatz bedingte Formatierung plus manuelle Prüfung anstelle einer automatischen Sperrung verwendet. 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 automatisch jede Bestellung mit mehreren Rechnungen 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 änderte
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 erfasst es, weil die anderen drei Felder übereinstimmen. Ohne diese Querprüfung würde Ihre Tabelle 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 unterscheiden sich um ein paar Dollar. 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 Tabellenkalkulation 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 Sekundenschnelle 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 durch die eingesparte Extraktionszeit mehrfach – 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 für wiederkehrende 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 Duplikats-Flag, wenn das Rechnungsdatum in den erwarteten Abrechnungszyklus fällt (z. B. gleicher Monat, gleicher Betrag, gleicher Lieferant = erwartete wiederkehrende Belastung, kein Duplikat). So bleiben wiederkehrende Rechnungen außerhalb Ihres Prüf-Workflows, ohne die Erkennung nicht wiederkehrender Duplikate desselben Lieferanten zu deaktivieren.
Wie verändert die E-Rechnung die Duplikatserkennung?
E-Rechnungsvorschriften – wie Frankreichs Anforderung ab 2026, Deutschlands gestaffelte Einführung und das breitere Peppol-Netzwerk-Framework – verringern einige Duplikatsrisiken, indem sie jeder Rechnung eine eindeutige, staatlich 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 neben der strukturierten XML-Version eingehen, insbesondere von kleineren Lieferanten, die noch nicht unter die Pflicht fallen. Und grenzüberschreitende Rechnungen – wenn ein Land eine Pflicht hat und das andere nicht – erzeugen genau das Zwei-Kanal-Kollisionsszenario, das wir zuvor beschrieben haben. Das Compliance-Framework erfasst die Version der Duplizierung der Steuerbehörde. Ihr AP-Team muss weiterhin seine eigene erkennen.