B2B-Account-Deduplizierung: Die sieben Fallstricke, die Ihr CRM ruinieren (2026)

Kurzfassung: Die B2B-Account-Deduplizierung scheitert, sobald Sie Firmendatensätze so abgleichen wie Personendatensätze. Denn Rechtsträger, Tochtergesellschaften, Franchisebetriebe und firmografische Felder verhalten sich völlig anders als ein Name und ein Geburtsdatum. Die Lösung ist Entity Resolution auf Account-Ebene: klar getrennte Matching-Verfahren, ein Identitätsgraph, der Hierarchien erhält, und eine Auflösung, die beim Ingest über jedes System läuft, das einen Account berührt – statt einer einmaligen CRM-Bereinigung.

Sehen Sie, wie Entity Resolution auf Account-Ebene die Fälle löst, an denen reines Namensmatching scheitert. Demo buchen oder Tilores Studio kostenlos testen.

Warum bricht der Account-Abgleich an Rechtsträgername vs. Handelsname?

Der Rechtsname eines Unternehmens – der beim Register hinterlegte – ist häufig nicht der Name, unter dem es am Markt auftritt, und keiner von beiden entspricht dem, was ein Vertriebsmitarbeiter in ein Formular tippt. Ein Unternehmen kann als „Acme Manufacturing LLC“ eingetragen sein, als „Acme Mfg“ auftreten, seine Kunden als „Acme“ fakturieren – und landet dann als drei verschiedene CRM-Datensätze im System: „Acme Manufacturing“, „Acme Mfg Ltd“ und „Acme Corp“. Sowohl Großbritannien als auch die USA kennen diese Trennung formal: Eine britische Gesellschaft hinterlegt einen Rechtsnamen, kann aber unter einem separaten Geschäftsnamen auftreten, und ein US-Unternehmen registriert einen Rechtsträgernamen, während es im Tagesgeschäft unter einem „Doing Business As“-Namen agiert.

Naives Matching scheitert hier in beide Richtungen. String-Matching auf den wörtlichen Namen führt entweder unverwandte Unternehmen zusammen, die zufällig ein gängiges Wort teilen (warum „Group“, „Holdings“ und „Solutions“ einfache Normalisierung aushebeln, vertiefen wir in Die Normalisierung von Firmennamen reicht für Fuzzy Matching nicht aus), oder es erzeugt drei getrennte Accountdatensätze für ein und dasselbe Unternehmen. Die Lösung besteht darin, das Identifikator-Problem vom Namensähnlichkeits-Problem zu trennen: Deterministisches Matching setzt auf stabile Identifikatoren wie Registernummer, Legal Entity Identifier oder D-U-N-S-Nummer, sofern vorhanden. Fuzzy Matching, gewichtet danach, wie häufig jedes Wort in Ihrem Accountbestand vorkommt, fängt die Namensvarianten ab, die Identifikatoren allein nicht erwischen.

Warum werden Tochtergesellschaften und Parent-Child-Hierarchien in den falschen Account eingeebnet?

Legal Entity Identifier existieren genau deshalb, weil Aufsichtsbehörden und Geschäftspartner wissen müssen, mit welcher Tochtergesellschaft welcher Muttergesellschaft sie es tatsächlich zu tun haben – und nicht nur, welcher Markenname auf der Rechnung steht. B2B-Accounts sind nicht flach, und sie flach zu behandeln erzeugt zwei gegensätzliche Fehler. Ebnen Sie zu aggressiv ein, wandern Verträge und Abrechnungshistorie einer Tochter in den Account der Mutter, was die lokale Fakturierung verfälscht und genau die Entität verliert, die ein regionales Team tatsächlich betreuen muss. Verknüpfen Sie sie gar nicht, hat ein Vertriebsteam keine Möglichkeit zu sehen, dass die Muttergesellschaft vor sechs Monaten einen Zwei-Millionen-Dollar-Deal unterschrieben hat, wenn heute eine Tochter mit einer neuen Angebotsanfrage auftaucht.

