Europe Standardised the Invoice, Not the Address

An electronic invoice can meet every requirement of the European standard and still have nowhere to go.

EN 16931 sits underneath almost every e-invoicing mandate in Europe. It fixes what an invoice must contain, how those contents relate to each other, and which two syntaxes may carry them. What it does not fix is where the finished document should be sent. The European Commission's documentation for the code list governing that field states the position without ceremony: the seller and buyer electronic address fields "are optional fields but require scheme identification when used."¹

Conformance governs the document. Delivery governs the address. Only the first of those was standardised, and the gap has been filled nine separate times by nine separate authorities, each reaching for a different number issued by a different kind of institution.

The result is a continent where the invoice format converged and the address book did not. A company selling into Belgium, Poland, Italy and France holds four routing identifiers issued by a business registry, a tax administration, a channel subscription register and a statistical office. None of the four reconcile with each other. Nothing above them reconciles them either.

What the standard leaves out

EN 16931 is a semantic data model rather than a transport protocol. It defines business terms and binds them to two permitted syntaxes, UBL 2.1 and UN/CEFACT Cross Industry Invoice. Compliance means the document carries the right information in the right structure. It carries no obligation about how that document reaches a counterparty.

Two business terms cover the electronic address. BT-34 holds the seller's, BT-49 holds the buyer's. Each pairs an identifier value with a scheme identifier declaring which register that value came from, and both sit in the standard as optional.¹

Every network that actually has to move invoices corrected this. Peppol BIS Billing 3.0, itself a restriction of EN 16931, requires the endpoint and states the rule directly: "schemeID attribute is mandatory for electronic addresses, ie. EndpointID."² Peppol validation rule BR-63 exists for the single purpose of rejecting a buyer electronic address that arrives without a scheme identifier.³ XRechnung, the German national restriction of the same standard, likewise raises the buyer electronic address from optional to mandatory.⁴

Two implementations, working independently, made the same correction to the same omission. That is a reasonable definition of a defect in the underlying specification.

The address namespace is a separate, moving artefact

An identifier without a namespace is an unattributed string of digits. A ten-digit number could be a Belgian enterprise number, a Polish tax number, or neither, and a receiving system has no way to tell from the value alone. The scheme identifier resolves this: a four-digit code drawn from a subset of the ISO 6523 International Code Designator list, plus Peppol's own extensions in the 9900 range.⁵

Maintenance of those lists sits outside the standard. The Electronic Address Scheme list is defined and maintained by the DIGITAL programme, successor to the Connecting Europe Facility since January 2022, precisely because the European standard "left undefined" what the field should contain.¹ Peppol maintains its own participant identifier scheme list on a separate cadence. Version 9.7, published on 2 July 2026, holds 105 entries: 82 active, 5 deprecated, and 16 removed.⁵

A list that has already retired sixteen schemes is not a stable foundation for addressing. It is a registry of registries, versioned independently of the standard that depends on it, and an integration written against version 8 can find its counterparty's namespace deprecated by version 9.

Resolution itself is mechanical. OpenPeppol operates the Service Metadata Locator as a central DNS-based registry that points at Service Metadata Publishers, and each publisher declares what a given participant can receive.⁵ The lookup is fast and reliable. It also asks no question about whether the identifier presented belongs to the company named on the invoice.

Nine answers to one question

Every mandate that had to deliver an invoice chose an identifier. No two chose the same kind of number, and more consequentially, no two chose the same kind of issuing institution.

Belgium routes on a business registry number. Poland and Romania route on tax numbers. France routes on a number issued by the national statistical office and resolved through a directory operated by the tax administration. Italy routes on a code tied to a transmission channel rather than to a company at all. Germany's public sector routes on a code issued by a body that is neither a registry nor a tax authority, but an IT standards coordinator.

Read down the final column and the problem stops looking like a technical detail. The same functional field is populated from five categories of institution that have no shared governance, no common update cycle, and no mechanism for telling each other when an entity changes. A business already holds a commercial register number, a tax number, a statistical number and a VAT number. European e-invoicing has now added a routing identifier to that stack in most markets, and in several of them the routing identifier is a repurposed copy of one of the existing four.

Repurposing is not free. A number that was issued to identify a legal entity for one administrative purpose now also determines whether a document arrives. Those two functions age differently. A company that restructures keeps its obligations to the tax authority current because the penalty is immediate, while its network registration can sit stale for months because nothing forces an update.

France shows that the ambiguity does not require a border to appear. From 1 September 2026 the customer's SIREN becomes a mandatory field on the invoice and doubles as the routing address, resolved through a central directory that the tax administration populates automatically for every VAT-registered business in the country, roughly 4.5 million of them, without any action on the business's part.⁶ A recipient may then set its routing at any of three levels: the SIREN of the legal entity, the SIRET of a specific establishment, or an internal code of its own choosing.⁶

