ViDA modernises EU VAT with structured e-invoicing and near real-time reporting. From 1 July 2030, all intra-Community B2B invoices must be issued as structured e-invoices compliant with EN 16931 and digitally reported to tax authorities. By 1 January 2035, Member States with existing domestic reporting systems must also align them with the EU standard. Countries may use different architectural models to meet these requirements, as ViDA does not mandate the use of one single platform. Here are the main models.
Understanding ViDA’s e-invoicing and digital reporting requirements
ViDA does not impose a single technical network, platform, or exchange infrastructure. Instead, it harmonises the move toward structured e-invoicing and Digital Reporting Requirements (DRR) for intra-Community transactions. While the cross-border mandate takes effect on 1 July 2030, Member States remain free to introduce domestic e-invoicing obligations on their own timelines — and many have already done so. EU Member States may implement these obligations through different architectural models, including EN 16931 is the European standard for the semantic data model of electronic invoices.
EN 16931 was originally developed for public procurement under Directive 2014/55/EU, it defines a common set of business terms and rules that structured e-invoices must follow. Under ViDA, EN 16931 is elevated from its B2G origin to become the required format for cross-border B2B e-invoicing across the EU. While EN 16931 provides a harmonised baseline, Member States may define Core Invoice Usage Specifications (CIUS) — national customisations that add country-specific rules or constraints on top of the European standard. Examples include Germany’s XRechnung, Italy’s FatturaPA, and Portugal’s CIUS-PT.
Under the new DRR rules, e-invoices for intra-Community transactions must be issued within ten days of the chargeable event — a significant tightening from the current deadline of the 15th of the month following the supply. The same ten-day window applies to reporting the transaction data to the seller’s national tax authority. These near real-time obligations replace the existing EC Sales Listing regime. It is important to distinguish between e-invoicing and e-reporting, as ViDA introduces obligations for both. E-invoicing refers to the exchange of structured invoices between businesses. E-reporting refers to the transmission of invoice data to tax authorities. Some of the models below address only the exchange flow, while others integrate reporting into the same infrastructure. Where a model does not include built-in reporting, a separate reporting channel is typically required.
Main e-invoicing models under ViDA
Centralised Exchange Model
In this model, a single government-run platform sits at the centre of all invoice flows. A single national platform serves as the mandatory infrastructure for invoice submission, validation, routing, and — in some cases — archiving. The supplier sends the invoice to the central platform, which validates its format and content, registers it, assigns a unique identifier, and then delivers it to the buyer. Only invoices successfully processed by the platform are considered legally valid. Italy’s Sistema di Interscambio (SdI) and Poland’s Krajowy System e-Faktur (KSeF) are the leading examples of this model in the EU.
Typical flow:
Decentralised Exchange Model
In this model, businesses exchange invoices directly — without routing them through a government platform. Invoices are exchanged directly between the supplier and buyer, either through their own systems or through private service providers. There is no single government platform controlling the invoice exchange. If tax reporting is required, it is usually handled through a separate reporting channel. In decentralised models, hybrid invoice formats play a significant role. Formats such as ZUGFeRD (Germany) and Factur-X (France) embed a structured XML data file within a human-readable PDF. These hybrid invoices are valid under ViDA and EN 16931, provided the structured data layer contains all required fields — the PDF component alone does not satisfy the e-invoicing requirement.
Typical flow:
Peppol Four-Corner Model
This model uses the Peppol network to connect businesses through certified Access Points, without government involvement in the delivery flow. The supplier connects to a sending Access Point, and the buyer connects to a receiving Access Point. The two Access Points exchange the structured invoice using Peppol rules and standards. The tax authority is not part of the standard invoice delivery flow.
Typical flow:
Peppol Five-Corner / Peppol CTC Model
This model extends the Peppol four-corner flow by adding a government platform for tax reporting or invoice clearance. In some implementations, the government platform validates, approves, and registers the invoice before it continues through the Peppol network to the receiver — effectively introducing a clearance step within the decentralised Peppol infrastructure. In other implementations, the government platform acts primarily as a data repository, receiving invoice data from the Access Points without intervening in the delivery flow. Belgium’s planned e-reporting model (from 2028) is an example of the latter approach, while France’s use of Peppol CTC incorporates elements of the former.
Typical flow:
Y-Model / Accredited Platform Model
In this model, accredited private platforms handle both the invoice exchange between businesses and the transmission of data to the tax authority. Businesses exchange invoices through certified or accredited private platforms. These platforms handle the invoice exchange between supplier and buyer and also transmit the required invoice data, status updates, or reporting information to a public platform or tax authority. This model uses private platforms for exchange and a public authority layer for oversight. France’s architecture, using the Portail Public de Facturation (PPF) as the public platform and Plateformes de Dématérialisation Partenaires (PDP) as accredited private platforms, is the leading example.
Typical flow:
Hybrid Exchange Models
This model reflects the reality in many countries, where different channels and platforms coexist for different transaction types. A country may use one model for B2G, another for B2B, and a separate reporting or fiscalisation system for B2C. Hybrid models are common where older B2G platforms, new B2B mandates, Peppol networks, and tax reporting systems coexist.
Typical flow:
