Europe's e-invoicing mandates: one roadmap to compliance

Belgium's domestic B2B e-invoicing mandate is already live. France entered its first mandatory phase on 1 September 2026. Germany and Norway both hit major issuance milestones on 1 January 2027, and the UK introduces mandatory e-invoicing on 1 April 2029. Most groups will meet each deadline. The risk is that they do it through country-specific fixes that never add up to one group process.

An organisation can make the right implementation decision in each country and still create a fragmented group process. In France, it may select the right accredited platform (plateforme agréée, or PA). In Belgium, it may implement Peppol correctly. In Germany, it may choose a compliant exchange route. But if those decisions are made separately, without one group design, the multinational can still end up with duplicate integrations, multiple providers, inconsistent invoice statuses, and separate exception processes across accounts receivable (AR), accounts payable (AP), and employee spend. The challenge is therefore not only complying with each mandate. It is making sure that the country-specific implementations still add up to one workable finance process.

The first article in this series explained why European e-invoicing cannot be treated as one model. This article starts with the consequence of that reality: several different mandates now have to be delivered through the same group organisation, systems, and controls. And the pressure will only increase as more countries introduce mandates and existing regimes expand through later waves, reporting layers, and broader scope.

The mandates overlap before the previous go-live is stable

A statutory go-live is only the visible point on the calendar. Provider selection, data remediation, and testing start months earlier; post-go-live stabilisation, supplier and customer issues, exception handling, and control tuning continue afterwards. France's September 2026 go-live therefore overlaps directly with the German and Norwegian implementation work for January 2027.

Placed on one group roadmap, the overlap becomes visible:

The calendar shows a continuous workload rather than a sequence of neatly separated projects. But timing is only the first layer of the problem. If every mandate required the same build, the group could largely repeat the first solution. It cannot, because the legal and technical work changes by country.

Different deadlines require different delivery responses

Overlapping dates would be much easier to manage if every mandate required the same implementation. They do not. At any given time, a multinational may be stabilising a regime that is already live, building a future requirement whose legal and technical design is largely fixed, and preparing for another market where important detail is still developing. Those are three different delivery problems.

A live regime needs production support, exception management, and control tuning. A confirmed future mandate needs design, data remediation, provider onboarding, and testing. A regime whose secondary rules are still moving needs decisions that preserve flexibility without delaying the work that can already be done. Treating all three as the same country rollout either creates rework or pushes teams into tactical choices.

The group can still reuse parts of the solution: source data, master-data governance, integration patterns, lifecycle statuses, monitoring, reconciliation, and control principles. What it cannot do is copy one complete country solution into the next. That combination of common corporate infrastructure and different local requirements is where the risk of fragmentation begins.

Separate country implementations can fragment the group finance process

The delivery pressure can show up in two different ways. In some groups, the same central specialists support several country implementations because they understand the group's VAT determination, master data, invoice output, integrations, and accounting controls. Post-go-live support for the French implementation can then overlap with the German and Norwegian build, year-end close, audit activity, and ERP change freezes. In other groups, delivery is pushed to local finance and IT teams or country providers. That reduces the central bottleneck, but creates a different risk: countries can solve the same problem differently, repeat work already completed elsewhere, and fail to carry lessons from one implementation into the next.

Both delivery models need a small group-level core team or design authority. It does not have to execute every local rollout. Its role is to protect the common design principles, own the group data and control model, approve genuine country deviations, maintain the roadmap, and carry learning from one implementation into the next. Local teams can still own country delivery, but they should not have to reinvent the architecture. Without that core layer, either central capacity becomes the bottleneck or local autonomy gradually becomes fragmentation.

Once those country implementations start diverging, the impact spreads beyond the project itself. It moves through provider and integration choices, data ownership and exception handling, then into the AR and AP controls around tax and cash, and finally into the financial and compliance exposure carried by each entity.

The operating model fragments first

A provider selected to meet one country deadline can become a permanent integration that the group has to support. Shared services may then inherit different channels, status messages, rejection flows, and correction processes. Master-data gaps become routing failures once exchange is automated, while audit evidence and lifecycle statuses are stored differently by entity. The group can lose one end-to-end view of the invoice lifecycle: invoice creation, platform or network status, any tax-authority reporting, ERP posting, and the VAT record. Reconciling that full chain is a control the group should design centrally.

The impact then reaches AR, AP, and employee spend

AR is often the first pressure point, because most mandates initially change the outbound sales-invoice process. That is where the taxable transaction, VAT determination, invoice obligation, delivery to the customer, and collection cycle all meet. Under EU VAT rules, VAT is generally chargeable when the relevant taxable event occurs, subject to transaction-specific rules and national options. A rejected or unprocessed e-invoice can therefore delay billing or customer payment without necessarily delaying the output VAT obligation. For AR, the control is not simply whether an XML file was generated. VAT determination, invoice issuance, delivery status, corrections or credit notes, accounting, and cash collection all need to remain aligned.

