E-invoicing recipient address: why finding your customer differs by country — and what it means for your business
You have prepared an e-invoice. The data is correct, the format is compliant, and your system is ready to send. Then comes the question that catches more businesses off guard than any technical specification: what do you enter as the e-invoicing recipient address?
Depending on where your customer is located, the answer might be a VAT number, a national company registration number, a Peppol Participant ID, a platform-specific code, or a combination of these. The tools available to find that address vary enormously by country. And the honest answer you will find in many support guides — “ask your customer directly” — is correct, but it is not a scalable process for any business that invoices internationally with any regularity.
This article unpacks why finding the right e-invoicing recipient address is a genuine challenge, why it differs by country, and what it means when you select an e-invoicing solution.
Three layers, three challenges
Correctly addressing an e-invoice to a new international recipient involves three distinct layers, each with its own complexity.
The first is the registration layer: where are businesses registered, and is that data available in a machine-readable way? The second is the lookup layer: how do you connect a company name to a fiscal identifier? The third is the addressing layer: how do you translate that identifier into a valid e-invoicing recipient address within the applicable system?
Each layer has its own fragmentation. Platforms that solve this well address one or two layers effectively. Rarely all three, and rarely consistently across borders.
Layer 1: The registration layer
Every lookup starts with a business registry. But these registries differ fundamentally by country — in governance, in accessibility, and in how machine-readable their data actually is. A lookup chain that works in one country may have no technical foundation in another.
Europe
The UK’s Companies House is an executive agency of the British government. It offers a fully open, free application programming interface (API) searchable by company name in real time. This reflects a deliberate policy choice: data only has value when it is used.
The Netherlands’ Kamer van Koophandel (KvK) is a government organisation. An API is available, but access is restricted to entities registered in the Netherlands. Foreign parties that need access to Dutch business data must work through recognised brokers rather than the API directly.
Belgium’s Crossroads Bank for Enterprises (KBO/BCE), where BCE stands for Banque-Carrefour des Entreprises in French, is a government registry offering API access on a paid basis.
Germany’s Handelsregister operates as a federated system managed at state level by individual courts. No central API exists.
Asia-Pacific
Australia operates two parallel systems. The Australian Business Register (ABR) maintains ABN Lookup, a free public web service for validation and lookup by Australian Business Number (ABN). The Australian Securities and Investments Commission (ASIC) manages the company register, searchable by company name or Australian Company Number (ACN), with basic information available free of charge and more detailed extracts on a paid basis. Neither offers the same fully open API model as the UK’s Companies House.
Africa
Nigeria’s Corporate Affairs Commission (CAC) maintains a public search portal searchable by company name or Registration Certificate number (RC number). The CAC does not offer a direct official machine-readable API. Access to CAC data for software integration is provided through third-party verification providers that wrap the underlying registry data — an unofficial but functioning market solution.
Latin America
Colombia’s Registro Único Empresarial y Social (RUES), managed by the chambers of commerce, provides free access to basic business registration data, supports comma-separated value (CSV) and plain text (TXT) downloads, and is searchable by company name.
Mexico’s Servicio de Administración Tributaria (SAT) allows validation of the Registro Federal de Contribuyentes (RFC) — Mexico’s tax identifier — but only by entering the RFC directly, one at a time, with a CAPTCHA verification step. Searching by company name to retrieve an RFC is not supported through the official portal. The SAT is primarily a tax authority, not a searchable business registry in the way European or Australian registries operate.
Middle East
The United Arab Emirates (UAE) does not have a single unified business registry. Mainland companies register with the Department of Economic Development (DED) at the emirate level, while dozens of free zones each maintain their own separate registries. There is no central, cross-registry searchable database.
North America
The United States has no mandatory federal business registry. Company registration takes place at the state level, resulting in fifty separate systems with varying levels of digital accessibility. The Digital Business Networks Alliance (DBNAlliance) operates the US e-invoicing exchange network, with addressability based on identifiers such as Employer Identification Number (EIN), Data Universal Numbering System (DUNS) number, and Global Location Number (GLN) — but these are not derived from a single public registry.
The pattern
The contrast is clear. Some countries have made their registries openly accessible as public infrastructure. Others restrict access by nationality or charge for it. Several have no machine-readable central access at all. The further from Europe, the more fragmented the picture becomes. Any lookup chain that an e-invoicing platform builds for one market must be rebuilt — often from scratch — for the next.
Layer 2: The lookup layer
Where layer 1 permits it, platforms can build a lookup chain: company name to registration number to fiscal identifier. The best e-invoicing solutions already do this today, combining a registry API with a Peppol Service Metadata Publisher (SMP) lookup so that a user can search by name while the system resolves the correct e-invoicing recipient address under the surface.
This works well, but only when three conditions are met. The registry must offer machine-readable access. The recipient must already be registered on the network. And the sender and recipient must sit within the same registry ecosystem.
Cross-border breaks the chain. A Dutch supplier looking up a Belgian customer needs a KBO/BCE integration, not a KvK integration. A German counterpart has no central API to query. An Australian or Nigerian recipient follows a different identifier logic entirely.
Europe does have a cross-border information infrastructure that connects all 27 member states and covers millions of registered businesses. It is called the VAT Information Exchange System (VIES), operated by the European Commission. And it is precisely here that the gap between potential and reality is most visible. VIES validates VAT numbers but does not allow searching by company name — and that is the central limitation: this infrastructure cannot answer the most basic lookup question a supplier faces — who is this company, and what is their identifier? The potential is there. The access is not.
This is a deliberate privacy decision, not a technical one. Some member states, including Germany and Spain, do not even return name information when a valid number is confirmed. The argument for caution is legitimate: open name-based lookup at scale creates risks of data harvesting and misuse. But the current restriction is a blunt instrument. Technically, controlled access is achievable — through API keys requiring authenticated registration, strict purpose limitation to invoice-related queries, rate limiting to prevent bulk extraction, and audit logging of all requests. These are mechanisms already in use in other European business registries, and they are fully compatible with the General Data Protection Regulation (GDPR).
Unlocking even a limited form of name-based lookup in VIES would require a policy change at European level. The legal basis is the EU VAT Directive (2006/112/EC), which governs what data member states share through VIES. Any structural change requires a legislative proposal from the European Commission, followed by agreement between the Council of the EU — representing member states — and the European Parliament. The European Data Protection Supervisor (EDPS) would need to be involved in any privacy impact assessment. This is not a quick process. But it is a tractable one, and it is worth naming as an explicit policy objective — particularly in the context of the VAT in the Digital Age (ViDA) reform agenda already underway.
Layer 3: The addressing layer per e-invoicing regime
Even with the correct fiscal identifier in hand, translating it into a valid e-invoicing recipient address is not automatic. The answer depends on the e-invoicing regime in force in the recipient’s country.
Peppol countries: Belgium, Netherlands, Australia, Nigeria
In Peppol countries, the Peppol Participant ID consists of a scheme code combined with an identifier. The scheme differs by country: the Netherlands uses the KvK number, Belgium uses the KBO/BCE enterprise number, other countries use GLN or DUNS.
Peppol has auto-discovery functionality, through its Service Metadata Locator (SML) and SMP. When a Peppol Access Point sends a document, it queries the SML to find which SMP holds information about the recipient, then retrieves the technical endpoint from that SMP. This routing process is automated and happens in milliseconds.
The critical nuance is that the SML/SMP resolves the routing question, not the discovery question. You already need the recipient’s Peppol Participant ID to initiate the lookup. If you only have a company name, the technical infrastructure does not help you from that starting point.
The Peppol Directory offers a human-readable search interface, but publication of a Business Card in the Directory is voluntary at the OpenPeppol level. A business can be fully reachable on the Peppol network without appearing in the Directory. In the Netherlands, broad adoption of this discoverability function has not materialised. The result is that a supplier wanting to know whether a customer is reachable via Peppol has no reliable central source to consult.
United States: DBNAlliance
The US has no government mandate for e-invoicing. The DBNAlliance, a nonprofit established by the Business Payments Coalition and the Federal Reserve, operates an open exchange network for B2B e-invoicing based on a four-corner model. American business identifiers such as EIN, DUNS, and GLN are used for addressing. Adoption is voluntary and growing. Businesses not connected to the network are not reachable through it, and there is no central directory to verify connectivity before attempting to send.
Clearance countries: Mexico, Colombia
In clearance countries, the tax authority sits at the centre of every transaction. Mexico’s SAT and Colombia’s Dirección de Impuestos y Aduanas Nacionales (DIAN) validate invoices before they reach the recipient. But the supplier must still provide the correct fiscal identifier of the recipient to submit the invoice correctly to the platform. The clearance regime ensures compliance, not lookup.
France: the Annuaire as routing infrastructure
France is instructive as a counterpoint to the general pattern. The Portail Public de Facturation (PPF) manages a central registry called the Annuaire, which records which certified Plateforme Agréée (PA) each French company uses to receive e-invoices. Companies are identified by their SIREN number — France’s national company identifier. The Annuaire is publicly accessible and continuously updated.
This means that once you have the SIREN number of a French recipient, you can determine where to route the invoice without needing to contact the customer. France has built routing transparency into its public infrastructure. The Direction Générale des Finances Publiques (DGFiP) became the French Peppol Authority in 2025, and Peppol connectivity between certified platforms is required, meaning Peppol serves as the interoperability layer between platforms.
UAE
The UAE is implementing e-invoicing on the basis of a Peppol five-corner model, with the government as the fifth corner. Whether a central routing directory comparable to the French Annuaire will be established has not yet been confirmed in published specifications.
What does exist, and where it stops
It would be inaccurate to suggest that no solutions exist for the addressing challenge. A number of international compliance providers have built robust systems that support multiple countries, multiple e-invoicing regimes, and multiple identifier types. These solutions address all three layers described above, and they do so effectively.
Their positioning is enterprise. The pricing model, implementation trajectory, and contract structure are designed for large organisations with high transaction volumes and dedicated finance operations teams. For smaller and mid-sized businesses invoicing internationally across a limited number of countries, these are not realistic options.
The market for smaller businesses consists of a large number of providers, each strong in a limited set of countries, each with their own lookup logic. This is not accidental. The fragmentation of registries, regimes, and identifiers makes broad coverage at low cost structurally difficult. Providers are not failing to build a universal solution out of lack of ambition. The underlying infrastructure simply does not support it.
The market dynamics behind the gap
To understand why this gap persists, it helps to look at the economic logic that underlies different e-invoicing network models.
In a three-corner model, a single Business Service Provider (BSP) holds a monopoly position on onboarding suppliers to a specific buyer or network. That BSP can set the terms: it can require full identity verification, enforce authentication standards, and charge onboarding fees. Suppliers have no alternative route — if they want access to the buying party, they must comply. This creates friction and cost for the supplier, but it also creates a verifiable chain: the buyer, and by extension the tax authority, can trust that the sender has been identified and authenticated in accordance with applicable requirements.
The four-corner and five-corner models — as used in Peppol and comparable open networks — invert this logic. In a competitive market of certified service providers, any additional onboarding requirement is a potential competitive disadvantage. A provider that demands extensive identity verification loses prospective customers to a competitor offering faster and cheaper access. The market therefore drives onboarding toward the technical minimum required to connect to the network, rather than the compliance maximum that public interest might warrant.
This is not a design flaw in Peppol. It is a predictable consequence of combining open network architecture with a competitive provider market — and one that delivers real benefits: lower barriers, faster adoption, broader reach, and access for smaller businesses that would never be served by a monopoly BSP. The trade-off is that compliance depth, including rigorous identification and authentication of senders, is not guaranteed by the network structure alone.
Countries that have prioritised fiscal control — Italy, Spain, Poland, Greece — have drawn an explicit conclusion from this trade-off. By choosing clearance models with a central government platform in the transaction flow, they ensure that identification, authentication, routing, and tax reporting are governed by law rather than left to market incentives. The choice is coherent, even if it comes at the cost of interoperability and the flexibility that open networks provide.
The challenge that remains is one that no individual service provider can resolve: in a competitive network, the cost of doing compliance properly falls on those willing to bear it, while the benefit — a trustworthy, verified network — accrues to everyone. That is a classic public goods problem, and public goods problems typically require a public solution.
From bilateral compliance to government-driven mandates
For decades, e-invoicing compliance was a bilateral matter. A supplier adapted to the technical requirements of each individual customer: Electronic Data Interchange (EDI) formats, customer-specific portals, agreed file structures. The recipient dictated the terms and the supplier followed. Large solution providers built their platforms around exactly that logic.
That model is shifting. Governments are now introducing mandates that do not just specify what an invoice must contain, but also set technical requirements for the infrastructure, the messaging standard, and the semantic structure of the data. Compliance is no longer a bilateral agreement between two trading partners. It is a multilateral obligation in which governments define the rules.
This shift is precisely what makes the e-invoicing recipient address challenge more visible than it has ever been. In a world of bilateral agreements, you asked your customer for their address. In a world of government-driven mandates, your system must know that address, validate it, and route correctly: automatically, at scale, across multiple countries simultaneously.
A gap worth putting on the agenda
France’s Annuaire demonstrates that routing transparency as public infrastructure is achievable. A supplier can determine where to route an invoice without needing to contact the recipient, provided they hold the national identifier.
The logical next step — an interoperable cross-border routing directory as a European or international baseline — is not currently on any policy agenda. That is worth naming explicitly. ViDA 2030 addresses transaction reporting between member states. But the question of who ensures that the e-invoicing recipient address of a cross-border counterpart is findable, validated, and current remains unanswered at the policy level.
The most valuable form of auto-discovery would go further still: a system that, given a company name or fiscal identifier, returns not only whether the recipient is reachable but also via which network or platform — Peppol, DBNAlliance, a national clearance system, or a certified PA. That is the missing link for suppliers operating across multiple countries. It does not yet exist as a standardised service.
Addressing this structurally also requires a conversation about how e-invoicing network infrastructure is governed. Two paths are worth considering.
The first is a more intergovernmental governance model for networks like Peppol. Today, OpenPeppol is a nonprofit association governed primarily by its member service providers and national Peppol Authorities. A more public-interest-oriented alternative would give governments a structural seat in determining the compliance standards that the network enforces — not just the technical specifications. A comparable model already exists in international finance: the Bank for International Settlements (BIS) is owned and governed by central banks, which are themselves public institutions. Its board is composed of central bank governors, not commercial banks. The result is a network infrastructure that serves system-wide public interests, not just member interests. A similar construct applied to e-invoicing network governance — where governments, through designated representatives, co-determine the compliance floors that every service provider must meet — would fundamentally change the market dynamics described above. It would create a level playing field where onboarding rigour is a shared baseline, not a competitive variable.
The Organisation for Economic Co-operation and Development (OECD) offers another reference point. Its Council operates at ambassador level, with each member country represented by a permanent delegate. This is a purely intergovernmental model — member states, not industries, set the agenda. Applied to e-invoicing, a comparable structure would allow countries to coordinate on shared compliance standards across borders, rather than each building its own national layer on top of a shared routing infrastructure.
The second path is more pragmatic: accepting that Peppol and comparable networks will continue to function primarily as routing infrastructure, while national compliance layers — onboarding, identification, authentication — remain the responsibility of individual countries. This is already the direction of travel. The practical consequence for internationally operating businesses is that entering a new market means going through that country’s onboarding process, regardless of what network you are already connected to. Knowing this in advance, and selecting a service provider that has already built those national integrations, becomes part of the market-entry decision rather than an afterthought.
Both paths are coherent. But they lead to very different futures for internationally operating businesses, and they deserve an explicit policy debate rather than an outcome by default.
What this means when you choose a provider
When selecting an e-invoicing solution, these are the questions that rarely get asked but matter most in daily practice.
In which countries must the solution support e-invoicing recipient address resolution? How does the provider solve all three layers for those specific countries? What happens when a recipient is not yet registered on any network? And can the solution scale as new mandates come into force?
Providers that answer these questions concretely — per country and per layer — are worth comparing carefully.
Compare certified e-invoicing providers on Peppol.now | How the four-corner and five-corner models work
Sources
VIES — VAT Information Exchange System — official EU VAT number validation tool. European Commission. https://europa.eu/youreurope/business/taxation/vat/check-vat-number-vies/index_en.htm
EU VAT Directive — Council Directive 2006/112/EC — the legal basis governing VAT information sharing between member states. EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32006L0112
EDPS — European Data Protection Supervisor — institutional overview. EDPS. https://www.edps.europa.eu/
Peppol Interoperability Framework — Overview of the four-corner model, SML and SMP. OpenPeppol. https://peppol.org/learn-more/peppol-interoperability-framework/
Peppol Directory — Public search interface for registered Peppol participants. OpenPeppol. https://directory.peppol.eu/
Companies House API — Developer documentation for the UK business registry API. Companies House (UK government). https://developer.company-information.service.gov.uk/
KvK Developer Portal — API documentation for the Dutch Chamber of Commerce. Kamer van Koophandel. https://developers.kvk.nl/
KBO/BCE Public Search — Belgian Crossroads Bank for Enterprises — public registry search. Belgian government. https://kbopub.economie.fgov.be/
Handelsregister — German commercial register — federated system. Bundesministerium der Justiz. https://handelsregister.de/
ABR — ABN Lookup — Australian Business Register — free public ABN lookup service. Australian government. https://abr.business.gov.au/
CAC Nigeria — Corporate Affairs Commission — Nigerian company registry public search. https://search.cac.gov.ng/
RUES Colombia — Registro Único Empresarial y Social — Colombian unified business registry. https://www.rues.org.co/
SAT Mexico — Servicio de Administración Tributaria — Mexican tax authority and RFC validation. https://www.sat.gob.mx/
DBNAlliance — Digital Business Networks Alliance — the US open e-invoicing exchange network. DBNAlliance. https://dbnalliance.org/
PPF / Annuaire — Portail Public de Facturation — French central invoicing portal and recipient directory. DGFiP. https://portail-facturation.dgfip.finances.gouv.fr/
BIS — Bank for International Settlements — governance structure and board composition. BIS. https://www.bis.org/
OECD Council — Organisation for Economic Co-operation and Development — Council and ambassador-level representation. OECD. https://www.oecd.org/en/about/structure/council.html
Comparison tool — Compare certified Peppol Service Providers. Peppol.now. https://peppol.now/comparison/
4-corner / 5-corner model — Knowledge base article on how the four-corner and five-corner models work. Peppol.now. https://peppol.now/knowledge/four-corner-five-corner-model/
