The core is getting less and less core
Last updated: 10 de September de 2026
CEN has approved and published a revised version of EN 16931-1, the semantic data model behind almost every electronic invoice sent in Europe. The European Commission will publish the reference to the new version, with a transition period. Peppol, XRechnung, Factur-X and the national formats all need changes to follow it, and that work is already under way.
I would like to raise a concern that some experts in the field have also expressed and that I think deserves attention: when defining the new version, the cost of migrating the existing ecosystem may not have been given enough weight. And this is not a minor consideration. A change to a standard like EN 16931 does not only affect the standard itself; it eventually reaches service providers, ERP vendors, accounting software and, ultimately, millions of companies.
I think this is therefore the right moment to question whether we are going in the right direction.
Where the standard came from
Directive 2014/55/EU required public authorities across the EU to be able to receive electronic invoices. To make that possible you need one thing everyone agrees on, so CEN was asked to produce a European standard for the semantic content of an invoice. EN 16931-1 was published in 2017, amended in 2019, and became the receiving obligation for public bodies in April 2019.
The design decision that made it work was restraint. The standard defines a core invoice model: around 160 business terms covering the absolute majority of the information actually used on invoices day to day. Not everything an invoice could possibly contain. Just what is genuinely common.
The point of a core that size is that it works without bilateral agreements. A seller does not have to negotiate with each buyer about which parts of the invoice are in use, which fields will be read and which will be ignored. Anything beyond the common set was pushed out into extensions, where it affects only the parties that need it.
And this, in my opinion, is exactly what a standard should do: make decisions. Define what is common, agree on how to represent it, and leave particular needs outside the core. That balance was the real value of the standard. Not the number of terms, but the fact that the set was well chosen: large enough to invoice properly, small enough that two parties who have never spoken can exchange an invoice and both process it automatically.
The 2026 revision is driven largely by VAT in the Digital Age and the digital reporting requirements that come with it. Some of it is genuinely useful cleanup, for example tax category combinations that were ambiguous in practice. But the revision also brings in a significant amount of new functionality, and the result is not backward compatible.
What revision does
Among the additions:
- consolidation of several deliveries into a single invoice, using delivery addresses, delivery dates and document references at line level;
- third-party charges added on top of the invoice total;
- multiple buyer references on the same invoice;
- and other changes along the same lines.
And this is not the end of it. CEN is already planning an amendment on top of the revision, which may bring further features and further business terms into the core.
This is where I start to have doubts. Every business term added to the core may solve a problem for a few companies, but it creates an implementation requirement for everyone. And at some point, the core stops being core.
What we see from where we sit
In B2Brouter we run the API that more than 100,000 companies use to send and receive invoices, fully aligned with the current Peppol BIS. That gives us a fairly direct view of what businesses ask for.
They have not asked for this. We are not guessing from a survey. We are describing years of support tickets, integration projects and feature requests from an installed base at that scale, and the new business terms are not in them.
We will implement all of it anyway, because supporting the standard is not optional for us. We have not finished costing the work, but it will be expensive, and the expense does not stop at our door. Every ERP and accounting system integrated with our API has to follow, and the same is true across the market: every service provider, every ERP vendor and every accounting package in Europe faces the same work.
A standards change becomes an ecosystem change. Service providers implement it first, but ERP vendors, accounting platforms and ultimately their customers all inherit part of the migration work.
It is worth separating the two kinds of change here. The ViDA-driven parts have a reason behind them that we can explain to an ERP vendor: legislation is coming, reporting will require this data, here is the deadline. That is a cost, but at least there is a clear reason for it.
The rest is harder to defend. Asking ERP vendors and their customers to fund a non-backward-compatible migration for functionality that nobody in their user base requested is much more difficult to justify, and I expect resistance rather than enthusiasm.
The part that lands on small suppliers
There is a downstream effect that deserves more attention than it gets.
Once a business term exists in the core, a large buyer can require it, and a small supplier has no realistic way to refuse.
Take the buyer reference, BT-10. This is the plain “your reference” that has been printed on paper invoices and PDFs for decades: one value, given by the buyer, that tells their side where the invoice belongs. Every invoicing and accounting system in Europe has a single field for it.
What happens when one field becomes a list?
The revised standard makes BT-10 repeatable. A large buyer can now decide that every invoice must carry two or three references, for instance the person who ordered plus an internal routing code for the department that will approve it. Their supplier is a small company with one field, because one field is all the standard has ever asked for.
That supplier now has three options: wait for their software vendor to turn a field into a list, cram all the values into the one field they have and hope the buyer’s validation accepts it, or go back to sending a PDF and lose the automation entirely.
None of those is a good outcome, and none of them was caused by the supplier. The core model was supposed to protect exactly these companies from having to renegotiate their invoicing every time a large customer changes its internal systems.
If we start moving particular business needs into the core, we are doing exactly the opposite: we are forcing everyone to support requirements that only some companies actually need. The more the core grows, the less it does what it was created to do.
For our customers, concretely
Nothing changes for you today. The current Peppol BIS remains in force and remains supported. These standards do not change overnight, and there will be a transition period.
We will give our customers and ERP partners enough notice to adapt. When it comes, the implementation work is ours, and we will work with the ERP partners integrated with B2Brouter so the changes reach their users without turning a standards revision into an emergency project.
Where this should be raised
This is not a criticism of Peppol. OpenPeppol takes the European standard as given and has to build on whatever CEN publishes. The decisions we are questioning were made in the revision of the EN itself.
And this is why I think this discussion should go beyond the technical working groups. The question is not whether these new business cases exist. Of course they do. The question is whether every business case that exists should become part of the European core invoice model.
Because every time we add something to the core, someone has to implement it, maintain it and pay for it.
Is the core invoice model still a core?
We think the question belongs at policy level rather than inside technical working groups: is the core invoice model still a core, and who pays when it stops being one?
Looking to integrate e-invoicing into your software?
Book a technical demo with our solutions engineering team or explore our API documentation to launch in weeks instead of quarters.