Die Lösung ist, Hierarchie explizit abzubilden, statt sie wegzuauflösen. Ein Identitätsgraph behält jede Tochtergesellschaft als eigene auflösbare Entität und speichert die Parent-Child-Beziehung als Kante zwischen Entitäten, nicht als zusammengeführte Zeile. Damit bleiben beide Sichten gleichzeitig erhalten: die eigene Abrechnungs- und Vertragshistorie der Tochter und die konsolidierte Sicht, die ein Umsatzteam über die gesamte Unternehmensfamilie hinweg braucht.

Warum werden Franchise- und Filialstandorte zu einem Account verschmolzen oder in Hunderte zersplittert?

Ein Franchisebetrieb ist ein rechtlich eigenständiges Unternehmen, das von einem Franchisenehmer unabhängig geführt wird – auf Basis einer Lizenz des Franchisegebers und obwohl es den Namen der Dachmarke und oft auch deren Marketing-Website teilt. Eine bundesweite Franchisemarke kann Tausende solcher Standorte haben, jeder mit eigenen Verträgen, eigener Abrechnungsbeziehung und eigener Supporthistorie, aber alle unter demselben oder einem nahezu identischen Namen.

Naives Matching auf den Markennamen führt jeden Standort zu einem einzigen Riesen-Account zusammen. Das zerstört die Abrechnungsgenauigkeit auf Standortebene und macht es unmöglich zu erkennen, welcher konkrete Franchisenehmer mit der Verlängerung im Rückstand ist. Naives Matching auf die Adresse bewirkt das Gegenteil: Es behandelt einen umgezogenen oder neu eröffneten Standort als völlig neuen, unverbundenen Account, ganz ohne Bezug zur Franchisebeziehung. Die Lösung entspricht dem Fall der Tochtergesellschaft: Lösen Sie jeden Standort als eigene Entität auf und verbinden Sie ihn über eine Kante mit der Entität des Franchisegebers – eine Kante, die eine vertragliche und keine eigentumsrechtliche Beziehung abbildet.

Warum zerstört eine Fusion oder Übernahme einen Account-Abgleich, der gestern noch funktionierte?

Eine Fusion ändert routinemäßig den Rechtsnamen eines Unternehmens, und das Verfahren dafür – die formale Anmeldung einer Namensänderung beim Handelsregister – ist gerade deshalb so gut dokumentiert, weil es so häufig vorkommt. Für Accountdaten ist das Problem: Verträge, Rechnungen und Supporttickets aus der Zeit vor der Fusion tragen weiterhin den alten Rechtsnamen. Wenn Ihr CRM drei Jahre Dealhistorie unter „Acme Manufacturing LLC“ führt und das Unternehmen fusioniert und sich in „Meridian Industrial“ umbenennt, werden neue Abschlüsse unter dem neuen Namen verbucht, während der alte Name im System liegt und aussieht wie ein völlig anderes Unternehmen. Ein Verlängerungsgespräch startet dann bei null Kontext statt bei drei Jahren Beziehung.

Die Lösung erfordert eine zeitliche Sicht auf Identität: Eine Entität sollte jeden Namen, unter dem sie je aufgetreten ist, als bekanntes Alias ihrer selbst behalten. So löst ein Datensatz, der über den alten Rechtsnamen gematcht wurde, auf denselben Account auf wie ein Datensatz, der über den aktuellen Namen gematcht wurde. Diese Kontinuität zu verlieren, gehört zu den teureren – und besser vermeidbaren – Fehlern der Account-Deduplizierung, denn das zugrunde liegende Unternehmen hat nie aufgehört, Kunde zu sein.

Warum belegt eine geteilte oder übereinstimmende Domain nicht zuverlässig, dass zwei Datensätze zum selben Account gehören?

