LEI-code en DUNS-nummer: twee bedrijfsidentifiers

Een LEI-code is een wereldwijd erkende identificatie voor een juridische entiteit, uitgegeven onder een internationale standaard en gepubliceerd zodat iedereen ze kan opzoeken. Een DUNS-nummer is iets heel anders: een bedrijfsidentificatie die door een particulier commercieel databedrijf wordt onderhouden en veel wordt gebruikt in inkoop en toeleveringsketens. Beide duiken op in dezelfde formulieren, beide worden in contracten aangehaald, en beide worden stelselmatig met fiscale nummers verward.

Dit artikel zet uiteen wat elk van beide is, waar ze worden gebruikt, hoe ze verschillen, en wat geen van beide bewijst over het bedrijf erachter.

Wat is een LEI-code?

De Legal Entity Identifier is gedefinieerd in de internationale standaard ISO 17442 en bestaat uit 20 alfanumerieke tekens, waarvan er één een controlecijfer is. Hij wordt uitgegeven via een publiek wereldwijd systeem van geaccrediteerde lokale operationele eenheden, en de resulterende records worden gepubliceerd en zijn gratis op te zoeken: de identificatie is gekoppeld aan referentiegegevens over de entiteit, zoals haar geregistreerde naam en adres.

Het doel is smal en nuttig. Financiële markten en toezichthouders hadden een manier nodig om “exact deze juridische entiteit” ondubbelzinnig aan te duiden over grenzen en over systemen heen, omdat bedrijfsnamen niet uniek zijn, transliteraties verschillen, en registratienummers nationaal zijn. De LEI vervult die behoefte: één entiteit, één identificatie, overal bruikbaar.

Wat hij niet is, is een vergunning, een permit, een kredietbeoordeling of een verklaring van goede staat. Een entiteit met een LEI kan slapend zijn, in liquidatie of allang doorgehaald; de identificatie legt vast wie ze is, niet hoe het met haar gaat.

Wat is een DUNS-nummer?

Een DUNS-nummer is een bedrijfsidentificatie die door een particulier kredietinformatiebureau wordt uitgegeven. Het bestaat uit negen cijfers en is gebouwd op een grote eigen database van bedrijven, samengesteld uit openbare deponeringen, handelsreferenties en zelfgerapporteerde informatie.

Zijn natuurlijke habitat is inkoop en toeleveringsketens. Grote kopers, overheidsinkoopsystemen en bedrijfsportalen voor leveranciersonboarding vragen erom omdat het hen een stabiele sleutel geeft voor een leverancier die in verschillende systemen op verschillende manieren kan worden beschreven. Het is handig en breed begrepen in die kringen.

Twee eigenschappen verdienen de nadruk. Ten eerste is het geen internationale standaard en wordt het niet door een overheidsinstantie beheerd; het behoort toe aan het bureau dat het uitgeeft. Ten tweede zijn de gegevens commercieel, dus de nauwkeurigheid van een bepaald record hangt af van het eigen onderhoud van dat bureau en van wat bedrijven het hebben verteld — het is geen register van oprichting en heeft op zichzelf geen rechtskracht.

Waar komen deze identificaties voor?

Beide typen komen voor op plaatsen waar een bedrijf aan een derde wordt beschreven en een naam alleen niet precies genoeg is.

Die laatste rij is de bron van heel wat verwarring. Een formulier dat vraagt om een “bedrijfsidentificatie” zonder er een te benoemen, stelt een vraag met meerdere juiste antwoorden, en het zal een mengeling van registratienummers, fiscale nummers, LEI’s en DUNS-nummers verzamelen tenzij het veld benoemt wat het wil.

Is een LEI-code hetzelfde als een fiscaal nummer?

Nee, en het onderscheid is de moeite waard om precies te stellen omdat de twee zo vaak worden samengegooid.

Een fiscaal nummer — een fiscale identificatie of een btw-nummer — wordt uitgegeven door een belastingdienst voor de belastingadministratie. Een LEI wordt uitgegeven onder een standaard voor financiële markten zodat juridische entiteiten consistent over systemen heen kunnen worden geïdentificeerd. Een DUNS-nummer wordt uitgegeven door een commerciële dataleverancier voor zijn eigen matchingdoeleinden. Drie verschillende uitgevers, drie verschillende doelen, en geen enkele overlap in betekenis.

