Ask what Europe's e-invoicing mandate requires and you will get an answer with a date in it. The answer is almost always wrong, not because the date is wrong but because the question has no single answer. There is no European e-invoicing mandate in the sense the question implies. There is a directive that obliges public bodies to receive structured invoices, a VAT directive that governs what an invoice is and what has to be provable about it, and — doing nearly all of the work that affects an ordinary business — around a dozen separate national laws, each with its own scope test, its own thresholds and its own timetable.
The practical consequence is that "when does the mandate start?" is unanswerable until you have said which entity, in which country, supplying whom. This article sets out the framework those questions are answered inside.
The three layers
Every obligation you are subject to comes from one of three places, and it is worth being able to say which.
| Layer | Instrument | What it actually obliges |
|---|---|---|
| European, procurement | Directive 2014/55/EU | Contracting authorities must receive and process invoices that comply with the European standard |
| European, VAT | Directive 2006/112/EC, as amended | What an invoice must contain, what must remain provable about it, how long it is kept |
| National | A national law, per Member State | Which businesses must issue a structured invoice, to whom, from when, in what format |
Only the third layer creates the obligation most businesses are worried about, and the third layer is not harmonised. Two Member States can adopt the same European standard, use the same network and still differ on the turnover threshold, the treatment of simplified invoices, the definition of an established business and the retention period.
Layer one: procurement, and why it is not enough
Directive 2014/55/EU is where European e-invoicing legislation begins. It did something narrow and important: it obliged contracting authorities and contracting entities to receive and process electronic invoices that conform to a European standard, and it commissioned that standard. It did not oblige any supplier to send one.
That asymmetry was deliberate, and it worked. It produced EN 16931 — a semantic model that every subsequent national mandate has been built on — without forcing a single small supplier to buy anything. It is also why business-to-government invoicing was solved years before business-to-business invoicing was seriously attempted.
Layer two: the VAT directive, and the sentence that changed
The VAT directive defines an electronic invoice as one issued and received in any electronic format. On that definition a PDF attached to an email qualifies. That is not a drafting accident: the 2010 amendment that introduced it was written to put paper and electronic invoicing on an equal footing and to stop Member States imposing technology requirements of their own.
Two provisions of that framework matter more than the rest.
The first is the requirement that the authenticity of origin, integrity of content and legibility of an invoice be assured from issue until the end of the retention period, with the taxable person free to choose how. That is still in force and still where most of the real compliance risk sits.
The second was the requirement that the use of an electronic invoice be subject to acceptance by the recipient. For a decade that sentence was the reason a Member State could not simply mandate structured invoicing: it had to ask the Council for a derogation under Article 395 first. Italy, France, Poland, Germany, Belgium and Romania all did exactly that. The VAT in the Digital Age package removes that obstacle, which is why the pace of national mandates changed.
Layer three: the national mandates, and how they are shaped
Read enough of them and the same architecture appears. A national mandate has to answer five questions, and it is the answers, not the technology, that decide how much work you have.
- Who is caught? Usually taxable persons established in the country, for domestic supplies to other taxable persons. Establishment is doing heavy lifting in that sentence and the definitions differ.
- What counts as compliant? A format, or a small set of them — normally a national profile of the European standard rather than the standard itself.
- How does the document travel? Either a four-corner network of accredited providers, or a platform operated by or for the tax administration.
- What does the administration receive, and when? The whole invoice, a defined data set, or a separate report — before delivery, at the same time, or afterwards.
- When does each group start? Almost always in stages, and almost always in the same order.
That last point is the one businesses consistently under-plan. The obligation to receive comes first, applies to everyone at once, and cannot be deferred by deciding not to change your own billing. It needs an address in a network, a monitored inbox and a decision about what to do with a document that arrives already structured — before it needs any new software at all.
The countries, and what distinguishes them
| Country | Architecture | Distinguishing feature |
|---|---|---|
| Italy | Central clearance | Longest-running B2B mandate in Europe; a national format, not a European profile |
| France | Licensed platforms | Invoicing and separate reporting; the platform, not the state, is the counterparty |
| Germany | No central platform | Receipt obligation first, staged issuing obligation later, no clearance step |
| Poland | Central clearance | A single national system that assigns the invoice its identifier |
| Spain | Two obligations at once | A B2B mandate sitting beside long-established ledger reporting |
| Belgium | Four-corner network | Structured invoicing on an existing network, with no national platform |
Reading down that table, the temptation is to conclude that clearance models are the strict ones and network models the relaxed ones. That is not how it works in practice. A clearance platform tells you immediately whether your document was accepted, which is unpleasant and useful. A network model tells you nothing until a buyer's own validation rejects it three days later, by which time the document has left your systems and the problem is a business exception rather than a technical one.
The establishment test is where scope actually goes wrong
Of the five questions above, the first is the one that produces expensive mistakes, and it produces them quietly.
A mandate normally catches taxable persons established in the Member State. That word is doing a great deal of work, and it is not a synonym for "registered for VAT there". A business can hold a VAT registration in a country — because it stores goods there, or because it exceeded a distance-selling threshold — without having anything that amounts to an establishment. Whether that registration brings it into scope of the invoicing mandate is a question of national law, and the answers differ between Member States that otherwise look similar.
Two consequences follow, and both are routinely missed.
The first is that a group with entities in several countries cannot answer the scope question once. It has to answer it per entity, per country, against that country's own test, and record the reasoning — because the answer will be challenged by somebody in two years and nobody will remember how it was reached.
The second is that scope moves without any law changing. Open a warehouse, second staff to a subsidiary, restructure a branch into a company, and an entity that was out of scope becomes established. Nothing in the mandate has changed; the facts have. That is why the scope statement produced by a readiness assessment has to be a living document with an owner rather than a project artefact, and why the most useful question to ask a tax adviser is not "are we in scope" but "what would have to change for us to become in scope".
Divergence first, convergence later
Anyone looking at the table above for the first time reaches the same conclusion: this is a mess, and it is getting worse. That is accurate about the present and wrong about the direction.
The divergence is a consequence of sequencing. Member States began mandating before there was a European framework permitting them to, so each obtained a derogation and each designed its own architecture around its own administration's priorities. Italy built clearance because it wanted the data. Germany did not build a platform because it did not want to operate one. France chose licensed intermediaries. None of those decisions was coordinated, because there was nothing to coordinate them.
The reforms in the VAT in the Digital Age package change that in one specific way: they set the European standard as the reference point for domestic regimes and remove the derogation requirement that made each mandate a separate negotiation. That does not retrofit convergence onto systems already running, and it does not mean the national formats disappear. It means the next mandate is more likely to look like the standard than the last one was.
For a business deciding whether to solve one country or several, that has a practical implication worth stating plainly. Building a country-specific solution for a mandate arriving now is defensible. Building six of them, on the assumption that each will always be different, is a bet against the direction the framework has already taken.
What actually has to change inside a business
The list is shorter than the market suggests, and almost none of it is about invoicing software.
Master data. A structured invoice carries identifiers with schemes attached, tax categories with reason codes, and units of measure from a code list. Most customer masters do not have them, and finding out which of five thousand accounts is missing one is the largest single task in any of these projects. Master data is where the timeline goes.
Addressing. You need to be findable, and you need to know where to send. That is a participant identifier in the relevant scheme, not a company registration number written on a form.
Accounts payable. A structured invoice arriving in an inbox that expects PDFs does not save anybody time; it creates a second process alongside the first. The saving comes from redesigning the process so that the matched invoices post themselves and only the exceptions reach a person.
Archiving. The document you must keep is the instance that was sent, not a rendering of it. That is a different requirement from the one most document management systems were bought to satisfy, and it is covered in archiving a structured invoice.
How to read a date on this subject
Every date attached to a mandate has a status, and the difference is not academic. A date in force is applying now. A date that is adopted is in a published law and applies from a future day. A date that is proposed is a statement of intent by a government, and governments postpone e-invoicing mandates routinely — several of the timetables in the table above have already moved more than once, some of them twice.
Plan against dates that are in force or adopted. Track the proposed ones. Do not commit capital to a proposed date without saying out loud, in the paper that requests the capital, that it is proposed.
Establish which of your legal entities is established for VAT purposes in each country you sell in, and put that list beside the table above. Every other question on this site is downstream of that list, and almost nobody has it written down.
Where to go next
If you are trying to answer a scope question, start with the country articles. If you are trying to work out what a compliant document looks like, start with EN 16931. If your problem is that something is arriving and nothing downstream can read it, start with the validation stack.
