What 10 Years of Powering Government E-Invoicing Taught Us About EDI Reliability

From Mercurius to today’s Peppol volumes in Babelway

In 2014, Belgium was still at the beginning of its structured e-invoicing journey. Mercurius was introduced as a common platform for public entities, giving suppliers a way to send electronic invoices to the Belgian public sector and allowing those invoices to be routed to the right administration.

Babelway was involved in that journey from the start and went on to power the Mercurius B2G gateway for ten years. At the same time, Babelway became a certified Peppol Access Point.

Back then, the context was very different from today. E-invoicing was still largely associated with specific projects, public-sector requirements and relatively limited groups of participants. The main challenge was often simply making sure that different systems could exchange structured documents correctly.

More than ten years later, that landscape has changed considerably. Belgium has moved from B2G e-invoicing to mandatory structured B2B e-invoicing, and Peppol has become much more central to the way invoices are exchanged in the country.

That change in scale is interesting because it changes what reliability means in practice.

Reliability is not just uptime

For an integration platform, availability is obviously important, but it is only part of the picture.

An invoice can leave one system successfully and still fail somewhere later in the process. It can be rejected because of a validation issue, routed incorrectly, or get stuck because of a problem on the receiving side. In those situations, the important question is not only whether the platform was online, but whether the transaction can be traced and the problem can be understood.

This is one of the things that becomes very clear when running e-invoicing infrastructure over a long period of time. Reliability depends on visibility across the complete exchange. You need to know whether a document was received, where it was sent, what happened to it, and why it failed if something went wrong.

Mercurius was built around this idea. It was not simply a place where invoices arrived. It also provided the mechanism to route documents to public entities and to follow their processing.

The importance of reliability increases with adoption

As e-invoicing adoption grows, the operational demands on the infrastructure grow with it.

A problem affecting a small number of transactions in an early-stage implementation can become a much more serious issue when the same type of integration is being used at much larger scale. This is where things such as traceability, monitoring, error handling and duplicate management become increasingly important.

The point is not that these are new requirements. They were already relevant in 2014. What changes is the impact when the number of users and transactions grows.

This is also why looking at Peppol only as a connectivity standard does not tell the whole story. The network can standardize the way documents are exchanged between organizations, but the systems behind those organizations remain very different.

Standardisation does not remove integration complexity

Peppol has made it much easier for organizations to exchange structured documents without having to build a separate bilateral connection for every supplier or customer.

That solves an important part of the problem, but it does not mean that every company suddenly uses the same ERP, the same internal format or the same business process.

One organization may already produce the required structured invoice format, while another may still be working with a different XML format, CSV, an API or an existing EDI standard.

The integration layer therefore still has an important role to play between the company’s internal systems and the external network. It has to handle transformation, validation, routing and communication without forcing the ERP to change every time an external requirement changes.

That flexibility becomes particularly important when regulation starts moving quickly.

The regulatory context has changed, but the integration still has to work

Mercurius was initially built around exchanges with Belgian public authorities.

Since then, e-invoicing requirements in Belgium have expanded significantly. What started as a B2G use case has now become part of the wider B2B environment, with structured electronic invoicing mandatory for most domestic transactions between Belgian VAT-registered businesses since January 2026.

For companies, this creates a practical challenge.

Regulation will continue to evolve. Formats can change. Validation rules can change. New document types can be added. Different countries can introduce different requirements.

But companies do not want to rebuild the connection to their ERP every time this happens.

A reliable integration architecture therefore needs to separate the internal system from the changing external requirements as much as possible. The ERP connection should remain relatively stable while the integration layer handles the differences in formats, networks and rules.

That is one of the clearest lessons from the evolution of Mercurius and Peppol over the past decade.

From a government project to everyday business infrastructure

Mercurius began as a way to make structured invoicing with Belgian public administrations easier.

Today, Peppol and structured e-invoicing are part of a much broader business environment.

The technology, the regulation and the number of participants have all changed, but the core expectations remain the same. Documents have to reach the right destination, the exchange has to be traceable, and when something goes wrong, the issue has to be clear enough to resolve quickly.

The difference is that all of this now has to work at a much larger scale and across a much wider range of systems and use cases.

That is probably the most important thing ten years of government e-invoicing has taught us about EDI reliability. It is not only about making an integration work correctly at the moment it is built. It is about making sure it continues to work as the environment around it changes.