ViDA is coming: what it is, and the privacy-friendly way to comply

Cross-border intra-EU B2B VAT reporting goes live on 1 July 2030. That date is not a consultation paper or a draft directive. It is law.

The EU Council adopted ViDA, VAT in the Digital Age, on 11 March 2025. It entered into force on 14 April 2025. The rollout runs in phases through to January 2035. If your company issues invoices across EU borders, sells through digital platforms, or operates in markets that run their own domestic e-invoicing regimes, ViDA reaches you. The question is not whether to comply. It is how you build your compliance architecture, and what that choice costs you in data: control, confidentiality, and the ability to leave.

That second question is the one many finance and IT teams have not asked yet.

ViDA is a reform of the EU VAT Directive. It has three pillars.

The first is Digital Reporting Requirements, or DRR. From 1 July 2030, structured e-invoices for cross-border intra-EU B2B transactions must be issued in EN 16931 format within 10 days of the chargeable event, with the data reported to your national tax authority at the moment the invoice is issued. The structured data travels with the invoice, or as part of it, from the moment it is created. Domestic regimes across member states are expected to harmonise with these requirements by 2035. And since ViDA entered into force, member states may mandate domestic e-invoicing without first obtaining an EU derogation, which is exactly what several governments are now preparing.

The second pillar covers the Platform Economy. Digital platforms facilitating short-term accommodation and passenger transport will be treated as deemed suppliers for VAT in more circumstances, with new reporting obligations attached.

The third is Single VAT Registration: an extended One-Stop Shop that lets businesses register in one member state and account for VAT across the EU, rather than registering separately wherever they sell.

For most finance and IT teams, DRR is the pillar that changes your data architecture. Real-time reporting at the moment of issuance, structured invoice data, machine-readable from the moment it is created. That is a very different operating model from the quarterly and annual filings most teams run today.

The description of ViDA gets muddier in most coverage, and the architecture question starts to matter.

ViDA's reporting transmission layer is decentralised. Each member state operates its own portal or API. You report to your national tax authority. There is no single EU submission endpoint. That part of the design is distributed by intent.

But the data does not stay distributed.

Transaction data reported to national authorities feeds into a revamped Central VIES database maintained by the European Commission. That database is integrated with the EU Customs Surveillance System and with CESOP, the Central Electronic System of Payment Information, which already aggregates cross-border payment data from payment service providers across the EU.

In practice, you report your invoice data to your national authority, and that transaction and payment data is then pooled at the EU layer. ViDA does not force every company to pipe data into one central system at the transmission layer, and it would be wrong to claim otherwise. What it does build is a centralised view of European commercial transaction flows, assembled from the national reporting feeds, and integrated with customs and payment surveillance.

That is a meaningful distinction, and it matters for how you think about the second exposure.

The bigger risk is not just what sits in the central EU layer. The bigger risk is what each business builds on its own side to comply. To produce structured, machine-readable invoice data at the point of issuance and report it within two days, most organisations need to pull data out of their ERP or accounting system and route it through a compliance pipeline. If that pipeline deposits a copy of your order book, your customer master data, or your pricing in a third-party system or a centralised reporting service, you have created a secondary store you did not plan for and probably cannot audit.

That store does not disappear when the reporting window closes. It sits somewhere, under someone else's security posture, until something goes wrong.

The finance-software industry is uneasy. Vendors building accounting and compliance tools are working through how to handle real-time obligations without turning their platforms into something their customers will regret.

The tension is built into the requirement. Real-time reporting requires real-time access to transaction data. The obvious engineering shortcut is to centralise that data first: pull everything into one place, then query it, then report it. Clean pipelines, simple queries, easy to test.

The shortcut works. The problem is that your entire transaction history, your customer relationships, your commercial terms, and your pricing now sit in a copy that lives outside your direct control. You built it to meet a compliance requirement. What you actually built is a shadow of your order book, held by a third party, indefinitely.

That looks manageable in a sprint review. It looks very different two years later, when the store gets breached, subpoenaed, or transferred to an acquirer you did not choose.

The temptation is understandable. The cost is real. And the companies that default to it will not realise the cost until they try to get the data back. This is the moment to separate compliance from overcollection.

There is a different architecture, and it does not require you to pool your transaction data anywhere.

Every business seals its own envelope at home. The postman picks it up, delivers it to the tax authority, and never once opens it. There is no intermediary who reads the contents, holds a copy, or aggregates your data alongside your competitors'. The keys never leave your hands. The delivery is peer-to-peer. The audit trail is provable without involving anyone in the middle.

Data at source means the structured invoice and the tax-relevant data are created and signed inside your own systems, at the point of origin, and delivered directly. The reporting obligation is met. What you do not do is hand a copy of your commercial data to a pipeline that now holds it indefinitely.

This is not a workaround, and it is not an alternative to ViDA. You comply with ViDA. The architecture is simply the privacy-friendly way to do it. You report exactly what the law requires, you can demonstrate what was reported and when, and you stay in grip of your own data throughout. Evidence does not have to mean exposure.

At mintBlue, this is the model we have been developing in R&D and pilot work with tax authorities. The data stays at source, the reporting still happens, and the audit trail exists. Nobody sits in the middle accumulating a copy of your commercial book.

Every time a new compliance layer arrives, the first question is integration cost. Nobody budgets to rip out an ERP to meet a tax reporting deadline.

This architecture does not ask you to. It runs alongside your existing accounting and ERP systems. Step by step, every phase its own go or no-go. A complement to the systems you already operate, not a replacement for them.

ViDA's own phasing gives you the runway to build incrementally. Voluntary simplification measures arrive in 2027. Platform and single-registration measures follow in 2028. Cross-border B2B reporting goes live on 1 July 2030. Domestic harmonisation completes by 2035. Each phase is a decision point, not a cliff edge. Each phase is a chance to extend your compliance infrastructure one layer at a time rather than committing to a big-bang migration that locks you into a data store you cannot get out of.

The companies that manage this well will be the ones that made the architecture choice deliberately, before 2030, when they had time to think.

The 2030 deadline feels distant. It is not. Large ERP projects routinely take two to three years. Compliance testing with national tax authorities requires lead time. And the organisations that wait for every implementation detail to crystallise will be choosing under deadline pressure, which reliably produces the central-store shortcut.

A deliberate choice looks like this. Map your cross-border B2B transaction flows. Identify where invoice data is created, which systems it passes through, and where a ViDA compliance pipeline would need to connect. Then ask the specific question: if we build our reporting stack today, where does our transaction data live after reporting, and who controls it?

If the answer is "in a third-party system we do not own," that is worth interrogating before you commit budget.

ViDA is a mandate. You will comply. The only real choice is how you comply, and what you hand over to get there. An auditor might ask you, today, exactly where a copy of last quarter's cross-border transaction data sits.