Most writing about VAT in the Digital Age treats it as one thing with one deadline. It is not one thing. Three legal instruments were adopted together, they amend three different pieces of existing law, and the directive among them carries three separate reforms with separate application dates and separate audiences. Only one of those reforms has anything to do with how an invoice is issued.
That distinction is not pedantry. A finance director who reads a summary and comes away with a single date has usually taken a date belonging to the platform economy rules or to the single registration measures and attached it to an invoicing project. The opposite error is more common still: treating the reporting obligation as something that arrives everywhere at once, on one morning, and therefore as something that can be left until the year before.
One more thing is worth establishing before anything else. The dates here have moved. The Commission's proposal is not the directive the Council adopted, and the calendar was amended more than once during the negotiation, which is why figures from the draft are still circulating in secondary material as though they were law. Anything you intend to plan against has to be read from the adopted legislation rather than from a summary of a proposal — including the summary you are reading now.
Three reforms travelling under one name
The directive amends the VAT Directive in three directions at once. These are usually called pillars, which is accurate enough provided you remember that the pillars do not share a roof. They have different subject matter, different application dates, and there is no operational reason why one project should deliver all three.
| Reform | What it changes | Touches the invoice document? |
|---|---|---|
| Digital reporting requirements | The definition of an electronic invoice, the conditions under which a Member State may require one, and transaction-level reporting of intra-Community supplies and acquisitions | Yes — this is the only one that does |
| Platform economy | Who is treated as the supplier where short-term accommodation or passenger transport is arranged through a platform | Only for platforms and the hosts and drivers behind them |
| Single VAT registration | The scope of the one-stop shop, the treatment of transfers of own goods, and the reverse charge where the supplier is not established | No |
If you sell goods or services to other businesses and you do not operate a platform, the middle row is somebody else's problem, and the bottom row changes where you register rather than what you issue. What is left is the top row. Its most consequential provisions, as it happens, are not the reporting rules at all.
What changed on the day the directive entered into force
Two provisions took effect on entry into force, years ahead of any reporting obligation, and both have already reshaped the ground under national mandates. Neither obliges a business to do anything. They remove obstacles that were holding Member States back.
Acceptance by the buyer is no longer a precondition
Under the invoicing rules as they stood, use of an electronic invoice was subject to acceptance by the recipient — Article 232 of the VAT Directive. In a voluntary world that was sensible. Under a national mandate it was incoherent, because a Member State could not compel electronic issuance while the directive handed every buyer a veto over receiving one.
The directive removes that precondition where invoicing is mandated. In practice the supplier no longer has to record and honour a customer's stated preference for paper, and the clause in supplier terms about delivery method quietly loses its function.
The end of the acceptance requirement does not by itself oblige a buyer to be capable of receiving a structured invoice. That duty comes from national law, and in several Member States the obligation to receive has already arrived ahead of the obligation to issue. Check the national instrument, not the directive.
Member States no longer need a derogation
The second change is the more consequential one, and it explains why the mandate map filled up so quickly. Requiring domestic electronic invoicing previously meant obtaining a special measure derogating from the invoicing rules — the route through Article 395 and the special measures procedure, with a Commission proposal, a Council decision and an expiry date attached to whatever was granted.
That requirement no longer applies to domestic e-invoicing mandates. A Member State that wants structured invoicing between established taxable persons can legislate for it directly. This is the provision that most changes a multinational's planning horizon, because it turns a queue of applications with known lead times into a set of national timetables that move independently of one another and of Brussels. The result is visible in the map of national mandates, which has grown faster since the directive than in the decade before it.
What a digital reporting requirement is, precisely
A digital reporting requirement is an obligation to transmit a defined set of data about individual transactions to the tax administration, on a schedule tied to the transaction rather than to a return period. It is not an invoicing mandate, although the two are increasingly delivered through the same pipe and are routinely confused in consequence.
The separation is set out at length in the difference between issuing an invoice and reporting one, and the directive keeps them apart too. An invoicing mandate governs the document passing between seller and buyer. A reporting requirement governs a second flow, from the taxable person to the administration, whose content is derived from that document but whose purpose is control.
Three properties define the obligation the directive creates.
- It is transaction by transaction. Not a period total and not a customer total. Each supply is reported as its own record, identified as such.
- It is derived from the invoice. What is reported is a subset of invoice data, which is why the reporting obligation carries an invoicing obligation with it rather than sitting beside one.
- It is bilateral. The supplier reports the supply and the acquirer reports the acquisition. Two records describing one transaction reach two administrations and are matched against each other.
The third property is the one with teeth. A system holding both sides of a transaction can detect a mismatch without asking anybody a question, and without waiting for an audit cycle to come round.
The recapitulative statement, and what replaces it
For intra-Community transactions the existing control instrument is the recapitulative statement: a periodic listing of supplies by customer VAT identification number, filed after the fact, aggregated, and compared centrally with the corresponding listings filed elsewhere.
Its weaknesses are structural rather than administrative. It aggregates, so it cannot say which transaction caused a discrepancy. It is periodic, so the data is old before it can be compared. And it is built around supplies rather than acquisitions, so one side of the matching exercise is inferred rather than reported.
The digital reporting requirement replaces it, for the transactions it covers, with transaction-level data transmitted close to the time of issue from both parties. Member States pass what they receive into a central system, so the matching happens against a common data set instead of through bilateral enquiry between administrations. The administrative cooperation regulation adopted alongside the directive is what makes that central handling lawful; it is the least discussed instrument in the package and the one that determines what the data is actually used for.
The obligation stops being a return you prepare and becomes a consequence of issuing an invoice. There is no filing window in which to correct the underlying data, because there is no filing.
That is worth reading twice if your current month-end involves somebody fixing customer VAT numbers, correcting a treatment or moving a transaction into the right period before the listing goes out. That review has nowhere left to happen.
The convergence constraint
The most underrated provision in the package is not an obligation on business at all. It is a constraint on Member States.
Before the directive, a Member State building a domestic reporting regime could design whatever it liked, and did. The results are why this field is hard: a national XML schema in one country, a real-time invoice data feed in another, a clearance platform in a third, each with its own data model, its own identifiers and its own view of what a credit note is.
The directive closes that door. Domestic digital reporting has to be built on electronic invoices complying with the European semantic standard and the syntaxes it names, with the reported data drawn from the same model. There is room left for other standards in purely domestic use, subject to conditions, but the direction of travel is fixed: national regimes converge on the European model rather than diverging further from it.
Note what this does not do. It does not settle the architecture. A Member State may still put every invoice through a platform, or leave the document to travel between the parties while a report goes to the administration separately. Those choices — laid out in four-corner and five-corner architectures — stay national. What is being made common is the content of the document and of the report, not the plumbing.
For a group with entities in several Member States that is the difference between a mapping problem and an addressing problem. Mapping problems compound with every country added. Addressing problems do not.
If you already report under a national regime
Several Member States have been running domestic transaction reporting for years. Those regimes do not vanish, and the businesses inside them do not get a pause.
The directive gives national systems that were already in operation a transitional period, at the end of which they must be brought into line with the European model. That is a long runway, and it is not indefinite. If your Hungarian entity has been filing under real-time invoice reporting since that regime began, the change ahead is not a new obligation but the replacement of the data model underneath an obligation you already meet.
That replacement is harder than it sounds, for reasons that have nothing to do with technology. A regime that has run for years accumulates local practice: the way a particular adjustment is reported, the field everyone populates with a value the specification never anticipated, the exemption coded one way because the administration's validator once refused the other. None of that survives a change of data model, and almost none of it is written down anywhere.
Zero-rated and exempt supplies. Every national regime has developed its own way of expressing why VAT was not charged, and moving to the European model means moving to its code list and its evidence expectations. The general shape of the problem is in exemption reason codes and what they have to be backed by.
The staged calendar, and how to read it
- 2022-12-08The Commission publishes its VAT in the Digital Age proposal: three instruments amending the VAT Directive, the administrative cooperation regulation and the VAT implementing regulationproposed
- 2025-03-11The Council adopts the three instruments; the directive enters into force twenty days after publication in the Official Journal, and the invoicing provisions apply from entry into forcein force
- 2027-01-01The first of the staged application dates in the directive; the measures concerned lie outside the reporting pillaradopted
- 2028-07-01Further measures in the single registration pillar apply, and the deemed supplier treatment for short-term accommodation and passenger transport becomes available to Member States as an optionadopted
- 2030-01-01The deemed supplier treatment for those platform services ceases to be optionaladopted
- 2030-07-01Digital reporting applies to intra-Community transactions, and the recapitulative statement is replaced for the transactions coveredadopted
- 2035-01-01Domestic reporting regimes already in operation must be brought into line with the European modeladopted
Every entry here is a staging point in an adopted instrument, not a proposal. The calendar was nonetheless amended during negotiation, and which provision applies from which date sits in the transitional articles of the directive. Read those before you commit a project plan to a date.
Two habits follow from that table. The first is to stop quoting a single year for the package, because no such year exists. The second is to notice that the two dates most likely to affect you are the earliest and the latest: entry into force, which released the national mandates, and the convergence deadline, which decides how long your existing national build survives.
What the reporting pillar actually asks of a finance function
- Which entities make intra-Community supplies or acquisitions at all, and in which Member States each is established or registered
- Whether customer VAT identification numbers are validated at the point of sale rather than at the point of filing
- Which of your current adjustments are made after invoicing and before filing, since those are the ones that will have nowhere to go
- Whether your national reporting today is produced from the invoice or from the ledger, and what the difference between the two currently amounts to
- Who reads a rejection, on which day, with what authority to correct and reissue
The last item decides more outcomes than any of the others. A reporting obligation derived from the invoice produces errors asynchronously, and an error that nobody is rostered to read is an error that stays in the administration's data set with your name on it.
What actually decides the outcome
The obligation the directive creates is not difficult to describe and not technically demanding. What makes it expensive is that it removes a buffer. Today the invoice goes out, the ledger is posted, and somewhere between them a person reconciles the two before anything is filed. Transaction-level reporting takes that person out of the sequence, leaving the reconciliation to be done afterwards against data the administration already holds — which is a different discipline with different tooling, set out in reconciling what you reported against what you posted.
None of that turns on a date. The provisions that removed the acceptance precondition and the derogation requirement are already in force, and the national mandates they unlocked are arriving on national timetables that owe nothing to the European reporting calendar. A business waiting for the intra-Community obligation before starting has misread which part of the package was aimed at it.
The work is the same work in every regime: master data that is right at the moment of issue, an invoice that agrees with the ledger, a code list that reflects the treatment rather than the validator's tolerance, and somebody watching the exception queue with the authority to act. That inventory is what a readiness assessment produces, and it is worth having whether your next deadline comes from your own Member State or from the directive.