Die Domain ist ein beliebter Standard-Matchschlüssel, weil sie sich trivial aus einer E-Mail-Adresse ziehen lässt. Für B2B-Accounts versagt sie jedoch in beide Richtungen. Sie matcht zu viel: Eine Marketingagentur, eine Beratung oder ein geteilter Coworking-Space kann Kontakte vieler tatsächlich unverbundener Kundenunternehmen unter einer Domain bündeln, und jeder Einzelunternehmer mit einem generischen E-Mail-Anbieter sieht aus wie jeder andere Einzelunternehmer auf derselben Domain. Und sie matcht zu wenig: Ein realer Account kann legitim mehrere Domains gleichzeitig besitzen – eine regionale Website, eine nach einer Umbenennung weitergeführte Altmarken-Domain oder eine Domain, die über genau die oben beschriebene Art von Übernahme hinzukam und nun als DNS-Variante des Fusionsproblems auftaucht.

Die Lösung ist, die Domain als ein probabilistisches Signal zu behandeln, das neben Rechtsidentifikatoren und firmografischen Daten gewichtet wird – niemals als eigenständigen deterministischen Schlüssel. Eine geteilte Domain erhöht die Wahrscheinlichkeit, dass zwei Datensätze zusammengehören; als alleiniger Beweis darf sie nie genügen.

Warum führen frei erfassbare firmografische Felder zu falschen und übersehenen Matches?

Branche, Mitarbeiterzahl und Umsatzklasse gehören zu den am uneinheitlichsten befüllten Feldern in jedem B2B-System: meist Freitext oder locker gepflegte Auswahllisten, ausgefüllt von unterschiedlichen Mitarbeitern zu unterschiedlichen Zeitpunkten und manchmal später von einem Anreicherungstool mit einer frischen Schätzung überschrieben, die dem widerspricht, was ein Mitarbeiter ein Jahr zuvor eingetragen hat. Datenqualität, die auf diese Weise verfällt, ist ein gut untersuchtes Problem und keine Eigenart eines einzelnen Unternehmensprozesses. Ein Mitarbeiter erfasst „Software“, der nächste „SaaS“, ein dritter „Technologie“ – für exakt dasselbe Unternehmen, und keiner von ihnen liegt falsch.

Matching-Logik, die exakte Übereinstimmung dieser Felder verlangt, übersieht echte Duplikate wegen eines Feldes, das nie ein starkes Identitätssignal war. Matching-Logik, die firmografische Felder komplett ignoriert, verschenkt einen nützlichen Zusatzbeleg, wenn zwei Accountnamen ähnlich, aber nicht eindeutig sind. Die Lösung ist, firmografische Daten als gewichteten, probabilistischen Zusatzbeleg einzusetzen – als Teil eines Konfidenzwerts statt als Pflicht-Exaktmatch oder ignoriertes Feld.

Warum sieht derselbe Account in CRM, Abrechnungssystem und Support-Desk unterschiedlich aus – und warum reicht eine CRM-Bereinigung allein nicht?

Ein mittelgroßes B2B-Unternehmen betreibt sein Go-to-Market typischerweise über drei oder mehr Systeme, die jeweils eine eigene Kopie „des Accounts“ halten: das CRM, das Deal- und Kontakthistorie führt; das Abrechnungs- oder Rechnungssystem, dem es auf den im Vertrag genannten Rechtsträger ankommt; und den Support-Desk, der oft in dem Moment einen brandneuen Account anlegt, in dem das erste Ticket eintrifft – mit der Domain als Schlüssel, die der Absender zufällig verwendet hat. Jedes System hält für sich genommen seinen eigenen Datensatz für sauber.

Ein einmaliges Deduplizierungsprojekt im CRM erreicht immer nur eines der drei Systeme. Sechs Monate später sieht das CRM aufgeräumt aus, während Abrechnung und Support längst weiter davon abgedriftet sind – denn das eigentliche Problem war nie, dass die Daten einmal bereinigt werden müssten. Es ist, dass diese Accounts fortlaufend zu unterschiedlichen Zeiten, von unterschiedlichen Menschen und in unterschiedlichen Systemen angelegt und aktualisiert werden. Die daraus folgende Architekturfrage – und wo das aufgelöste Profil liegen sollte – behandle ich in Eine einheitliche Kundensicht über CRM, Marketing und Analytics aufbauen. Für Accounts gilt dasselbe Prinzip: Die Auflösung muss fortlaufend laufen, über jedes System hinweg, das einen Account berührt – nicht einmalig in einem einzigen davon.

