Three-Way-Matching mit KI: Bestellung, Wareneingang und Rechnung ohne manuelles Hinterherlaufen

Das Three-Way-Matching bestätigt, dass eine Lieferantenrechnung mit der Bestellung übereinstimmt, die die Ausgabe autorisiert hat, sowie mit dem Wareneingang, der die Lieferung belegt, bevor überhaupt jemand zahlt. Der saubere Fall ist einfach. Die Arbeit steckt im langen Schwanz: Teillieferungen, eine Bestellung, die über drei Rechnungen abgerechnet wird, unpassende Einheiten, Freitextpositionen ohne Schlüssel. Genau dorthin gehört KI, um Positionen abzugleichen und Exceptions zu routen, während die Toleranz-Policy beim Controller bleibt.

Wo der strikte Abgleich zerbricht

Ein Three-Way-Match im ERP läuft über einen exakten Join: Bestellnummer, Position, Artikelnummer, Menge, Preis. Wenn alle drei Belege dieselben Schlüssel tragen und die Zahlen innerhalb der Toleranz liegen, funktioniert die Straight-Through-Processing und niemand denkt darüber nach. Trotzdem betreibt die Kreditorenbuchhaltung eine Klärungs-Queue, weil ein großer Anteil der realen Rechnungen diesen sauberen Join nie liefert.

Die wiederkehrenden Bruchstellen, die wir sehen:

• Teil- und Überlieferungen. Eine Bestellposition über 1.000 Stück wird als 600 und dann 400 geliefert, was zwei Wareneingänge und oft zwei Rechnungen zu einer Bestellposition erzeugt. Die naive Mengenprüfung pro Position scheitert bei beiden.
• Aufgesplittete und konsolidierte Rechnungen. Ein Lieferant rechnet eine einzelne Bestellung über mehrere Rechnungen ab; ein anderer bündelt zehn Bestellungen in einem Beleg. Der Abgleich erstreckt sich jetzt über eine Many-to-Many-Beziehung, nicht über eine Zeile.
• Konflikte bei den Mengeneinheiten. Die Bestellung ist in Kartons, der Wareneingang in Stück, die Rechnung in Kilogramm. Ohne Umrechnungstabelle wirken die Mengen falsch, selbst wenn die Lieferung korrekt war.
• Freitext- und Dienstleistungspositionen. Dienstleistungen, Frachtkosten und Einmalpositionen tragen Beschreibungen statt Katalog-Artikelnummern, es gibt also nichts, worüber man joinen könnte.
• Preis- und Steuerabweichungen. Kontraktpreis gegen berechneten Preis, Rabatte auf der falschen Ebene angewandt, Steuer auf einer anderen Bemessungsgrundlage berechnet.

Nichts davon ist ein Extraktionsproblem. Der Beleg wurde korrekt gelesen und der Abgleich scheitert dennoch, weil die Beziehung zwischen den drei Belegen keine Eins-zu-eins-Zeilenbeziehung ist.

Die Matching-Logik, die wir bauen

Wir behandeln das als Entity Resolution auf Positionsebene über drei Quellen hinweg, nicht als einzelnes ERP-Flag. Die Pipeline normalisiert zuerst, bewertet dann und entscheidet zuletzt.

Die Normalisierung ist der unglamouröse Teil, der die meiste Arbeit leistet. Einheiten werden über eine lieferanten- und artikelbezogene Umrechnungstabelle auf eine gemeinsame Basis gebracht. Beschreibungen werden bereinigt und, sofern ein Katalog existiert, auf interne Artikel-IDs aufgelöst. Preise werden auf eine vergleichbare Grundlage gestellt, netto von Steuern und bekannten Rabatten, wobei Währung und Datum explizit behandelt werden, damit ein zwei Wochen alter Wechselkurs keine Abweichung fabriziert.