Eén praktisch gevolg: het bezit van een van deze vertelt je niets over de andere. Een bedrijf kan een LEI en geen btw-nummer hebben, of een btw-nummer en geen LEI, en geen van beide situaties is ongewoon. Een formulier dat ze allemaal tegelijk vereist, legt een eis op die niet elk legitiem bedrijf kan vervullen, dus het moet kunnen zeggen waarom het elk afzonderlijk nodig heeft.

Wat bewijst het bezit van een van beide werkelijk?

Het bewijst identificatie, en alleen identificatie. Dit is het belangrijkste om je eigen te maken, want de verleiding om meer in deze identificaties te lezen is groot.

Een LEI-record bevestigt dat de entiteit bekend is bij het wereldwijde systeem en dat er een referentierecord bestaat. Het bevestigt niet dat de entiteit solvent, gelicentieerd, compliant of bevoegd is om te doen wat ze beweert. Een DUNS-record bevestigt dat het bureau een record voor het bedrijf heeft. Het bevestigt niet dat het bedrijf is opgericht, en het ontbreken van een DUNS-nummer betekent zeker niet dat een bedrijf onrechtmatig is — tal van volstrekt echte bedrijven verkrijgen er nooit een.

Beide kun je het beste als joinsleutels behandelen. Ze helpen je de versie van een bedrijf in het ene systeem te matchen met de versie van hetzelfde bedrijf in een ander systeem. Verificatie van een bedrijf is een aparte activiteit, uitgevoerd tegen het bedrijvenregister van het land van oprichting en, waar de fiscale status ertoe doet, tegen de officiële opzoekservice van de betrokken belastingdienst.

Voor ontwikkelaars: externe identificaties opslaan en controleren

Sla elke identificatie op in een eigen veld, met een eigen label en een eigen validator, en nooit achter één generieke kolom “bedrijfsidentificatie”. Velden met gemengde typen zijn onmogelijk te valideren, lastig te indexeren en zullen zeker rommel verzamelen.

Behandel voor de LEI de waarde als een alfanumerieke string in hoofdletters met vaste breedte, en implementeer de gepubliceerde controlecijferregel als je een lokale gezondheidscontrole nodig hebt — die vangt transcriptiefouten goedkoop op. Behandel voor het DUNS-nummer de waarde als een string van cijfers met een belangrijke kanttekening: er is geen controlecijferalgoritme dat je lokaal kunt berekenen, dus een lokale controle kan de vorm bevestigen en niets meer. Sla geen van beide op in een kolom met gehele getallen, en neem nooit aan dat een string van negen cijfers een DUNS-nummer is alleen omdat hij negen cijfers lang is.

Behandel de opzoekdiensten die deze identificaties oplossen als externe afhankelijkheden met de gebruikelijke zorg. Geef ze een time-out, behandel een niet-beschikbare service als een onbekend resultaat in plaats van een fout, en cache geslaagde opzoekingen voor een redelijke periode terwijl je negatieven veel korter cachet. Log het feit dat er een opzoeking plaatsvond, en behandel de payload als bedrijfsgegevens.

Twee veiligheidsgewoonten zijn belangrijk in testomgevingen. Ten eerste: test niet met echte identificaties: een gegenereerde waarde is genoeg om het veld te beproeven, en de generator op deze site vult de identificatievelden met synthetische waarden die tot niets leiden. Ten tweede: behandel deze identificaties nooit als autorisatie. Een opzoeking die een record teruggeeft is geen toestemming, en code die toegang verleent op grond van een overeenkomende identificatie is een veiligheidsdefect, geen gemak. Het artikel over fiscale identificaties behandelt dezelfde gelaagdheid voor fiscale nummers, en testbedrijfsgegevens laat zien waar deze velden in een volledig synthetisch record staan.

Volgende stappen

Kijk hoe je product om bedrijfsidentificaties vraagt en tel hoeveel betekenissen die vraag op dit moment heeft. Als één veld een registratienummer, een btw-nummer en een LEI kan ontvangen, splits het dan in benoemde velden en valideer elk alleen op zijn eigen vorm. Genereer dan een synthetische entiteit in de generator voor bedrijfsgegevens en bevestig dat je formulieren, exports en logs allemaal de identificatie labelen die ze tonen.