Wie vermeidet Entity Resolution auf Account-Ebene alle sieben Fallstricke auf einmal?

Jeder der oben genannten Fallstricke geht auf dieselbe Ursache zurück: ein Unternehmen wie eine Person zu behandeln und den Datensatz eines Systems für die ganze Wahrheit zu halten. Tilores löst B2B-Accounts mit drei klar getrennten Matching-Verfahren auf – deterministisch, unscharf und probabilistisch –, die bewusst nicht zu einer einzigen Technik verschmolzen werden. So trägt ein Match über die Registernummer, ein gewichteter Namensmatch und ein firmografischer Konfidenzmatch jeweils seine eigene nachvollziehbare Begründung. Hierarchie wird nicht wegaufgelöst: Parent-Child- und Franchisegeber-Franchisenehmer-Beziehungen werden als Kanten im Identitätsgraphen gespeichert, sodass die konsolidierte Sicht und die Einzelentitätssicht beide verfügbar bleiben.

Die Auflösung geschieht beim Ingest: Sobald ein Datensatz aus Ihrem CRM, Ihrem Abrechnungssystem oder Ihrem Support-Desk eintrifft, gleicht Tilores ihn sofort gegen den bestehenden Graphen ab, behält den Originaldatensatz neben einer normalisierten Fassung für das Matching und aktualisiert die Kanten der Entität, bevor irgendjemand sie abfragt. Eine Abfrage über die GraphQL-API ruft dann diesen bereits aufgelösten, aktuellen Account ab, statt ihn live neu zu berechnen. Genau das ermöglicht es, dass CRM, Abrechnung und Support ohne wiederkehrendes Bereinigungsprojekt denselben Account lesen. Wir vergleichen diesen Ansatz direkt mit flachem Matching, Vektorähnlichkeit und MDM-Plattformen in Entity Resolution für KI: API vs. Vektordatenbank vs. MDM vs. CDP und vertiefen die Trennung von Ingest- und Abfragezeit in Echtzeit- vs. Batch-Entity-Resolution. Nichts davon läuft auf dauerhaft bereitstehender Infrastruktur; Matching und Retrieval sind serverless und werden pro Anfrage ausgeführt und abgerechnet. Und nichts davon ersetzt Ihr CRM, Ihre MDM-Plattform, Ihre CDP oder Ihr Data Warehouse. Tilores steht neben diesen Systemen und liefert ihnen einen aufgelösten Account, statt selbst zu einem weiteren System of Record zu werden, das Sie synchron halten müssen.

Fallstrick, Ursache des Scheiterns und was korrekte Auflösung leistet

Fallstrick	Warum naives Matching scheitert	Was korrekte Account-Auflösung leistet
Rechtsname vs. Handelsname (DBA)	Matcht auf die wörtlich ins Formular getippte Zeichenkette	Trennt Identifikator-Matching (Registernummer, LEI, D-U-N-S) vom gewichteten Fuzzy-Namensmatching
Tochtergesellschaften und Parent-Child-Hierarchie	Führt entweder alles Namensgleiche zusammen oder lässt echte Beziehungen unverknüpft	Speichert Parent-Child-Beziehungen als Kanten im Identitätsgraphen statt als eingeebnete Zeile
Franchise- und Filialstandorte	Verschmilzt jeden Standort zu einem Account oder behandelt jeden als unverbunden	Löst jeden Standort als eigene Entität auf, verknüpft mit der Entität des Franchisegebers
Fusionen und Umbenennungen	Verliert die Accounthistorie, weil der Rechtsträger den Namen gewechselt hat	Behält jeden früheren Namen dauerhaft als bekanntes Alias derselben Entität
Domain- vs. Firmen-Diskrepanz	Matcht geteilte Domains zu großzügig, Accounts mit mehreren Domains zu knapp	Behandelt die Domain als ein gewichtetes, probabilistisches Signal, nie als alleinigen deterministischen Schlüssel
Frei erfassbare firmografische Felder	Verlangt exakte Übereinstimmung oder ignoriert das Feld ganz	Nutzt firmografische Daten als gewichteten, probabilistischen Zusatzbeleg
Wildwuchs zwischen CRM, Abrechnung und Support	Bereinigt ein System, während die anderen wieder auseinanderlaufen	Löst fortlaufend beim Ingest auf, über jedes Quellsystem hinweg, das einen Account berührt

