Invoice compliance just became an architecture problem

Belgium switched on mandatory structured B2B e-invoicing on 1 January 2026. The three-month tolerance period ended on 31 March. Fines now start at 1,500 euros for a first infringement and climb to 5,000 for repeat offences.

Paper is out. PDF attachments are out. If you invoice a Belgian business today, the invoice travels the Peppol network as a structured EN 16931 document, or it doesn’t count.

Here’s the truth: Belgium itself is not the story. The story is what Belgium tells you about the next three years of your ERP roadmap.

The wave, not the mandate

Look at the calendar for a single D365 Finance estate trading across Europe. Belgium has been live since 1 January 2026, with Peppol e-reporting to follow in January 2028. Poland’s KSeF went live for large taxpayers on 1 February 2026, roughly 4,200 of them in the first phase, and extended to all B2B on 1 April. France switches on its receive obligation for every established business on 1 September 2026, with large and mid-size companies issuing from the same date. Germany has required businesses to receive EN 16931 invoices since January 2025, with issuing obligations phasing in through 2027 and 2028. And the UK has now confirmed in its consultation response that e-invoicing will be mandated for all VAT invoices from 2029, with the implementation roadmap due at Budget 2026 and Peppol named as the core network.

Five countries. Five formats. Five deadlines. One finance system and one close.

If you run one D365 F&O instance across several of these countries, you’re not managing a mandate. You’re managing a pipeline of them.

Three patterns that don’t scale

What I’m seeing across D365 Finance programmes right now:

Invoice outputs still designed for PDFs. Years went into polishing the template. Logo placement, footer wording, print alignment. None of that survives contact with a structured exchange network, where the invoice is an XML document validated against a ruleset and the human-readable layout is an afterthought.

Country compliance logic hardcoded into customisations. A Belgian VAT rule buried in X++ here, a Polish field mapping welded into an integration there. Each one works on its own. Together they turn every new mandate, and every Microsoft service update, into a regression exercise.

Peppol readiness parked as “later”. Until a mandate date lands and “later” becomes a mini-project with a legal deadline, run in a hurry by whoever happens to be available.

Each of these is rational in isolation. That’s what makes them dangerous. Nobody sets out to build an unscalable invoice architecture. It accretes, one country at a time, one urgent workaround at a time.

What modular actually means

If you operate across multiple legal entities or countries, your invoice architecture needs four layers you can change independently.

Country rules. The mandate-specific logic: what Belgium requires, what KSeF requires, what France will require in September. This layer changes constantly and should be configuration, not code.

Validation. Checks that run before a document leaves your system. Catch the EN 16931 and country-specific errors inside Dynamics and rejections drop sharply. Skip this and your finance team spends its week chasing rejected statuses out of a platform portal.

Transport. How documents move: Peppol access point, national platform, service provider. This layer should be swappable. Choosing a provider must never mean re-architecting, because you may need to change providers faster than you can change architectures.

Tax mappings and master data. VAT IDs, endpoint identifiers, units of measure, tax codes. The least glamorous work on the plan and, on the projects I’ve run, the single biggest cause of rejections. A perfectly valid XML built from a wrong VAT number still gets refused downstream.

When those four are separated, a new mandate is an extension. Add a country rule set, plug in the transport, extend the validation, verify the data. When they’re tangled together, every new mandate is a transformation project. Again.

The good news for D365 estates

Standard product now does most of this, if you use it the way Microsoft designed it.

The Electronic Invoicing service in Dynamics 365 Finance is a configurable, multitenant engine that sits under Globalization Studio. Country features are imported and configured rather than coded. The Belgian Peppol feature has been generally available since April 2025 and covers outbound sales and project invoices as well as inbound vendor invoices. Poland’s KSeF feature sits in the same workspace. The Electronic Reporting formats underneath are Microsoft-maintained and updated as legislation changes.

So if your roadmap question is “does Microsoft handle e-invoicing”, the answer is yes. Build on what the product ships. The framework is not the part that fails projects.

What standard doesn’t do is the part that decides whether you go live cleanly: configuring the service against your actual document types and tax setup, wiring inbound invoices into AP so they land as pending vendor invoices your team can match, giving finance a lifecycle status view it can act on (a “refused” that nobody sees is a compliance gap with a date on it), validating before submission, and cleaning the master data nobody wants to own.

That last stretch is where every e-invoicing project I’ve seen either holds or breaks.

Centralised, localised, or hybrid?

Three operating models are emerging across multi-entity estates.

Centralised orchestration puts one invoice hub at the centre: one provider relationship, country rules applied centrally. Cleanest to run, but it concentrates risk, and it can fight country-specific realities like KSeF’s direct-to-authority clearance model.

Localised ERP logic configures each country in the ERP with its own feature and connection. This is closest to how Microsoft ships D365 today. It works well, provided you stay configuration-first and resist the urge to customise per country.

Hybrid keeps country rules and validation in the ERP while consolidating transport through one or two providers. On the multi-country D365 estates I work with, this is where most sensible architectures end up.

There’s no single right answer here. There is a wrong one: deciding by default, one urgent mandate at a time, until the architecture is whatever the last three deadlines left behind.

The question that matters

The question isn’t whether e-invoicing becomes standard. Belgium answered that in January. Poland answered it in April. France answers it in September, and the UK has put its answer in writing for 2029.

The real question is whether your ERP landscape can absorb each of those dates as configuration, or whether each one becomes another transformation project with a regulator’s deadline attached.

If you’re running D365 F&O across multiple countries and can’t answer that with confidence, have the conversation now, while the nearest deadline is still measured in months rather than weeks.

Book a 30-minute e-invoicing readiness call. Bring your country footprint, your D365 version, and whichever mandate date is closest. I’ll come back with a one-page fastest-path plan: what standard Dynamics already covers for you, and exactly what needs configuring on top.