What it is
The D-U-N-S Number (Data Universal Numbering System, almost always written "DUNS") is a nine-digit numeric identifier assigned and maintained by Dun & Bradstreet (D&B). Each number identifies a single business entity at a single physical location; a company operating from several sites can therefore hold several DUNS Numbers, with D&B's corporate-linkage data describing the parent/branch relationships between them. The scheme has been in use since 1962 and is one of the most widely recognised commercial business identifiers in the world, heavily used in supply-chain, procurement, and credit-reporting systems — including by the US federal government for decades.
The number is purely a key: it carries no embedded meaning, and the once-customary trailing check digit is no longer maintained by D&B, so a DUNS Number cannot be self-validated the way an IBAN, a VAT number, or an ISO 17442 LEI can. Verification means looking the number up against D&B's registry rather than computing a checksum.
Why it matters for e-invoicing
To deliver an EN 16931 invoice across an open network such as Peppol, the buyer and seller must be identified by a coded scheme — a value plus a scheme identifier drawn from the ISO/IEC 6523 ICD (International Code Designator) registry, surfaced in e-invoicing through the Peppol Electronic Address Scheme (EAS) code list (EN 16931 code list ICD/EAS). The DUNS Number sits in that registry under code 0060 ("DUNS Number Dun & Bradstreet"). That makes it a legitimate value for a Peppol participant identifier and for the electronic-address business terms BT-34 (seller) and BT-49 (buyer): a participant may register on Peppol as 0060:123456789 and be routed on that basis.
In practice, EU public-sector e-invoicing flows overwhelmingly route on VAT numbers, national company numbers, the GLN, or country-specific schemes, and the DUNS Number is comparatively rare as a routing address inside the EU. It is most likely to surface when a counterparty is a multinational or a US-headquartered supplier whose master data is keyed on DUNS, or in legacy EDI integrations that predate Peppol. For an ERP vendor the relevance is therefore defensive: you must recognise 0060 as a valid scheme rather than rejecting it as unknown, and you must not assume every participant identifier is a VAT number.
How ERP vendors encounter it
Three integration touchpoints recur:
1. As an electronic address (BT-34 / BT-49). The endpoint carries schemeID="0060" and the nine-digit DUNS Number as the value. Treating 0060 as "unknown scheme" is a common, avoidable cause of misrouted or rejected invoices.
2. As a buyer/seller identifier (BT-46 / BT-29). Some trading-partner master-data records identify a party by DUNS even when routing happens on another scheme; your mapping must keep the two roles distinct.
3. In validation. Because there is no check-digit algorithm, a pipeline can only range-check the format (nine digits, numeric) and, where higher assurance is needed, confirm existence against D&B. This is a meaningful difference from the LEI, which a validator can check offline via its ISO 7064 digits.
Relation to EN 16931
EN 16931 is scheme-agnostic: it does not prescribe which identifier a party must use, only that identified parties carry a value together with a scheme identifier from the agreed code lists. The DUNS Number is simply one permitted ICD/EAS value (0060) alongside the GLN (0088), the LEI (0199), and the many national schemes. The vendor's job is not to prefer the DUNS Number but to accept and route it correctly when a counterparty has registered it — and to understand that, unlike a VAT identifier, it tells you nothing about the party's tax status and cannot stand in for BT-31/BT-48 VAT identifiers.