Ein LEI Code ist eine weltweit anerkannte Kennung für eine Rechtsperson, die nach einer internationalen Norm ausgegeben und veröffentlicht wird, sodass jeder sie nachschlagen kann. Eine DUNS-Nummer ist etwas völlig anderes: eine Unternehmenskennung, die von einem privaten Wirtschaftsdatenunternehmen geführt und in Beschaffung und Lieferkette breit verwendet wird. Beide tauchen in denselben Formularen auf, beide werden in Verträgen zitiert, und beide werden regelmäßig mit Steuernummern verwechselt.
Dieser Artikel legt dar, was jede von ihnen ist, wo sie verwendet wird, wie sie sich unterscheiden und was keine von beiden über das dahinterstehende Unternehmen beweist.
Was ist ein LEI Code?
Der Legal Entity Identifier ist in der internationalen Norm ISO 17442 definiert und besteht aus 20 alphanumerischen Zeichen, von denen eines eine Prüfziffer ist. Ausgegeben wird er über ein öffentliches weltweites System akkreditierter lokaler Vergabestellen, und die daraus entstehenden Datensätze werden veröffentlicht und sind kostenlos nachschlagbar: Die Kennung ist mit Referenzdaten über die Rechtsperson verbunden, etwa mit ihrem eingetragenen Namen und ihrer Adresse.
Der Zweck ist eng umrissen und nützlich. Finanzmärkte und Aufsichtsbehörden brauchten eine Möglichkeit, über Grenzen und über Systeme hinweg eindeutig zu sagen, dass genau diese Rechtsperson gemeint ist, weil Firmennamen nicht eindeutig sind, Transliterationen abweichen und Registernummern national sind. Der LEI beantwortet dieses Bedürfnis: eine Rechtsperson, eine Kennung, überall verwendbar.
Was er nicht ist: keine Lizenz, keine Genehmigung, kein Bonitätsurteil und keine Bescheinigung geordneter Verhältnisse. Eine Rechtsperson mit LEI kann ruhen, in Liquidation sein oder längst gelöscht worden sein; die Kennung hält fest, wer sie ist, nicht wie es um sie steht.
Was ist eine DUNS-Nummer?
Eine DUNS-Nummer ist eine Unternehmenskennung, die von einer privaten Wirtschaftsauskunftei ausgegeben wird. Sie besteht aus neun Ziffern und beruht auf einer großen proprietären Unternehmensdatenbank, die aus öffentlichen Einreichungen, Handelsauskünften und Selbstauskünften der Unternehmen zusammengesetzt ist.
Ihr natürlicher Lebensraum sind Beschaffung und Lieferkette. Große Einkäufer, staatliche Vergabesysteme und Portale zur Lieferantenanlage fragen sie ab, weil sie ihnen einen stabilen Schlüssel für einen Lieferanten liefert, der in verschiedenen Systemen unterschiedlich beschrieben sein kann. In diesen Kreisen ist sie bequem und allgemein verstanden.
Zwei Eigenschaften verdienen Betonung. Erstens ist sie keine internationale Norm und wird nicht von einer öffentlichen Stelle geführt; sie gehört der Auskunftei, die sie vergibt. Zweitens sind ihre Daten kommerziell, die Genauigkeit eines einzelnen Datensatzes hängt also von der Pflege dieser Auskunftei und von dem ab, was Unternehmen ihr mitgeteilt haben – sie ist kein Eintragungsregister und trägt keine eigene Rechtskraft.
Wo tauchen diese Kennungen auf?
Beide Arten erscheinen dort, wo ein Unternehmen gegenüber einem Dritten beschrieben wird und ein Name allein nicht genau genug ist.
| Zusammenhang | Welche Kennung üblicherweise erscheint |
|---|---|
| Grenzüberschreitende Finanztransaktionen und Meldepflichten | LEI |
| Konzerntreasury und Beteiligungsstrukturen | LEI |
| Staatliche und unternehmenseigene Vergabeportale | DUNS |
| Lieferantenanlage und Stammdatenpflege | DUNS, teils zusammen mit einem LEI |
| Bonitätsprüfungen | Beide, verwendet als Abgleichschlüssel und nicht als Nachweis |
| Unternehmensformulare, die nach der Unternehmenskennung fragen | Je nachdem, was der Ersteller des Formulars angenommen hat, häufig keine von beiden |
Die letzte Zeile ist die Ursache sehr vieler Verwirrung. Ein Formular, das nach einer Unternehmenskennung fragt, ohne eine zu benennen, stellt eine Frage mit mehreren richtigen Antworten und sammelt ein Gemisch aus Registernummern, Steuernummern, LEI und DUNS-Nummern, solange das Feld nicht sagt, was es haben möchte.
Ist ein LEI Code dasselbe wie eine Steuernummer?
Nein, und die Unterscheidung lohnt sich genau deshalb, weil beides so oft gleichgesetzt wird.
Eine Steuernummer – eine Steuerkennung oder eine Umsatzsteuernummer – wird von einer Steuerverwaltung für die Steuererhebung ausgegeben. Ein LEI wird nach einer Finanzmarktnorm ausgegeben, damit Rechtspersonen über Systeme hinweg einheitlich identifiziert werden können. Eine DUNS-Nummer wird von einem kommerziellen Datenanbieter für dessen eigene Abgleichzwecke ausgegeben. Drei verschiedene Stellen, drei verschiedene Zwecke und keine Überschneidung in der Bedeutung.
Eine praktische Folge: Der Besitz der einen Kennung sagt nichts über die anderen aus. Ein Unternehmen kann einen LEI und keine Umsatzsteuernummer führen oder eine Umsatzsteuernummer und keinen LEI, und keiner der beiden Zustände ist ungewöhnlich. Ein Formular, das alle gleichzeitig verlangt, stellt eine Anforderung, die nicht jedes legitime Unternehmen erfüllen kann, und sollte deshalb begründen können, wofür es jede einzelne braucht.
Was beweist eine dieser Kennungen tatsächlich?
Sie beweist Identifikation, und nur Identifikation. Das ist das Wichtigste, was man verinnerlichen sollte, weil die Versuchung stark ist, in diese Kennungen mehr hineinzulesen.
Ein LEI-Datensatz bestätigt, dass die Rechtsperson im weltweiten System bekannt ist und dass ein Referenzdatensatz existiert. Er bestätigt nicht, dass die Rechtsperson zahlungsfähig, zugelassen, regelkonform oder zu dem berechtigt ist, was sie behauptet. Ein DUNS-Datensatz bestätigt, dass die Auskunftei einen Datensatz zu diesem Unternehmen führt. Er bestätigt nicht, dass das Unternehmen eingetragen ist, und das Fehlen einer DUNS-Nummer bedeutet keineswegs, dass ein Unternehmen unseriös wäre – viele vollkommen reale Unternehmen beschaffen sich nie eine.
Am besten behandelt man beide als Verbindungsschlüssel. Sie helfen, die Version eines Unternehmens aus einem System mit der Version desselben Unternehmens aus einem anderen System zur Deckung zu bringen. Die Prüfung eines Unternehmens ist eine eigene Tätigkeit, die gegen das Handelsregister des Landes der Eintragung geführt wird und, wo der steuerliche Status zählt, gegen den amtlichen Auskunftsdienst der zuständigen Steuerverwaltung.
Für Entwickler: externe Kennungen speichern und prüfen
Speichern Sie jede Kennung in einem eigenen Feld, mit eigener Bezeichnung und eigener Prüffunktion, und niemals hinter einer einzigen allgemeinen Spalte für Unternehmenskennungen. Felder mit gemischtem Inhalt lassen sich nicht prüfen, sind unbequem zu indizieren und sammeln garantiert Ausschuss.
Beim LEI behandeln Sie den Wert als alphanumerische Zeichenkette fester Breite in Großbuchstaben und implementieren die veröffentlichte Prüfziffernregel, wenn Sie eine lokale Plausibilitätskontrolle brauchen – sie fängt Übertragungsfehler günstig ab. Bei der DUNS-Nummer behandeln Sie den Wert als Ziffernfolge mit einem wichtigen Vorbehalt: Es gibt keinen Algorithmus, den Sie lokal berechnen könnten, eine lokale Prüfung kann also nur die Gestalt bestätigen und nichts weiter. Speichern Sie keine der beiden in einer Ganzzahlspalte, und nehmen Sie nie an, dass eine neunstellige Zeichenkette allein wegen ihrer Länge eine DUNS-Nummer ist.
Behandeln Sie die Nachschlagdienste, die diese Kennungen auflösen, als externe Abhängigkeiten mit der üblichen Sorgfalt. Geben Sie ihnen einen Zeitablauf, werten Sie einen nicht erreichbaren Dienst als unbekanntes Ergebnis und nicht als Fehlschlag, und speichern Sie erfolgreiche Abfragen für einen sinnvollen Zeitraum zwischen, negative Ergebnisse dagegen deutlich kürzer. Protokollieren Sie, dass eine Abfrage stattgefunden hat, und behandeln Sie die Nutzdaten als Geschäftsdaten.
Zwei Sicherheitsgewohnheiten sind in Testumgebungen wichtig. Erstens: Testen Sie nicht mit echten Kennungen. Ein erzeugter Wert genügt, um das Feld zu prüfen, und der Unternehmensdaten-Generator auf dieser Seite füllt die Kennungsfelder mit synthetischen Werten, die zu nichts auflösen. Zweitens: Behandeln Sie diese Kennungen niemals als Berechtigung. Eine Abfrage, die einen Datensatz zurückgibt, ist keine Erlaubnis, und Code, der Zugriff auf der Grundlage einer übereinstimmenden Kennung gewährt, ist ein Sicherheitsmangel und keine Bequemlichkeit. Der Artikel zur Steuerkennung führt dieselbe Schichtung für Steuernummern durch, und der Beitrag zu den Testunternehmensdaten zeigt, wo diese Felder in einem vollständigen synthetischen Datensatz sitzen.
Nächste Schritte
Sehen Sie sich an, wie Ihr Produkt nach Unternehmenskennungen fragt, und zählen Sie, wie viele Bedeutungen diese Frage derzeit hat. Wenn ein Feld eine Registernummer, eine Umsatzsteuernummer und einen LEI aufnehmen kann, teilen Sie es in benannte Felder und prüfen Sie jedes nur auf seine eigene Gestalt. Erzeugen Sie dann eine synthetische Rechtsperson im Unternehmensdaten-Generator und bestätigen Sie, dass Ihre Formulare, Exporte und Protokolle die Kennung jeweils benennen, die sie anzeigen.