Dann bewerten wir Kandidaten-Verknüpfungen. Für jede Rechnungsposition rufen wir plausible Bestell- und Wareneingangspositionen ab und bringen sie in Rangfolge nach Lieferanten-Artikelnummer, gegenüber der Bestellung verbleibender Menge, normalisiertem Einzelpreis und Textähnlichkeit für die Freitextfälle. Der Mengenabgleich läuft gegen den offenen Saldo der Bestellposition, nicht gegen deren Ursprungsmenge, sodass sich Teillieferungen über mehrere Wareneingänge hinweg korrekt aufaddieren. Genau hier werden aufgesplittete und konsolidierte Rechnungen in eine belastbare Many-to-Many-Zuordnung aufgelöst, statt in eine erzwungene Eins-zu-eins-Vermutung.

Die Entscheidungsebene bleibt bewusst getrennt von der Bewertung. Ein automatisches Match erfolgt nur oberhalb eines Konfidenz-Schwellenwerts, der auf einem gelabelten Eval-Set historischer Matches kalibriert ist, und nur dann, wenn die resultierende Abweichung innerhalb der vom Controller gesetzten Toleranzbandbreite liegt. Toleranz ist Policy. Das Modell schlägt ein Match vor; die Policy entscheidet, ob dieses Match ohne einen Menschen zahlen darf. Diese beiden Dinge auseinanderzuhalten, ist genau das, was es erlaubt, das False-Positive-Budget zu verschärfen, ohne irgendetwas neu zu trainieren.

Zwei Constraints, an denen wir festhalten:

• Point-in-Time-Korrektheit. Der Abgleich nutzt die Bestellversion, den Preis und den offenen Saldo so, wie sie zum Eingangszeitpunkt der Rechnung standen, nicht den heutigen Stand. Nachträgliche Preisänderungen und spätere Wareneingänge dürfen eine bereits getroffene Entscheidung nicht umschreiben, sonst verliert der Audit-Trail seine Bedeutung.
• Vollständige Lineage. Jede automatisch gematchte Position hält fest, welche Bestellposition, welcher Wareneingang, welcher Umrechnungsfaktor und welcher Schwellenwert die Entscheidung erzeugt haben, sodass sich eine gematchte Rechnung Monate später zum Quartalsende rekonstruieren lässt, ohne sie von Hand neu herzuleiten.

Exception-Routing, das tatsächlich abgearbeitet wird

Das Matching ist die halbe Miete. Die andere Hälfte ist, was mit all dem passiert, was das Modell nicht automatisch klären würde, denn in dieser Queue verbringt die Kreditorenbuchhaltung ihre eigentliche Zeit.

Wir routen nach Exception-Typ, statt alles in einen generischen Hold-Topf zu werfen, weil sich Ansprechpartner und Lösung unterscheiden. Eine Mindermenge geht an den Wareneingangsstandort, der den Wareneingang gebucht hat. Eine Preisabweichung jenseits der Toleranz geht an den Einkäufer, dem der Kontrakt gehört. Ein Steuer- oder Kontierungsfehler geht an die Kreditorenbuchhaltung. Eine Rechnung ohne Bestellbezug geht an denjenigen, der den autorisierenden Beleg erstellen oder bestätigen kann. Jedes Routing trägt die bestbewerteten Kandidaten-Matches des Modells und den konkreten Grund, aus dem die Position hängengeblieben ist, sodass der Prüfer von einer priorisierten Shortlist ausgeht statt von einer leeren Suche.

Die reine Match-Rate ist die falsche Kennzahl fürs Rampenlicht. Die beobachtenswerte Zahl ist die Exception-Rate, gewichtet danach, wie lange jeder Typ bis zur Klärung braucht, über die Zeit verfolgt, damit Drift sichtbar wird. Wenn ein Lieferant sein Rechnungslayout ändert oder anfängt, Bestellungen zu konsolidieren, verschiebt sich der Exception-Mix, bevor sich die Summen ändern, und diese Verschiebung ist das Frühsignal dafür, dass eine Umrechnungstabelle oder ein Schwellenwert Aufmerksamkeit braucht.

Das ist das Ziel: Der saubere Schwanz wird unangetastet abgearbeitet, mehrdeutige Fälle treffen vorsortiert und mit angehängten Kandidaten ein, und die einzigen Rechnungen, die ein Mensch ohne Vorlauf öffnet, sind die, bei denen die Belege einander wirklich widersprechen. Diese letzte Gruppe erreicht nie null, und das soll sie auch nicht. Es sind die Fälle, in denen eine Kontrolle ihre Aufgabe erfüllt.