ViDA compliance: architecture before vendor selection

ViDA compliance: architecture before vendor selection

Most ViDA (VAT in the Digital Age) conversations start in the wrong place. The first question is usually which tool to buy: Pagero Sovos, Avalara, Vertex, a local provider, or whether the ERP can handle it natively. The deadline follows shortly after. The question that actually de-risks the programme is different: what exactly are we changing, and where does that change sit in our architecture?

ViDA is easy to file mentally under “tax project” or “e-invoicing initiative.” Neither framing captures the full scope. Overlay ViDA-impacted capabilities on a finance capability map and the real footprint becomes visible almost immediately. The impact extends beyond invoicing into Accounts Receivable, Accounts Payable, Indirect Tax Compliance, Tax Transactions & Advisory, Regulatory Reporting, Intercompany Transactions, and the data and integration layers underneath all of them.

That breadth is why organizations should approach ViDA as an architecture transformation rather than a vendor selection exercise.

The three ViDA reforms and their architectural footprint

ViDA consists of three major reforms, each affecting different parts of the enterprise landscape.

Digital Reporting Requirements and e-invoicing

From 1 July 2030, intra-EU B2B transactions will be subject to mandatory digital reporting requirements supported by structured electronic invoicing based on the European EN 16931 standard. The scope of change runs well beyond billing templates. It affects VAT determination, invoice generation, validation, transmission, acknowledgement handling, corrections processing, inbound receipt and matching on the AP side, reporting, and long-term archiving. The end-to-end process spans multiple capabilities, applications, data domains, and integration points.

Platform economy and deemed-supplier rules

From 1 July 2028, new platform economy measures begin to shift VAT obligations towards digital platforms in specific sectors, particularly accommodation and passenger transport. The underlying challenge is architectural: determining liability correctly, maintaining auditable transaction data, and reporting consistently across jurisdictions.

Single VAT Registration

Also from 1 July 2028, the expansion of Single VAT Registration Mechanisms further reduces the need for multiple VAT registrations across Member States. For many organizations, this changes registration logic, cross-border transaction processing, reverse-charge determination, and reporting obligations.

Why the 2035 milestone matters more than it looks

The final milestone is often overlooked. By January 2035, existing domestic digital reporting and e-invoicing regimes across the EU must align with the common European framework. Organizations designing purely for the 2030 requirements risk optimizing for an interim state rather than the longer-term target architecture. The regulatory milestones define the waypoints, but the architecture should be designed around the destination.

Why ViDA vendors define the problem differently

One reason ViDA vendor evaluations often become confusing is that vendors define the problem boundary differently. Some approach ViDA primarily as a compliance network problem, focusing on connectivity to tax authorities and trading partners. Others lead with tax determination and VAT logic. Some specialize in continuous transaction controls and clearance models; others focus on reporting and filing obligations. ERP vendors typically cover parts of the process natively while relying on partners for the remainder.

These approaches solve different parts of the same problem. Without a neutral architectural reference, organizations end up comparing one vendor’s definition of “ViDA coverage” against another’s, and the gaps that matter most rarely surface in product demonstrations. Questions like these are architectural decisions long before they become procurement decisions:

• Which system owns invoice data?
• Where is tax determination performed?
• How is localization managed across Member States?
• Which application becomes the source of truth?
• How are exceptions handled?
• Where does compliance evidence live?

Two solutions can both claim to support e-invoicing while fundamentally disagreeing on ownership of master data, transaction data, and reporting responsibilities. That disagreement is often where future reconciliation effort and operational complexity originate.

The integration architecture most ViDA programs underestimate

Many ViDA programs focus on business processes, applications, and data, and treat integration as secondary. That is usually where the complexity catches up with them. A typical future-state landscape introduces new interactions between ERP platforms, tax engines, e-invoicing networks, Peppol access points, reporting platforms, archiving solutions, and master data services.

Moving data between systems is the straightforward part. The harder decisions are where orchestration occurs, how monitoring is performed, how exceptions are handled, and who owns the resulting compliance data throughout its lifecycle. The integration pattern selected today will often outlive the initial ViDA implementation by years.

What an enterprise architecture lens actually delivers

This is why we approach ViDA as an architecture decision first. Using a capability map together with business, application, data, integration, and technology views creates a neutral frame that does not belong to any vendor. Working from that frame, four things become clearer.

Scope honestly

Overlaying the impacted capabilities makes the true footprint visible: not just invoicing, but also accounts payable, reporting, tax, data governance, and integration management.

Map coverage, not marketing

Assessing vendors against capabilities, processes, and information objects rather than product claims makes gaps, overlaps, and hand-offs visible. “ViDA compliant” stops being a checkbox.

Protect the data layer

Deciding deliberately where invoice, tax, and reporting objects are mastered, and which systems act as sources of truth, prevents those decisions from emerging accidentally through tool selection.

Sequence to de-risk

Planning along the regulatory milestones of 2028, 2030, and 2035 enables incremental delivery, limits rework and keeps future options open.

Vendor selection becomes a genuinely clean exercise only once those decisions are made. At that point, organizations are matching defined target capabilities against solution coverage, determining where to buy, build, or configure, and selecting partners against an architecture they own.

VAT in the Digital Age: treat it as a financial architecture change

VAT in the Digital Age introduces hard regulatory deadlines, which creates a natural temptation to treat it as a procurement exercise. Organizations that treat it as a change to their financial architecture tend to spend less, encounter fewer surprises, and keep more options open than those that start with the shortlist.

The tooling matters enormously, and the architecture determines whether it serves as an accelerator or becomes tomorrow’s constraint. A vendor shortlist is a necessary step. Arriving at it with a defined architecture already in place is what separates a well-sequenced program from an expensive discovery process.

At 2-cnnct we take a platform- and vendor-neutral approach, starting with capabilities, architecture, and ownership before discussing solutions. By understanding the impact of ViDA across business, application, data, integration, and technology domains, organizations can make tooling decisions that support a deliberate target architecture rather than accidentally defining it.

Let’s talk about your ViDA architecture

If you recognize the challenges described here and want to get ahead of the deadlines, we are happy to help you map it.