Three valid answers for one company is a reasonable design decision for a large group that wants invoices landing at the right subsidiary. It is also three things a sender has to get right, in a directory that will hold millions of entries within weeks of the obligation starting, with no external signal about which level any given counterparty selected.

Germany put the routing key in the wrong field

Germany's public-sector routing identifier does not live in the address field at all.

The Leitweg-ID is a hierarchical administrative address. The first two digits give the federal state, 01 through 16, or 99 for the federation. Subsequent digits narrow to district, county and municipality, followed by an alphanumeric segment of up to 30 characters, closed by a two-digit checksum.⁷ It describes a position within the German state apparatus. It does not identify a legal entity, and it was never intended to.

That value is carried in BT-10, the buyer reference.⁸ Peppol BIS Billing 3.0 treats BT-10 as conditional: "The buyer reference, known as Your ref, is conditional. An invoice shall have either the buyer reference or the order reference."² Germany took a conditional free-text field, semantically equivalent to "your ref", and made it a hard delivery dependency. An invoice to a German public buyer without a valid Leitweg-ID cannot be routed and is rejected.⁸

KoSIT then registered ICD 0204 so the same value can serve as a Peppol participant identifier when the invoice travels over that network.⁸ One string now does duty as both a semantic field inside the document and a network address outside it.

Set against that precision, Germany's private sector has no addressing requirement whatsoever. The B2B obligation, phased in by the Growth Opportunities Act of 23 March 2024, requires businesses to receive structured invoices from 1 January 2025, to issue them from 1 January 2027 above EUR 800,000 annual turnover, and from 1 January 2028 in all cases.⁹ It prescribes the format and says nothing about the channel. Upload, web forms, email, De-Mail and Peppol are all acceptable routes.⁹

Reject, fall back, or vanish

What happens to a misaddressed invoice depends on the architecture carrying it, and the outcomes are not symmetrical.

Germany's public sector fails loudly. An invalid Leitweg-ID produces a rejection and the sender finds out at once.⁸

Italy fails quietly by design. Where no Codice Destinatario is supplied, the reserved seven-character value 0000000 sends the Sistema di Interscambio to the recipient's registered certified email address, or deposits the document in their reserved area on the Agenzia delle Entrate portal. Invoices to foreign counterparties carry the reserved value XXXXXXX.¹⁰ The document is not lost. Delivery simply becomes a pull rather than a push, and a recipient who does not check the portal does not know it is waiting.

Poland removes the delivery question from the system entirely. The buyer identifier on a KSeF invoice is a tax number rather than an address: NIP for domestic buyers, a VAT-UE number with country prefix for buyers elsewhere in the EU, and a BrakID flag where the buyer has neither.¹¹ A German or Swiss counterparty holds no Polish NIP and cannot log in to retrieve anything. The Ministry of Finance resolves this outside the system, instructing sellers to pass the document to the buyer "in an agreed manner, for example as a PDF, by email, or even on paper if that is what they agree", with a QR code so the recipient can confirm the invoice exists in KSeF without holding an account.¹¹ A clearing model routes to the state, and the state is not the counterparty.

The reverse direction closes the loop. The Ministry of Finance has confirmed that KSeF is not used at all for cost invoices received from foreign suppliers without a Polish establishment.¹¹ A Polish importer buying from a German supplier therefore books a document that never touches the national system, using whatever format the supplier sent, while the same importer's outbound sales invoices to that same supplier must clear KSeF first. One trading relationship, two architectures, no shared identifier between them.

Peppol carries the failure mode with no alarm attached. An unregistered participant identifier fails at lookup and the sender is notified. An identifier that is valid but belongs to a different company delivers successfully, to that different company. Nothing in the four-corner chain verifies that the address presented matches the legal entity named on the invoice, because that was never the chain's job.

Belgium counts addresses, not companies

Belgium made Peppol compulsory for domestic business-to-business invoicing on 1 January 2026, under a law of 6 February 2024 amending the VAT code, with penalties held back until 31 March 2026.¹² The mandate names the network, names the syntax as Peppol BIS Billing 3.0, and names the identifier: scheme 0208, the enterprise number from the Crossroads Bank for Enterprises.¹³ It is the most complete national addressing mandate in Europe.

Belgium has 1,202,139 VAT-registered enterprises, measured by its own statistical office in December 2025.¹⁴

Belgian participants registered on the Peppol network numbered 940,354 that same month. By June 2026 the figure was 2,111,684.¹⁵

That works out at roughly 1.76 registered routing addresses for every business the mandate covers. The source publishing the participant figures explains the arithmetic without being asked.

Many Belgian businesses are registered under both the KBO/CBE enterprise number (scheme 0208) and their VAT number (scheme 9925). That means the directory often counts the same company twice or more.

