VAT in the Digital Age

A route to comply with the mandate without building a central store of every transaction.

VAT in the Digital Age, ViDA, is law. The EU Council adopted Council Directive (EU) 2025/516 on 11 March 2025, and it entered into force on 14 April 2025. For intra-EU cross-border business-to-business transactions, structured e-invoicing and digital reporting apply from 1 July 2030. Platform and single-registration measures arrive in 2028, and the wider rollout runs through to 2035. The question for a tax administration or a finance team is no longer whether to comply. It is how the compliance architecture is built, and what that choice does to the data that flows through it.

2030

Real-time digital reporting for intra-EU transactions applies from 1 July 2030.

Council Directive (EU) 2025/516

What ViDA actually asks

ViDA reforms the EU VAT Directive. From 1 July 2030, cross-border intra-EU B2B invoices must be issued as structured e-invoices in the EN 16931 format, with the transaction data reported to the national tax authority close to the moment of issuance. Reporting is decentralised by design, and there is no single EU endpoint. Each of the 27 member states operates its own portal or interface, and a business reports to its own authority. Since the directive entered into force, member states may also mandate domestic e-invoicing without first obtaining an EU derogation.

Across the Union that adds up to billions of structured invoices each year, each carrying line-level detail, and each retained for the statutory periods that VAT law already requires, which run to years. The European Commission put the EU VAT gap at €128 billion for 2023. Closing that gap is the stated purpose of the reform, and real-time digital reporting is the instrument.

Those are the facts of the mandate. What they leave open is where the data lives once it has been reported, and who can read it.

What Peppol does, and what it does not

Peppol is the network most European e-invoicing runs on. It is worth being precise about its scope, because it is often assumed to cover more than it does.

What Peppol delivers

  • Standardised transport of invoice messages (UBL documents over the AS4 protocol)
  • Validation that a message is structurally valid
  • Broad adoption across the Netherlands and the wider EU
  • Predictable semantics between trading partners

What Peppol does not set out to do

  • Bind the sender's identity to the message at a cryptographic level
  • Keep the invoice content private from the receiving authority
  • Provide a non-repudiable audit trail for inspection after the fact

None of this is a criticism of Peppol. A transport network moves messages reliably. Identity, confidentiality and long-term audit sit above the rails, not inside them.

Three gaps in centralised reporting

When digital reporting is built as a central collection of invoice data, three gaps tend to appear in the architecture. Each is a design choice rather than a requirement of the law.

Content disclosure as the default. A reporting system that collects full invoice descriptions in order to check VAT does so on a pre-cryptographic assumption. The correctness of a VAT calculation, the right rate on the right amount, can be proven without handing over the description of what was sold.

Identity that is not cryptographically bound. A message on a transport network has a sender at the network level, not a non-repudiable identity at the level of the message itself. Where that binding is missing, patterns such as carousel fraud become visible only in aggregate, after the fact, at the centre. The identity layer ViDA leaves open is being filled elsewhere in EU law: under eIDAS 2 (Regulation (EU) 2024/1183), every member state must offer at least one European Digital Identity Wallet by the end of 2026, which makes attributable, signed transactions possible.

Long retention as an architecture choice. Holding large volumes of invoice records for years, in one place, is a decision about architecture. It widens the window in which the data can be misused, and it does so independently of the compliance goal it is meant to serve.

The missing layer: privacy-enhancing technologies

Each of those gaps has an answer in privacy-enhancing technologies (PETs). PETs are not a single tool. Three families matter here, and each one closes a gap without a central database.

Signed capture. Every transaction leaves a signable proof that it happened: between which verified parties, at which moment, under which tax parameters. The proof travels, and the content does not have to.

Selective disclosure. A business can demonstrate that the VAT is correct, at the right rate and on the right amount, without revealing the invoice lines behind it. The claim is verifiable for an inspector, and the underlying detail stays with the business.

Attribute-blind monitoring. An authority can see patterns and outliers across aggregated flows without the identity of sender or receiver attached, unless it is requested in a targeted and authorised way. Inspection stays as sharp as it is today, without the bulk store underneath it.

This is the layer the compliance-audit fundament is built on, applied to the specific shape of a VAT reporting obligation.

Two architectures, side by side

Centralised reporting

  • Message transport

    National channel per member state

  • Identity to message

    At the network level

  • VAT validation

    Content disclosed to the authority

  • Audit

    Central database, after the fact

  • Retention

    Central, held for years

  • Inspection

    Bulk analysis

Reporting with a PET layer

  • Message transport

    Peppol BIS (UBL over AS4)

  • Identity to message

    Cryptographically, at the message level

  • VAT validation

    Selective disclosure per transaction

  • Audit

    Cryptographic trail, retrieved where needed

  • Retention

    Proof held at the source, provable later

  • Inspection

    Targeted, with authorisation

Where this is being built

None of this is theoretical. The same fundament is being explored across four domains with the Netherlands Tax Administration. Each carries an honest status.

  • VAT (Tax Splitter). Pilot / R&D. A working prototype, developed and tested with the Netherlands Tax Administration in an R&D setting, with market parties participating in trials.

  • Gambling tax. R&D. An R&D track exploring real-time database audit for gambling tax.

  • Construction. Proposal. A proposed application: continuous permanent-establishment detection.

  • Agentic commerce. Horizon. Agent-mandate-bound transactions, on the horizon and never a current capability.

The full picture, with each application on its own status pill, sits on the domains page.

The architecture question, in one line

Storing billions of invoices, with line descriptions, for years, in 27 separate national systems is an architecture decision, not a compliance requirement.

Comply with the mandate, not an alternative to it

This is a way to meet ViDA, not a way around it. The reporting obligation is satisfied in full. The structured invoice is issued, the data reaches the national authority, and what was reported can be shown at any later date. The difference is only in where the data rests afterwards. It stays at the source, with the business that created it, rather than in a copy held somewhere else for years.

The architecture choices are being made now. What gets built to meet the 2030 deadline becomes the architecture everyone lives with afterwards. Choosing deliberately, while there is time, is the difference between compliance that proves what happened and compliance that quietly accumulates a second copy of everyone's commercial life.

Evidence does not have to mean exposure. From more data after the fact to more certainty up front.

Related. Real-time-taxation-by-country tracker for where the mandate stands market by market, including the EU ViDA timeline. Read Tax Administration 3.0, the OECD policy frame this fits into. Definitions: real-time reporting, selective disclosure, privacy-enhancing technologies.

Official sources. VAT in the Digital Age (European Commission) · Council Directive (EU) 2025/516 (EUR-Lex) · Regulation (EU) 2024/1183, eIDAS 2 (EUR-Lex)

A public protocol, designed and integrated by mintBlue in collaboration with the Dutch Tax Administration.