AP carries a different risk. The right to deduct input VAT arises when the deductible tax becomes chargeable, but for ordinary supplies the business generally needs a valid VAT invoice to exercise that deduction. If an incoming e-invoice cannot be received, validated, or linked to the accounting record, posting, approval, supplier payment, and input VAT recovery can all be delayed. AP controls therefore need to link the structured invoice and its delivery status to matching, approval, accounting, and VAT evidence. Employee expenses sit beside that process but are not automatically part of the same legal invoice flow. A platform such as Rydoo does not replace a Peppol provider or French PA; it helps keep employee-spend evidence, policy checks, approvals, VAT capture, and the accounting hand-off controlled while AP adds new invoice channels.

The same weakness produces different country risks

A weak invoice process does not create the same exposure everywhere. Belgium applies a specific graduated fine where a business lacks the technical means to issue and receive structured e-invoices: EUR 1,500 for a first infringement, EUR 3,000 for a second, and EUR 5,000 for subsequent infringements. France has statutory document-level and reporting penalties, although the government confirmed that no business will be sanctioned during 2026 while the reform is being brought into operation. Germany does not use the same dedicated per-invoice penalty model; failures feed into the ordinary VAT invoicing, correction, and record-keeping framework. Norway and the UK still have enforcement details that need to be finalised as their remaining rules are developed.

Penalty amounts matter less than the shape of the exposure. The same rushed local workaround can create a capability fine, document-level exposure, delayed input VAT recovery, customer correction work, or an open future risk depending on the country. Fragmentation is therefore a tax, cash, control, and operating-model issue, not simply an architecture problem.

At that point, the design question changes. The group no longer needs to ask how to make each local implementation work in isolation, but which parts of the finance model should stop being redesigned country by country.

Standardise the group design before deciding what to outsource

Once fragmentation is visible, the most important question is not which provider can solve the next country. It is which parts of the finance and compliance model the organisation wants to own and keep consistent as more mandates are added. That includes the source-data definitions, master-data ownership, tax and routing principles, lifecycle statuses, exception handling, monitoring, AR and AP reconciliation, minimum audit evidence, and the link back to the ERP and VAT record.

Connectivity can also be reused where local rules allow it. A common network such as Peppol may form part of that connectivity strategy in several markets, while other countries require a different route. The more important design choice is to keep the provider interface and internal data model consistent enough that a change in country channel does not force a redesign of the underlying finance process.

That common design creates a much clearer make-versus-buy decision. Country-specific format transformation, technical validation, connection to platforms or networks, transmission, operational monitoring, and technical archiving can all be outsourced. But outsourcing execution should not mean outsourcing understanding or control. The organisation should still know what source data was used, what rules were applied, what was transmitted, which status came back, and how the result reconciles to its own accounting and VAT records.

The same principle applies to archiving and evidence. A provider can store the technical archive, but the organisation should define what must be retained, how long it must remain accessible, how invoice and status history can be retrieved, and how that evidence connects to the accounting record. The service can be outsourced; accountability for the control cannot.

Keep provider choice understandable and reversible

Some multinationals use different local providers; others prefer one global provider to reduce integrations, contracts, and support models. Both approaches can work. A global provider can simplify delivery, but it does not automatically remove fragmentation. Country coverage may differ in depth, local capabilities can depend on partners or provider roadmaps, and proprietary mappings, validations, or status models can create lock-in. A group can be compliant and still find that it cannot easily explain why an invoice failed, what was reported to the tax authority, or how to move a country to another provider. Provider selection should therefore sit inside the group architecture, not define it.

The group-level core team should therefore retain ownership of the common design and the provider-governance rules. That includes data and API access, mapping and validation transparency, monitoring, portability, migration, and exit requirements. Local or global providers can then deliver country-specific services around that design without becoming a black box that the organisation cannot challenge or replace.

Country-specific work will always remain. The French implementation needs its local platform and reporting design; Belgium has its current invoice-exchange model and a future reporting phase; Germany retains channel flexibility; Norway has its 2027 sending obligation while secondary rules continue to develop; and the UK needs a 2029 country design around its confirmed mandate. Those differences should connect to one governed group model rather than create separate end-to-end processes.

The real test is what happens when the next mandate arrives

That test will come repeatedly. More countries will introduce e-invoicing, while regimes already in place will continue to expand through new taxpayer waves, receipt obligations, transaction reporting, and wider scope. A group with a stable design can add the next entity, flow, deadline, and local requirement to an existing roadmap. A fragmented group starts again with another owner, provider, integration, and exception process.

For finance and tax teams maintaining that roadmap, the Rydoo Compliance Centre provides country-by-country information on e-invoicing and related spend-compliance topics, including VAT, paperless documentation, per diems, and mileage. It complements official sources and helps teams keep AP and employee-spend requirements visible as the mandate calendar evolves.

Status and sources: this article reflects mandate status, dates, and official guidance available as of 16 September 2026, checked against official materials from the French Ministry of Finance, the Belgian federal e-invoicing portal, the German Federal Ministry of Finance, the Norwegian Ministry of Finance (Prop. 44 L, 2025–2026), GOV.UK, and the European Commission's ViDA materials. E-invoicing and digital reporting rules continue to evolve, and several future measures above still require secondary legislation or detailed technical rules, particularly Belgium's future reporting phase, Norway's secondary regulations, and the detailed UK 2029 regime. Verify the position for the relevant entity and transaction before implementation. This article is general information and is not tax or legal advice.