Bulk registration compounds it, with banks and accounting platforms enrolling entire client bases at once.¹⁵ The consequence is that the headline adoption statistic for Europe's most thoroughly mandated e-invoicing market counts addresses rather than organisations, and the two numbers have diverged by three-quarters of a million.

The operational reading matters more than the counting error. A sender resolving a Belgian counterparty may find two valid, simultaneously routable addresses for one company, under two different scheme codes, issued by two different authorities. Both deliver. Neither is marked canonical. The network has no opinion on which is correct because correctness of that kind was never something it was built to assess.

Identifier fragmentation was the condition the mandate was meant to end. Eighteen months of compulsory adoption reproduced it one layer higher, in a namespace that did not exist before.

What the standard settled and what it did not

One standard now governs what a European invoice says. Nine authorities separately decided where it goes.

The norm left the recipient's address optional. The networks that carry real traffic re-mandated it. The national mandates each picked a different issuing institution, from business registries to tax administrations to statistical offices to a public-sector IT standards body. The namespace those identifiers live in is maintained outside the standard and has already retired sixteen schemes. The most-mandated market in Europe now reports more routing addresses than it has businesses, and nobody publishes a failure rate for any of it.

None of this stops invoices moving. Most of them arrive. The cost lands somewhere less visible: on whoever has to establish that the entity at the far end of a participant identifier is the entity named on the document, across systems that were each designed to answer a national question and none of which were designed to answer that one.

The standard answered the easier question. The harder one was left with whoever is holding the invoice.

Footnotes

1. European Commission, Digital Building Blocks – Electronic Address Scheme (EAS) code list. https://ec.europa.eu/digital-building-blocks/sites/x/XYTXGw – accessed 15 August 2026. ↩ ↩² ↩³

2. OpenPeppol – Peppol BIS Billing 3.0. https://docs.peppol.eu/poacc/billing/3.0/bis/ – accessed 15 August 2026. ↩ ↩²

3. OpenPeppol – business rule BR-63, "The Buyer electronic address (BT-49) shall have a Scheme identifier." https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-63/ – accessed 15 August 2026. ↩

4. XRechnung field reference, BT-49 Buyer Electronic Address. https://www.invoice-converter.com/en/resources/xrechnung/bt-49-buyer-electronic-address – accessed 15 August 2026. ↩

5. OpenPeppol – Peppol Code Lists, Participant identifier schemes v9.7, published 2 July 2026. https://docs.peppol.eu/edelivery/codelists/ – accessed 15 August 2026. ↩ ↩² ↩³

6. Ministère de l'Économie et des Finances – Facturation électronique : ouverture de l'annuaire dédié. https://www.economie.gouv.fr – accessed 15 August 2026. Calendar and directory scope corroborated by BDO, France: Mandatory e-invoicing to be implemented in 2026. https://www.bdo.global – accessed 15 August 2026. ↩ ↩²

7. KoSIT – Leitweg-ID Formatspezifikation, version 2.0.2, 28 July 2021. https://leitweg-id.de – accessed 15 August 2026. ↩

8. E-Rechnung in der Bundesverwaltung – Buyer reference (Leitweg-ID). https://e-rechnung-bund.de – accessed 15 August 2026. ↩ ↩² ↩³ ↩⁴

9. European Commission, Digital Building Blocks – eInvoicing in Germany. https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108886/eInvoicing+in+Germany – accessed 15 August 2026. ↩ ↩²

10. ecosio – E-invoicing compliance in Italy. https://ecosio.com/en/compliance/italy/e-invoicing/ – accessed 15 August 2026. ↩

11. Ministerstwo Finansów – Pytania i odpowiedzi KSeF 2.0. https://ksef.podatki.gov.pl/pytania-i-odpowiedzi-ksef-20/ – accessed 15 August 2026. Original wording: "Sprzedawca musi przekazać mu dokument w uzgodniony sposób – np. w formie PDF, mailowo, albo nawet papierowo, jeśli tak się umówią." ↩ ↩² ↩³

12. Loyens & Loeff – E-invoicing in Belgium as from 1 January 2026: key provisions of the royal decree. https://www.loyensloeff.com – accessed 15 August 2026. ↩

13. European Commission, Digital Building Blocks – eInvoicing in Belgium. https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108877/eInvoicing+in+Belgium – accessed 15 August 2026. ↩

14. Statbel – Statistics on the number of VAT units (monthly), December 2025. https://statbel.fgov.be/en/themes/enterprises/vat-registered-businesses/statistics-number-vat-units-monthly – accessed 15 August 2026. ↩

15. e-invoice.be – Peppol statistics, June 2026 snapshot. https://e-invoice.be – accessed 15 August 2026. Participant counts are derived from the Peppol Directory, which does not list every recipient on the network. ↩ ↩²