Ein Unternehmensdaten Generator erzeugt die Feldmenge, die ein Formular für die Geschäftskundenanbahnung abfragt: einen Rechtsnamen mit dem passenden Suffix seiner Jurisdiktion, eine Registernummer, eine Steuerkennung, eine Adresse und häufig auch eine Rechtsform und einen Ansprechpartner – so angeordnet, dass die Teile zueinander passen. Die Schwierigkeit liegt nicht darin, einen Firmennamen zu erfinden. Sie liegt darin, ein Dutzend voneinander abhängiger Identifikatoren mit einer einzigen Jurisdiktion in Übereinstimmung zu halten.
Dieser Leitfaden behandelt, wie sich die Konventionen für Firmennamen zwischen Ländern verschieben, warum Registernummern und Steuernummern anderen Regeln folgen als die meisten Teams erwarten, welche Felder ein KYB-Ablauf wirklich benötigt und wofür ein erzeugter Rechtsträger niemals verwendet werden darf. Am Ende wissen Sie, welche Konsistenzprüfungen in Ihre eigene Testsuite gehören und welche Annahmen über Unternehmensdaten schlicht falsch sind.
Warum trägt der Firmenname die Jurisdiktion im Suffix?
Das Suffix am Ende eines Firmennamens ist keine Verzierung. Es benennt die Rechtsform, unter der der Rechtsträger existiert, und es ist in den meisten Jurisdiktionen verpflichtend. Eine deutsche Gesellschaft mit beschränkter Haftung trägt GmbH, eine französische oder spanische Gesellschaft kann S.A. oder S.A.S. tragen, eine malaysische Gesellschaft trägt Sdn. Bhd., eine australische Proprietary Company trägt Pty Ltd, eine amerikanische Limited Liability Company trägt LLC, und eine türkische Aktiengesellschaft trägt A.Ş.
Weil das Suffix die Rechtsform kodiert, schränkt es auch den Rest des Datensatzes ein. Ein Rechtsträger mit dem Suffix GmbH unterliegt dem deutschen Gesellschaftsrecht, also folgt seine Registernummer dem deutschen Muster, seine Steuerkennung folgt dem deutschen Muster, und seine Adresse liegt in Deutschland. Ein Datensatz, der ein deutsches Suffix mit einer britischen Registernummer mischt, ist nicht subtil falsch – er beschreibt ein Unternehmen, das nicht existieren kann.
Zeichensetzung und diakritische Zeichen bilden eine zweite Ebene. Mehrere Suffixe enthalten Punkte, einige enthalten akzentuierte Zeichen, und einige werden konventionell ohne Leerzeichen geschrieben. Ein Namensfeld, das bei der Eingabe Satzzeichen entfernt, beschädigt einen Rechtsnamen; ein Validator, der eine einzige Suffixliste erwartet, weist die Formen zurück, die er noch nie gesehen hat. Der Artikel zu den Firmennamen-Suffixen nach Land sammelt die gebräuchlichen Formen und ihre Konventionen.
Ein dritter Punkt ist die Umschrift. Namen aus Jurisdiktionen mit nichtlateinischen Schriften erreichen ein Formular entweder transliteriert oder in Originalschrift, und beide Wege sind zulässig. Werden sie gemischt, entstehen zwei Datensätze für dasselbe Unternehmen, die keine Prüfung als Duplikat erkennt, weil die Zeichenketten einander nicht ähneln.
Wie unterscheiden sich Registernummern und Steuerkennungen?
Eine Registernummer wird vom Handelsregister einer bestimmten Jurisdiktion vergeben. Ihre Länge, ihr Format und die Frage, ob sie Buchstaben enthält, variieren. Manche Register verwenden eine rein numerische Folge, manche betten ein Jahr oder einen Bezirk ein, und manche vergeben eine alphanumerische Zeichenkette. Es gibt keine internationale Norm, die diese Nummern austauschbar macht; ein System, das sie in einem Feld mit einer einzigen Prüfregel speichert, weist gültige Eingaben aus dem größten Teil der Welt zurück.
Eine Steuerkennung ist eine andere Nummer, vergeben von einer anderen Behörde. Die beiden zu vermengen gehört zu den häufigsten Modellierungsfehlern in Onboarding-Systemen. In vielen Ländern hat ein Unternehmen sowohl eine Registernummer als auch eine Steuernummer, sie haben unterschiedliche Formate, und sie erscheinen in unterschiedlichen Feldern eines Formulars. Ein Datensatz, der beide Felder mit demselben Wert füllt, ist intern inkonsistent, obwohl jeder Wert für sich plausibel wirkt.
Die Umsatzsteuer-Identifikationsnummer bildet eine dritte Variante. Innerhalb der Europäischen Union beginnt sie üblicherweise mit einem zweibuchstabigen Länderpräfix, gefolgt von der inländischen Steuernummer, und das Präfix muss zum Land der Adresse und der Registrierung passen. Der Artikel zu den USt-IdNr-Formaten nach Land zeigt die Bandbreite der Formen, und der Artikel zu den Prüfregeln für Steuer-IDs behandelt die Checks, die sie voneinander unterscheiden.
Für Testdaten ist wichtig, dass jede dieser Nummern eine eigene Prüfziffernlogik haben kann. Eine Steuernummer, die nur die Länge einhält, aber die Prüfziffer verletzt, besteht jede Feldprüfung und fällt erst dort auf, wo die Prüfsumme gerechnet wird. Solche Werte sind nützlich – aber nur, wenn Sie sie bewusst als Negativfall einsetzen und nicht versehentlich als Positivfall. Wie Prüfziffern grundsätzlich arbeiten, beschreibt der Artikel zur Funktionsweise der Nummernprüfung.
Was ist mit LEI und D-U-N-S?
Der Legal Entity Identifier ist ein zwanzigstelliger alphanumerischer Code, der Rechtsträgern zugewiesen wird, die an Finanztransaktionen teilnehmen, und er ist weltweit eindeutig. Er ist keine Registernummer und ersetzt keine; er ist ein zusätzlicher Identifikator, den eine Finanzgegenseite anfordern kann. Seine Struktur umfasst ein Präfix der lokalen Betriebseinheit, einen reservierten Abschnitt und zwei Prüfziffern, die nach einer veröffentlichten Norm berechnet werden.
Die D-U-N-S-Nummer ist ein neunstelliger Identifikator, der von einem kommerziellen Datenanbieter vergeben wird und breit in Kredit- und Lieferantenbewertungen verwendet wird. Sie ist kein staatlicher Identifikator, und sie existiert nur für Rechtsträger, die dieser Anbieter erfasst hat. Sie in einem Formular als Pflichtfeld zu behandeln, schließt die meisten Unternehmen in den meisten Ländern aus.
Beide Identifikatoren gehören in einen Testdatensatz, weil ihre Längen- und Zeichenregeln unverwechselbar sind und weil ihr Vorhandensein in einem Formular den Validierungspfad ändert. Ein Generator sollte jedoch offenlegen, ob der erzeugte LEI die veröffentlichte Prüfsumme erfüllt. Ein wohlgeformt aussehender LEI mit falscher Prüfziffer fällt genau an der Stelle durch, die Sie prüfen wollten. Der Artikel zu den Geschäftsidentifikatoren LEI und D-U-N-S geht beide ausführlicher durch.
In der Praxis reicht es, für diese Felder drei Werte zu erzeugen: einen formal gültigen, einen mit richtiger Länge und falscher Prüfziffer und einen mit abweichender Länge. Damit decken Sie die drei Zweige ab, die jede Implementierung hat – akzeptieren, Prüfsummenfehler, Formatfehler.
Welche Felder machen einen KYB-Datensatz kohärent?
Ein Know-your-Business-Ablauf fragt den Rechtsnamen eines Rechtsträgers ab, seine Jurisdiktion und Rechtsform, seine eingetragene Adresse, seine Registernummer, seine Steuerkennung, seine Vertretungsberechtigten und häufig seine Eigentümerstruktur. Die Kohärenzanforderung lautet, dass diese Felder einen Rechtsträger an einem Ort beschreiben.
Das bedeutet: Die Jurisdiktion bestimmt die Namenskonvention, das Format der Registernummer und das Format der Steuernummer. Die eingetragene Adresse liegt im selben Land, und wenn sie in einer Untereinheit liegt, muss die Postleitzahl zu dieser Untereinheit passen. Die Vertretungsberechtigten tragen Namen und Adressen, die zur Jurisdiktion passen, und das Gründungsdatum liegt vor jedem Dokument, das der Rechtsträger unterzeichnet. Die beiden Nummern sind getrennte Tatsachen; ein Formular, das sie vermengt, akzeptiert eine Steuerkennung im Registerfeld – ein Defekt, der erst in einer Jurisdiktion sichtbar wird, die für beides dieselbe Nummer verwendet. Der Artikel zu den Registernummern nach Land listet die Formate, die eine Kohärenzprüfung erzwingen muss.
Kohärenz hat außerdem eine Richtung. Ein Wechsel der Jurisdiktion sollte jedes abhängige Feld mitziehen; ein Test, der das Land in einem bestehenden Datensatz umstellt, prüft also mehr als ein Etikett. In der Praxis tun die meisten Formulare das nicht, und unter dem neuen Land bleibt eine veraltete Registernummer stehen – genau die Art von Defekt, die ein kohärenter Datensatz in einem Durchlauf sichtbar macht statt in der Produktion.
Das Feld, das Kohärenz am häufigsten bricht, ist die Adresse, weil Teams sie gern aus einem Personendatensatz übernehmen, ohne das Land anzupassen. Ein deutsches Unternehmen mit britischer Postleitzahl ist ein offensichtlicher Defekt, den ein verschachtelter Validator sofort fängt; dieselbe Logik gilt für die Telefonvorwahl im Kontaktdatensatz. Der Artikel zur KYB-Testcheckliste stellt die Prüfungen in der Reihenfolge zusammen, in der eine echte Onboarding-Pipeline sie anwendet.
Es gibt zudem eine Gruppe von Feldern, die viele Systeme ergänzen und für die es überhaupt kein universelles Format gibt: Mitarbeiterzahl, Jahresumsatz, Branchenklassifikation und Website. Sie sind freiformig oder klassifikationsbasiert, und ein Testdatensatz sollte sie bewusst variieren, statt jeden erzeugten Rechtsträger in Größe und Branche identisch zu lassen. Variation ist wichtig, weil Validierungslogik, die nie auf einen ungewöhnlichen Wert trifft, nie ausgeführt wurde. Eine Übersicht der Rechtsformen je Land, die eine solche Matrix abdecken sollte, liefert der Artikel zu den Rechtsformen nach Jurisdiktion.
Sind erzeugte Unternehmen echte Rechtsträger?
Sie sind es nicht. Ein erzeugtes Unternehmen hat einen Rechtsnamen mit gültigem Suffix, eine Registernummer im richtigen Format, eine Steuerkennung im richtigen Format und eine Adresse im richtigen Land – und nichts davon ist irgendwo eingetragen. Hinter der Registernummer steht keine Anmeldung, hinter der Kennung kein Steuerdatensatz und hinter dem Namen kein Rechtsträger.
Genau diese Eigenschaft macht die Daten unbedenklich nutzbar. Weil das Unternehmen nicht existiert, kann kein Dritter durch den Datensatz geschädigt werden, es kann kein Kredit gegen ihn vergeben werden, und keine Gegenseite kann getäuscht werden, solange der Datensatz klar gekennzeichnet ist. Sie bedeutet auch, dass jede Prüfung, die ein Register abfragt, fehlschlägt – das ist das korrekte Ergebnis und sollte in einem Test das erwartete Verhalten sein. Ein erzeugter Firmenname sollte deshalb auch nicht mit einem realen kollidieren; die einfachste Absicherung ist, erzeugte Namen erkennbar generisch zu halten statt plausibel genug, um auffindbar zu sein.
Die Grenze gehört ausdrücklich in den Datensatz selbst. Datensätze dieser Art sind synthetische Geschäftsdaten, sie entsprechen keinem eingetragenen Rechtsträger, und sie dürfen nicht verwendet werden, um ein reales Konto zu eröffnen, eine reale KYB- oder Bonitätsprüfung zu bestehen, Waren oder Dienstleistungen auf Kredit zu erhalten, Zahlungen unter falschem Namen zu senden oder ein reales Unternehmen zu vertreten.
Wird ein erzeugtes Unternehmen mit einer erzeugten Person als Vertretungsberechtigtem kombiniert, bleibt der gesamte Datensatz synthetisch, und dasselbe Verbot gilt für die Kombination. Ein Datensatz wird nicht dadurch für eine reale Transaktion nutzbar, dass er intern konsistent ist; interne Konsistenz ist eine Testeigenschaft und nichts weiter. Wo die Grenzen synthetischer Firmendaten im Einzelnen verlaufen, behandelt der Artikel zu den Grenzen synthetischer Firmendaten.
Was sollten Ihre B2B-Formulartests abdecken?
Prüfen Sie zuerst die Paarung aus Jurisdiktion und Rechtsform, denn sie steuert alles Weitere. Wählen Sie ein Land, bestätigen Sie, dass die angebotenen Rechtsformen die sind, die dieses Land kennt, und bestätigen Sie, dass das Suffix im Namensfeld gegen die Auswahl validiert wird und nicht frei bleibt.
Prüfen Sie das Feld für die Registernummer im selben Durchlauf gegen mehrere Länder, mit einem Wert in der richtigen Länge und einem, der zu kurz ist. Hier zeigt sich eine einzelne fest verdrahtete Regel, weil das Feld die gültige ausländische Nummer zurückweist statt die ungültige inländische.
Prüfen Sie die Steuerkennung als eigenes Feld mit eigenen Checks, einschließlich des Länderpräfixes, wo eines erwartet wird, und bestätigen Sie, dass das Formular eine Nummer ablehnt, deren Präfix dem gewählten Land widerspricht. Der Artikel zu den Testfällen für Rechnungsformulare erweitert das auf die zahlungsnahen Teile des Ablaufs, in denen der Unternehmensdatensatz auf eine Rechnung trifft.
Prüfen Sie auch die Reihenfolge, in der die Felder erscheinen. Ein einziges globales Formular erzwingt eine Abfolge für jede Jurisdiktion, und diese Abfolge ist irgendwo falsch. Ein Feld, das in einem Land Pflicht ist und in einem anderen bedeutungslos, wird für beide als erforderlich markiert; die daraus entstehende Reibung melden Nutzer als Verwirrung und nicht als Fehler.
Prüfen Sie anschließend die freiformigen Felder. Ein Rechtsname mit einem kaufmännischen Und, ein Name mit einem Punkt aus einem abgekürzten Suffix, ein Name an der Längengrenze und ein Name ein Zeichen darüber decken zusammen die meisten Arten ab, auf die ein Namensfeld bricht. Der Unternehmensdaten-Generator erzeugt Datensätze über diese Jurisdiktionen hinweg mit zueinander passenden Identifikatoren, sodass eine einzelne exportierte Zeile als kohärente Fixture dienen kann, statt von Hand zusammengesetzt zu werden.
Jeder so erzeugte Datensatz ist synthetischer Testdatenbestand ausschließlich für Softwaretests. Er beschreibt keinen eingetragenen oder handelnden Rechtsträger, er verleiht keine rechtliche Existenz, und er darf nicht verwendet werden, um ein Unternehmen vorzutäuschen, reale Konten zu eröffnen oder zu registrieren, Kredit oder Waren zu erlangen oder eine reale Unternehmensprüfung zu bestehen.