Published: 05 August 2026
What the current wave of e-invoicing mandates reveals about tax data, systems and governance
Most of what an e-invoicing mandate exposes is not a defect. It is a decision, often a sensible one, taken when an invoice was primarily a document and the main question was whether it reached the customer.
Covering every business scenario in the ERP is expensive. Automating a process that occurs ten times a year may not justify the cost, so it is left to a person. Someone raises the invoice manually, perhaps in a spreadsheet or document template, sometimes outside the main billing system.
That was not necessarily poor design. Under periodic VAT compliance, the data could still be collected, reviewed and corrected after the transaction, when there was time to identify what the manual route had missed.
A structured e-invoicing mandate changes that calculation. A stress test introduces no weakness; it applies load until existing weaknesses become visible. The mandate is the load. It exposes every process deliberately left outside the automated transaction flow, and every exception that must now operate within a structured and controlled invoicing process.
The paths left outside the system
Re-invoicing is a clear example. Cross-charges, cost recharges, intercompany rebills and one-off corrections are often produced manually because they are too varied or infrequent to justify full automation.
Under a mandatory regime, the manual route does not necessarily disappear, but it must operate within the prescribed process. A spreadsheet or Word template can no longer serve as the final invoicing channel. The information must be converted into the required structured format, validated and transmitted through the relevant platform.
A scenario that was cheap to handle manually once a year may therefore need to be modelled, mapped and controlled in advance.
Customer-specific requirements create a similar challenge. A customer may require a purchase-order number, project code, cost centre or particular description. Historically, the solution was often to add the information manually before sending the invoice.
In a structured environment, the issue is not simply whether a field exists in the national schema. The data must exist in the source system and be mapped to the correct structured field. If it has not been captured or mapped, adding it manually after the invoice has been generated becomes much more difficult.
What was once a free-text amendment may therefore require configuration, mapping, testing and ownership. Requirements that were almost costless on paper acquire a technical and governance tail.
The mandate does not necessarily reveal that these processes were broken. It reveals that they were deliberately left unautomated, and changes the economics of that decision.
One entity, several systems
The same pressure exposes weaknesses in the wider system landscape.
It is not unusual for one legal entity to operate more than one ERP. The arrangement may result from an acquisition, regional implementation, carve-out or incomplete migration. In steady state, this creates maintenance and reconciliation costs, but organisations often learn to live with them.
E-invoicing changes the nature of that complexity.
Each source system needs its own data mapping, validation controls and integration into the mandated process. Even where several ERPs feed one global platform, the source-specific work remains. Tax codes, customer data, invoice types and document logic may be represented differently in each system.
The burden therefore multiplies across systems and countries, not merely across legal entities.
Each national mandate may introduce a different technical model, structured format, validation logic and communication process. If one legal entity operates two source systems, both must be mapped and connected to each relevant national model. The organisation is no longer managing one implementation per country, but a growing matrix of source systems and local requirements.
Each additional source system increases the work required for every mandate, and each additional mandate increases the cost of maintaining every source integration.
Consolidating onto one ERP may be a strategic response, but it is not an automatic one. The more immediate question is whether the e-invoicing architecture can insulate national requirements from the underlying systems.
A global layer can reduce duplication by standardising the core invoice model and containing country-specific formats, validations and routing rules. It cannot remove differences between source systems, but it can prevent each difference from becoming a separate national build.
The other half of the transaction
The buy side carries a subtler version of the same problem, involving technology that many organisations have only recently implemented.
Accounts payable teams have invested heavily in OCR: technology designed to extract structured information from PDFs and scans and convert it into data that can be processed by the ERP.
For invoices received in a structured format, the role of OCR should diminish substantially. The data is already labelled and structured and can, in principle, be validated and processed directly.
In practice, some organisations render the incoming XML into a visual document and feed it back through OCR. Structured data is converted into a PDF so that the existing process can reconstruct it as structured data again.
As a temporary bridge, this may be understandable. Suppliers may still send different formats, legacy systems may require visual documents and deadlines may leave little room for redesign.
As a long-term architecture, however, it preserves the weaknesses of the old process. It retains extraction errors, adds unnecessary transformations and prevents the organisation from using structured data as intended.
Structure alone is not enough. A technically valid XML invoice may still contain the wrong VAT treatment, supplier registration or transaction reference. Direct processing removes extraction guesswork; it does not remove the need to validate the meaning of the data.
What is actually being tested
It would be easy to view these issues as implementation friction. That misses the broader point.
National mandates test whether invoice processing has been designed as a transaction-level capability or as a collection of local documents and workarounds.
ViDA will increase that pressure. Structured e-invoicing and digital reporting will become part of the standard model for certain intra-EU transactions, while domestic regimes continue to develop in parallel. The direction is towards more structured data and closer links between invoicing and tax reporting.
The question is therefore not only whether an organisation can comply with the mandate immediately in front of it. With enough effort, most can deliver one country.
The more revealing question is what the second country costs, and the third.
Does each mandate require another project, another set of mappings and another exception process? Or can it be added as a controlled configuration within a common architecture?
That answer is largely determined before any particular mandate arrives. It depends on how many invoice scenarios remain outside the system, how many source systems operate under one entity, whether outbound and inbound invoices are treated as structured data, and whether anyone owns the invoice model from end to end.
In many structured e-invoicing regimes, invoices are also transmitted through central or near-real-time systems operated or supervised by tax authorities, such as Italy’s SdI. This means that invoice data is available to authorities almost immediately, increasing the likelihood that inconsistencies or errors are detected early. Unlike in traditional periodic reporting, there is limited opportunity to identify and correct issues at the VAT return stage.
E-invoicing mandates do not simply test compliance readiness. They test whether the tax technology landscape can scale.
