An LEI code is a globally recognised identifier for a legal entity, issued under an international standard and published so that anyone can look it up. A DUNS number is a different thing entirely: a company identifier maintained by a private commercial data business and widely used in procurement and supply-chain work. Both turn up in the same forms, both are quoted in contracts, and both are routinely confused with tax numbers.
This article sets out what each one is, where it is used, how they differ, and what neither of them proves about the business behind it.
What is an LEI code?
The Legal Entity Identifier is defined by the international standard ISO 17442 and consists of 20 alphanumeric characters, of which one is a check digit. It is issued through a public global system of accredited local operating units, and the resulting records are published and free to look up: the identifier is tied to reference data about the entity, such as its registered name and address.
The purpose is narrow and useful. Financial markets and regulators needed a way to say “this exact legal entity” unambiguously across borders and across systems, because company names are not unique, transliterations differ, and registration numbers are national. The LEI answers that need: one entity, one identifier, usable everywhere.
What it is not is a licence, a permit, a credit rating or a statement of good standing. An entity with an LEI may be dormant, in liquidation or long since struck off; the identifier records who it is, not how it is doing.
What is a DUNS number?
A DUNS number is a company identifier issued by a private credit-information agency. It consists of nine digits and is built on a large proprietary database of businesses, assembled from public filings, trade references and self-reported information.
Its natural habitat is procurement and supply chains. Large buyers, government purchasing systems and enterprise vendor-onboarding portals ask for it because it gives them a stable key for a supplier that may be described in several different ways across systems. It is convenient and widely understood in those circles.
Two properties deserve emphasis. First, it is not an international standard and is not managed by a public authority; it belongs to the agency that issues it. Second, its data is commercial, so the accuracy of a particular record depends on that agency’s own maintenance and on what businesses have told it — it is not a register of incorporation and carries no legal force of its own.
Where do these identifiers show up?
Both types appear in places where a business is being described to a third party and a name alone is not precise enough.
| Context | Which identifier tends to appear |
|---|---|
| Cross-border financial transactions and reporting | LEI |
| Corporate treasury and group structures | LEI |
| Government and enterprise procurement portals | DUNS |
| Supplier onboarding and vendor master data | DUNS, sometimes alongside an LEI |
| Credit assessment workflows | Either, used as a matching key rather than as evidence |
| Company forms asking for “your business identifier” | Whichever the form’s builder assumed, often neither |
That last row is the source of a great deal of confusion. A form that asks for a “business identifier” without naming one is asking a question with several right answers, and it will collect a mixture of registration numbers, tax numbers, LEIs and DUNS numbers unless the field names what it wants.
Is an LEI code the same as a tax number?
No, and the distinction is worth stating precisely because the two are so often conflated.
A tax number — a tax identifier or a VAT number — is issued by a tax authority for tax administration. An LEI is issued under a financial-markets standard so that legal entities can be identified consistently across systems. A DUNS number is issued by a commercial data provider for its own matching purposes. Three different issuers, three different purposes, and no overlap in meaning.
One practical consequence: holding any of them tells you nothing about the others. A business can hold an LEI and no VAT number, or a VAT number and no LEI, and neither state is unusual. A form that requires all of them at once is imposing a requirement that not every legitimate business can satisfy, so it should be able to say why it needs each one.
What does holding one actually prove?
It proves identification, and identification only. This is the single most important thing to internalise, because the temptation to read more into these identifiers is strong.
An LEI record confirms that the entity is known to the global system and that a reference record exists. It does not confirm that the entity is solvent, licensed, compliant, or authorised to do what it claims. A DUNS record confirms that the agency holds a record for the business. It does not confirm that the business is incorporated, and the absence of a DUNS number certainly does not mean a business is illegitimate — plenty of entirely real companies never obtain one.
Both are best treated as join keys. They help you match one system’s version of a business to another system’s version of the same business. Verification of a business is a separate activity, carried out against the company register of its country of incorporation and, where tax status matters, against the relevant tax authority’s official enquiry service.
For developers: storing and checking external identifiers
Store each identifier in its own field, with its own label and its own validator, and never behind a single generic “business identifier” column. Mixed-type fields are impossible to validate, awkward to index and certain to collect junk.
For the LEI, treat the value as an uppercase alphanumeric string of fixed width, and implement the published check-digit rule if you need a local sanity check — it catches transcription errors cheaply. For the DUNS number, treat the value as a string of digits with an important caveat: there is no check-digit algorithm you can compute locally, so a local check can confirm shape and nothing more. Never store either in an integer column, and never assume a nine-digit string is a DUNS number just because it is nine digits long.
Treat the lookup services that resolve these identifiers as external dependencies with the usual care. Give them a timeout, treat an unavailable service as an unknown result rather than a failure, and cache successful lookups for a reasonable period while caching negatives for much less. Log the fact that a lookup happened, and treat the payload as business data.
Two safety habits matter in test environments. First, do not test with real identifiers: a generated value is enough to exercise the field, and the generator on this site fills the identifier fields with synthetic values that resolve to nothing. Second, never treat these identifiers as authorisation. A lookup that returns a record is not a permission, and code that grants access on the strength of a matching identifier is a security defect, not a convenience. The tax identifier article covers the same layering for tax numbers, and test company data shows where these fields sit in a full synthetic record.
Next steps
Look at how your product asks for business identifiers and count how many meanings that question currently has. If one field can receive a registration number, a VAT number and an LEI, split it into named fields and validate each one for its own shape only. Then generate a synthetic entity in the company data generator and confirm your forms, exports and logs all label the identifier they are showing.