Doppelte und abweichende Stammdatensätze werden bereinigt, indem man Deduplizierung als Entity Resolution und nicht als String-Matching begreift: Die Datensätze werden per Blocking in Kandidatengruppen gruppiert, jedes Paar wird über Name, Adresse, Steuer-ID und Bankverbindung gemeinsam bewertet, und anschließend legen Survivorship-Regeln fest, welcher Datensatz erhalten bleibt. Das Modell schlägt Zusammenführungen vor. Ein Prüfer genehmigt die Fälle oberhalb Ihres Budgets für False Positives, der Rest läuft im Straight-Through-Verfahren durch.
Schlechte Lieferantenstammdaten melden sich nicht von selbst. Sie liegen unauffällig herum, bis derselbe Lieferant, zweimal unter leicht abweichenden Namen angelegt, zwei Zahlungen für eine einzige Rechnung erhält. Oder bis der Three-Way-Match scheitert, weil die Bestellung auf “Acme Ltd” zeigt und die Rechnung von “Acme Limited” kommt, und ein Sachbearbeiter das von Hand umgeht. Die unsaubere Tabelle selbst ist billig. Die Doppelzahlung ist es nicht, und ebenso wenig die Stunden, die jemand damit verliert, eine Summe abzustimmen, die drei Systeme auf drei verschiedene Arten melden.
Warum die Dubletten überhaupt entstehen
Stammdaten verschlechtern sich durch ganz normalen Gebrauch. Ein Lieferant wird vom Einkauf angelegt, dann noch einmal von der Kreditorenbuchhaltung, weil der erste Datensatz nicht gefunden wird. Ein Unternehmen ändert nach einer Übernahme seinen Handelsnamen, und beide Versionen leben weiter. Jemand fügt eine Adresse mit einem angehängten Leerzeichen ein. Nichts davon ist dramatisch, und genau das ist das Problem: Jeder einzelne Fall sieht auf dem eigenen Bildschirm in Ordnung aus.
Die Muster, die einen Namen verdienen, weil sie steuern, wie man abgleicht:
- Fast identische Namen: “Acme Ltd”, “Acme Limited”, “ACME LTD”. Dieselbe Entität, drei Zeichenketten.
- Eigenständige Entitäten, die identisch aussehen: zwei Tochtergesellschaften unter einer Konzernzentrale, mit unterschiedlichen Steuer-IDs und unterschiedlichen Bankkonten. Diese zusammenzuführen ist schlimmer, als sie getrennt zu lassen.
- Vertauschte oder unvollständige Kennungen: eine USt-IdNr. mit vertauschter Ziffer, eine IBAN, die in falscher Länge erfasst wurde.
- Veraltet versus aktuell: eine alte eingetragene Adresse neben der neuen, beide zu unterschiedlichen Zeitpunkten technisch korrekt.
Der letzte Fall ist der Grund, warum Point-in-Time-Korrektheit selbst hier zählt. Wenn Sie eine auf März datierte Rechnung gegen einen Stammdatensatz abgleichen, dessen Adresse sich im Mai geändert hat, sind die Attribute aus dem März diejenigen, die übereinstimmen sollten. Alle Versionen in eine einzige “goldene” Zeile zu kollabieren, wirft die Historie weg, die Abstimmung und Prüfung später brauchen.
Der Entity-Resolution-Ansatz
String-Ähnlichkeit auf einem einzelnen Feld reicht nicht aus, und jeden Datensatz gegen jeden anderen zu vergleichen, skaliert nicht. Eine Tabelle mit einer Million Lieferanten ergibt eine halbe Billion Paare. Die Methode hat drei Stufen.
Blocking kommt zuerst. Sie partitionieren die Datensätze in Kandidatengruppen, sodass immer nur plausibel zusammenpassende Datensätze überhaupt verglichen werden. Ein Block-Schlüssel könnten die ersten vier Zeichen eines normalisierten Namens plus die Postleitzahl sein, oder eine phonetische Kodierung des Namens, oder das Präfix der Steuer-ID. Gutes Blocking verkleinert den Vergleichsraum um Größenordnungen und hält echte Treffer dabei im selben Block. Wenn ein echtes Dublettenpaar nie in einem gemeinsamen Block landet, kann kein nachgelagertes Modell es wieder einfangen. Deshalb ist der Recall des Blockings die Kennzahl, die man im Auge behält.
Scoring kommt als Zweites. Innerhalb jedes Blocks erhält jedes Kandidatenpaar einen Ähnlichkeitsvektor: Editierdistanz auf dem Namen, Token-Überlappung auf der Adresse, exakt-oder-nicht auf der Steuer-ID, exakt-oder-nicht auf dem Bankkonto, Abstand zwischen den Registrierungsdaten. Ein Modell (oft Gradient-Boosted Trees, manchmal ein feinabgestimmter Encoder für die Textfelder) macht aus diesem Vektor eine Match-Wahrscheinlichkeit. Der Sinn des feldübergreifenden Scorings ist, dass kein einzelnes Feld allein entscheidet. Ein gemeinsames Bankkonto plus ein ähnlicher Name ist ein starker Treffer, selbst wenn die Adressen abweichen. Eine gemeinsame Adresse mit unterschiedlichen Steuer-IDs und unterschiedlichen Bankkonten ist ein starker Nicht-Treffer: genau der Tochtergesellschaftsfall, den Sie nicht zusammenführen dürfen.
Survivorship kommt als Drittes. Sobald ein Cluster von Datensätzen als dieselbe Entität eingestuft ist, entscheiden Sie, welche Werte in den zusammengeführten Datensatz übernommen werden: das jüngste verifizierte Bankkonto, die vollständigste Adresse, die Steuer-ID, die gegen das Register validiert. Hier zahlt sich Lineage aus. Jedes übernommene Feld sollte einen Verweis auf den Quelldatensatz tragen, aus dem es stammt, damit ein Prüfer fragen kann, warum der zusammengeführte Lieferant diese IBAN hat, und eine Antwort bekommt.
Den Schwellenwert setzen und mit ihm leben
Es gibt keinen Schwellenwert, der jede Dublette findet und nichts zusammenführt, was er nicht sollte. Sie handeln zwei Fehlerarten gegeneinander ab, und im Zahlungsverkehr sind sie nicht symmetrisch. Eine übersehene Dublette lässt zwei Datensätze zurück, die später eine Doppelzahlung auslösen könnten. Eine falsche Zusammenführung verschmilzt zwei reale Entitäten und kann das Geld des einen Unternehmens auf das Konto eines anderen leiten. Das Zweite ist schlimmer, und Ihr Budget für False Positives sollte das widerspiegeln.
Setzen Sie den Arbeitspunkt also bewusst:
- Bauen Sie ein Eval-Set aus gelabelten Paaren, echte Treffer und echte Nicht-Treffer, einschließlich der schwierigen Tochtergesellschaftsfälle, und messen Sie Precision und Recall daran, nicht an einer Demo.
- Wählen Sie ein Hochkonfidenz-Band, das im Straight-Through-Verfahren automatisch zusammenführt, ein niedriges Band, das automatisch ablehnt, und ein mittleres Band, das ein Mensch prüft. Die Breite dieses mittleren Bandes ist eine Kostenentscheidung, keine technische.
- Leiten Sie jede automatische Zusammenführung und jede Prüferentscheidung in einen Audit-Trail, damit eine Zusammenführung erklärt und, falls sie falsch war, rückgängig gemacht werden kann.
Achten Sie dann auf Drift. Ein neues Quellsystem, ein anderes Onboarding-Formular, eine Änderung darin, wie eine Region Adressen formatiert: Jedes davon kann die Score-Verteilung verschieben und Datensätze leise über Ihre Schwellenwerte hinwegbewegen. Ein planmäßiges Re-Scoring gegen das Eval-Set, und erneut vor dem Quartalsende, wenn das Volumen hochschnellt, zeigt Ihnen, ob der Arbeitspunkt noch hält. Stammdaten erreichen nie einen fertigen Zustand. Es ist eine Tabelle, die weiter driftet, während Menschen Lieferanten so anlegen, wie Menschen das eben tun, und die Resolution-Pipeline ist das, was sie an Ort und Stelle hält.
Häufige Fragen
Führt die KI meine doppelten Lieferantensätze automatisch zusammen?
Sie sollte Zusammenführungen vorschlagen, nicht durchführen. Das Modell liefert bewertete Kandidatenpaare und einen Survivorship-Vorschlag; ein Prüfer genehmigt alles oberhalb Ihrer Toleranz für False Positives, der Rest läuft im Straight-Through-Verfahren durch.
Wie verhindern Sie, dass eine legitime zweite Entität in die erste hineinverschmolzen wird?
Zwei Datensätze mit gleichem Namen und gleicher Adresse können immer noch eigenständige juristische Personen mit unterschiedlichen Steuer-IDs und Bankverbindungen sein. Blocking und Scoring behandeln Bankkonto und Steuer-ID als starke Signale, und Grenzfälle gehen in die Prüfung statt in die automatische Zusammenführung.
Worin unterscheidet sich das vom Fuzzy-Matching in unserem ERP?
Fuzzy-String-Matching bewertet jeweils nur ein Feld und hat kein Gedächtnis. Entity Resolution gruppiert die Daten per Blocking in Kandidatengruppen, bewertet mehrere Felder gemeinsam und lernt Schwellenwerte aus einem gelabelten Eval-Set, sodass Sie die False-Positive-Rate steuern können.