E-invoicing in Europe: what each country requires
The rules diverge far more than most groups expect — the network, the format and the dates all differ. Here they are side by side, with a link to the tool for each country and what the work actually looks like inside Odoo.
What each country actually requires
Five bodies of law, side by side. The network, the format and the dates diverge far more than most groups expect — and a single configuration rolled out everywhere is the usual way to discover it late.
| Country | What the country imposes | Must be able to receive | Must issue |
|---|---|---|---|
| Germany | A format, and no network at all | then | |
| Belgium | The Peppol network, imposed by decree | ||
| France | A state directory and approved platforms | then | |
| Netherlands | No B2B obligation | nothing yet | nothing yet |
These dates are read from the same country files that drive each national tool — not retyped here. Follow a country to get your own dates, your profile and, where the law allows it, a real lookup.
Not covered yet: Luxembourg · Italy · United Arab Emirates · United Kingdom · United States. No tool there for now. If you invoice from one of them, tell us — we open a market when we can source it properly, not before.
One obligation, five different laws
E-invoicing is being mandated country by country, and the gaps are wider than most groups expect. It is tempting to treat it as one project — pick a network, switch it on everywhere — and that is the assumption that produces rejected invoices in one country while another has not yet asked for anything. The four things that actually differ are the channel, the format, the date, and who is caught by it.
The clearest illustration is that two neighbouring countries can require opposite things. Belgium mandates a network: since January 2026 a domestic B2B invoice travels over Peppol, and the royal decree says so in its own text. Germany mandates a form and no network at all: since January 2025 every business must be able to receive a structured invoice, but the finance ministry is explicit that it may arrive by e-mail. France mandates neither in that sense — it built a state directory and a register of approved platforms, and an invoice must pass through one of them.
Peppol, and why it is not the whole story
Peppol is a shared addressing and transport network for business documents. Rather than each company agreeing a format with each customer, every participant registers an address and exchanges structured invoices through certified access points. An invoice sent over Peppol arrives as data your accounting system can read, not as a PDF someone has to re-type.
Being 'on Peppol' means two things: your identifier resolves to a registered address, and your software can produce and receive the structured format. Many companies discover they have the first without the second, because an integrator registered them during a pilot and nothing was connected afterwards.
What changes from country to country is what that registration is worth. In Belgium it is how you comply. In the Netherlands it is voluntary — nothing in Dutch law requires it, and a Dutch business typically joins because a Belgian or German customer asks. In Germany it is one delivery option among several and carries no legal weight of its own. And in France an entry in the state directory is not something you create yourself: your approved platform declares you, which is precisely why an absent entry is worth checking.
What this means inside Odoo
Odoo acts as a Peppol access point, and it is registered on the French tax authority's list of approved platforms — since 15 April 2026, on the official list published on 19 August 2026, the same list the French tool on this site searches. That covers the two mechanisms that need an intermediary; the German requirement, being a format rather than a channel, is a question of what your invoices contain rather than how they travel.
The work is rarely the connection itself — it is the data behind it: customer records without valid VAT or registration numbers, product lines without the tax mapping the format requires, and journals that were never set up to keep structured invoices for the statutory retention period. A missing tax mapping does not produce a visible error on your side; it produces an invoice rejected at the network level that never reaches your customer.
Our usual sequence is to clean the partner and tax data first, register the addresses second, and only then switch the outbound flow. Doing it in the other order produces a queue no one can unblock at month end — and it tends to surface in the week the obligation starts, which is the worst possible week to discover it.
You can connect everywhere, and it is often a sensible baseline — but connecting is not complying. Belgium requires the network; Germany requires a format and accepts e-mail; France requires an approved platform and an entry in the state directory. A single rollout satisfies one of those three by accident, not by design. Work from the country tool for each market you invoice from: each one carries that country's own dates, its own questions and, where the law allows it, a real lookup.
Not immediately. Registration makes you reachable; whether you may stop sending a PDF depends on your country's mandate and on what your customer can receive. In practice most companies run both for a transition period.
Usually no. Odoo can act as your access point and is on the French approved-platform list, which avoids paying twice and keeps the invoice data in one system. A separate provider mainly makes sense when you have volumes or formats Odoo does not cover — or when a country requires something Odoo does not yet do for that market.
They are rejected at the network level and never reach your customer. This is why the data clean-up matters more than the connection: a missing tax mapping produces a silent backlog rather than a visible error on your side.