One connection, millions of businesses: How to scale e-invoicing across borders
Last updated: October 23, 2026
Think of millions of businesses in many countries that all need to send and receive structured electronic invoices, with customers and suppliers at home and across borders. Most of them are small. They have no IT department, nobody who knows what an invoice format is, and no reason to learn. They want to send an invoice and get paid, and they want the invoices they receive to be easy to book in their accounts and pay on time.
Traditional EDI often relies on bilateral agreements, partner-specific configurations and customised mappings, even when messages are exchanged through service providers. That works for a large retailer and its hundred biggest suppliers. It does not work for millions of businesses, because the number of trading relationships grows much faster than the number of businesses. Managing individual agreements and configurations for every trading partner simply does not scale.
The other common approach is a central national platform, built by a public body for domestic needs. Every business in the country connects to it, and inside that country it can work well. But such platforms are often designed around one country’s formats and rules. A business that invoices customers in five countries may have to adapt to five different systems, while foreign suppliers face requirements that were never designed with cross-border exchange in mind. A national platform can scale domestically without necessarily scaling internationally.
So the architecture has to start from the need to scale. A business chooses its accounting software and its service provider. After that, it should be able to exchange invoices with anyone, regardless of the country or the provider they use.
Such an architecture would need a small number of mechanisms:
- A network of service providers. Each business should connect to one provider, and the providers should connect to each other through common rules and protocols. One connection should be enough to reach every business in the network, and a new business should become reachable by everyone as soon as it joins.
- Competent ERP and accounting software providers. The ERP or accounting system holds the source data: the customer reference, the VAT treatment, the goods or services supplied. That data should be maintained in a form that makes it possible to create a compliant invoice. Users should be able to issue electronic invoices as easily as they currently generate a PDF.
- Recognised identifier schemes. Businesses should be able to use identifiers they already possess, such as VAT numbers, company registration numbers or GLNs. The network should maintain a defined list of accepted schemes. These identifiers should belong to the businesses, not to their service providers, and remain portable when they change provider.
- Automatic addressing and discovery. At the moment of sending, the sender’s provider should automatically discover where the receiver is registered, which provider serves it, which document types it can accept and where to deliver them. A shared discovery mechanism with distributed service metadata can make this possible without bilateral partner configurations or a central database containing every participant’s technical details.
- Common standards for domestic and cross-border use. There should be one common semantic core for all invoices, whether domestic or cross-border. National rules may introduce additional requirements, but they should preserve the common meaning of the data and avoid forcing receivers to implement incompatible country-specific formats.
- Freely available standards. Technical specifications, validation rules and test materials should be publicly accessible and available for implementation without proprietary licensing barriers. Operating as a network service provider may still require accreditation and compliance with common rules, but access to the standards themselves should not depend on commercial agreements.
- A secure protocol. Communication between providers should use authenticated, encrypted transport, cryptographic integrity protection and verifiable delivery acknowledgements. Network-issued certificates should establish trust between service providers. Authentication, integrity and confidentiality should be built into the infrastructure, with nothing for individual businesses to configure.
- One legal framework for all. Every provider should operate under the same agreement, covering responsibilities, compliance, security and appropriate know-your-customer checks. Businesses should be verified before registration, and providers that fail to meet their obligations should be subject to corrective measures or removal from the network.
- Simple migration between providers. A business’s address in the network should be based on its own recognised identifier, not one assigned by its provider. When a business changes provider, its registration and routing information should be updated without requiring its trading partners to change their systems. This prevents lock-in, encourages competition and helps keep prices down.
- Tax reporting without disrupting business exchange. Tax authorities may require transaction data for compliance and control, but reporting obligations should not force businesses to abandon interoperable exchange networks. Business-to-business communication and tax reporting serve different purposes and should be designed as complementary functions. Governments should be able to obtain the information they need without imposing unnecessary country-specific barriers to the exchange of invoices.
- A neutral, non-profit organisation that sets the rules. Common standards, agreements and operating rules should be maintained by a neutral, non-profit organisation through a transparent governance process. It should not compete with service providers or favour individual market participants. Its role is to maintain the shared infrastructure and ensure that providers can compete fairly on top of it.
These are the properties of an architecture that could scale to millions of businesses, across countries, without requiring every company to understand the technical complexity behind electronic invoicing.
The objective is simple: businesses should be free to choose their software and service provider, while remaining able to exchange invoices with anyone.
Do you know of an architecture like this?
I do. 🙂
One connection. Global reach. Ready to integrate?
Shared standards, interconnected providers and one connection to reach a global network. B2Brouter’s API brings these principles into your ERP or software, making international e-invoicing easier to integrate and scale.