FAQ

Warum ist die B2B-Account-Deduplizierung schwieriger als das Deduplizieren von Verbraucherdatensätzen?

Ein Verbraucherdatensatz löst sich meist über eine kleine Menge stabiler personenbezogener Identifikatoren auf. Ein Accountdatensatz muss Rechtsträgernamen berücksichtigen, die vom Handelsnamen abweichen, dazu Parent-Child-Hierarchien, Franchisebeziehungen und Namensänderungen durch Fusionen – nichts davon hat eine Entsprechung im Abgleich von Personendaten.

Löst die Normalisierung von Firmennamen das Problem doppelter B2B-Accounts?

Nein. Normalisierung entfernt Rechtsformzusätze und Formatierung, kann aber nicht zwischen einem geteilten, bedeutungstragenden Geschäftswort wie „Group“ oder „Holdings“ und einer echten Namensübereinstimmung unterscheiden. Genau deshalb braucht es neben der Normalisierung ein gewichtetes, häufigkeitsbewusstes Matching.

Wie sollten Mutter- und Tochtergesellschaften bei der Deduplizierung abgebildet werden?

Als verknüpfte, aber eigenständige Entitäten. Eine Tochter in den Account der Mutter zu verschmelzen, zerstört die Genauigkeit lokaler Abrechnung und Verträge; sie unverknüpft zu lassen, verbirgt die konzernweite Beziehung. Ein Identitätsgraph bildet die Beziehung als Kante zwischen zwei getrennt auflösbaren Entitäten ab.

Kann ein Domain-Abgleich allein doppelte B2B-Accounts erkennen?

Nein. Eine geteilte Domain kann unverwandte Unternehmen unter einen Matchschlüssel bringen, etwa bei einer Agentur- oder Coworking-Domain, und ein einzelner realer Account kann legitim mehrere Domains halten. Die Domain sollte als eines von mehreren Signalen gewichtet und nicht als deterministischer Identifikator behandelt werden.

Was passiert nach einer Fusion oder Übernahme mit dem Account-Abgleich?

Der Rechtsträgername ändert sich, die Kundenbeziehung nicht. Die Auflösung muss den alten Namen als bekanntes Alias derselben Entität behalten, damit Datensätze von vor und nach der Fusion weiterhin zu einer durchgehenden Accounthistorie auflösen.

Ersetzt Tilores unser CRM, unsere MDM-Plattform oder unsere CDP?

Nein. Tilores steht neben Ihrem CRM, Ihrer MDM-Plattform, Ihrer CDP und Ihrem Data Warehouse, löst Accounts beim Ingest auf und liefert die aktuelle aufgelöste Entität über die GraphQL-API. Es wird kein neues System of Record, das Sie zusätzlich abgleichen müssten.

Muss die B2B-Account-Auflösung fortlaufend laufen, oder genügt eine einmalige Bereinigung?

Fortlaufend. Eine einmalige Bereinigung erreicht nur das System, in dem sie läuft – meist das CRM –, während Abrechnungs- und Supportsysteme weiterhin eigenständig Accountdatensätze anlegen und aktualisieren. Die Auflösung muss beim Ingest über jedes Quellsystem hinweg laufen, um genau zu bleiben.