E-Invoicing & E-Reporting Explained: What’s “Sent” vs What’s “Reported”

This briefing document outlines the critical distinction between e-invoicing and e-reporting, two complementary but fundamentally different digital tax compliance obligations dominating current and future global tax landscapes. While both draw from transactional data, e-invoicing concerns the structured exchange of a complete invoice document between trading partners for commercial purposes, whereas e-reporting involves transmitting a defined data extract from that transaction to the tax authority for VAT monitoring and fraud prevention. Misunderstanding this distinction carries significant risks, including non-compliance, system architecture flaws, and potential penalties. The relationship between “what’s sent” (the e-invoice) and “what’s reported” (the data extract) varies across different country models, ranging from full clearance where the invoice is the report, to parallel data flows where the two obligations are entirely separate. The EU’s ViDA initiative aims for future harmonization, but businesses must navigate the current complexities to ensure robust compliance.

II. Main Themes and Key Ideas

A. The Fundamental Distinction: Document vs. Data

The core concept is that an e-invoice is a complete document, while e-reporting is an extract of data derived from or related to a transaction. The source clearly states: “e-invoicing is about exchanging a structured invoice document between trading partners, while e-reporting is about transmitting a data extract from that invoice (or transaction) to the tax authority — they are not the same thing, even when they share the same source data.”

• E-Invoicing: “What is Sent”
• Purpose: Primarily commercial – to trigger payment, allow buyers to book purchases, and enable input VAT deduction.
• Nature: A complete, structured, machine-readable document (e.g., UBL, CII, Factur-X) replacing traditional paper or PDF invoices.
• Content: Contains all information required by VAT legislation (e.g., Article 226 of the EU VAT Directive) and often much more, including: header data (invoice number, date, due date), seller/buyer data (name, address, VAT ID), line items (descriptions, quantities, prices, discounts, VAT), totals, references (PO number), and sometimes attachments.
• Recipient: Sent to the business counterparty (the buyer).
• Government Involvement: In clearance models (e.g., Italy’s SDI, Poland’s KSeF), the invoice is routed through a government platform for validation before delivery to the buyer, meaning the tax authority sees the full invoice as a “by-product.” In post-audit models, the invoice goes directly from seller to buyer, with no direct tax authority involvement unless audited.
• E-Reporting: “What is Reported”
• Purpose: To give tax authorities “near-real-time visibility into economic activity, enabling faster VAT gap detection, cross-checking of declared returns against actual transaction volumes, pre-filled VAT returns, and reduced fraud.”
• Nature: A digital submission of structured transaction data to the tax authority. It is “not about sending an invoice.”
• Content: A defined subset of data fields, typically including: Seller/Buyer VAT ID, Invoice number and date, Taxable base (net amount), VAT rate(s) and amount(s), Transaction type/nature code (often an enrichment), Currency, and Credit note indicator.
• Distinction from E-Invoice: Significantly, e-reporting usually excludes detailed commercial information such as line-item descriptions, quantities, unit prices, payment terms, IBAN/bank details, purchase order references, delivery addresses, and embedded PDF attachments.
• Data Enrichment: Crucially, the reporting dataset is not always a pure subset. It may require fields not present on the invoice itself, such as:
• Transaction type codes (e.g., France’s B2B, B2C classification).
• Payment status data (e.g., France’s “encaissement” for services).
• Expense classifications (e.g., Greece’s myDATA).
• Nature-of-goods fields (discussed for ViDA’s DRR). This means the reporting data is “derived from the invoice, enriched with additional context, and formatted according to the tax authority’s specifications.”

B. The Data Transformation Pipeline

The journey from a commercial invoice to a reporting dataset involves several distinct steps:

1. Invoice Creation: Generation of the invoice in the seller’s system.
2. Structured Format Generation: Mapping invoice data into an e-invoice format (e.g., UBL). This is the e-invoice “sent” to the buyer.
3. Data Extraction: A subset of fields is extracted from the structured e-invoice. This can occur within ERP systems, middleware, or certified platforms.
4. Data Enrichment: Additional, non-invoice fields required for reporting are added (e.g., transaction type codes).
5. Format Transformation: The extracted and enriched data is converted into the specific reporting format required by the tax authority (often a different XML schema, JSON, or API call).
6. Transmission: The reporting dataset is submitted to the government platform, either in real-time, within a short window, or in periodic batches.

C. Spectrum of Models for E-Invoicing and E-Reporting

Countries implement these obligations in various ways, forming a spectrum of integration:

• Model A: The Invoice IS the Report (Clearance Models)
• Example: Italy (SDI), Poland (KSeF).
• Description: The structured e-invoice is routed through a government platform, which validates it and delivers it to the buyer. The tax authority receives the complete invoice as part of this process, fulfilling both commercial and reporting needs simultaneously.
• Relationship: “What’s sent = What’s reported (the full invoice document).”
• Model B: The Report Is Extracted FROM the Invoice (Hybrid Models)
• Example: France (Y-schema).
• Description: Certified platforms receive the full e-invoice, deliver it to the buyer, and simultaneously extract VAT-relevant data to transmit to the tax authority.
• Relationship: “What’s sent ≠ What’s reported (but they share the same source data, with automatic extraction for e-invoiced transactions).” This model also features separate e-reporting for transactions outside e-invoicing scope (B2C, cross-border).
• Model C: The Report Is a Parallel Data Flow (Real-Time Reporting Models)
• Example: Hungary (RTIR), Spain (SII), Greece (myDATA).
• Description: The reporting obligation exists independently of any e-invoicing mandate. Businesses issue invoices (which may or may not be structured e-invoices) and separately submit transaction data to the tax authority.
• Relationship: “What’s sent (the invoice) and what’s reported (the data) are separate flows, even though they describe the same underlying transaction.”
• Model D: The Report Covers What the Invoice Does Not (Gap-Filling Models)
• Example: France’s e-reporting for B2C and cross-border transactions.
• Description: These transactions are not subject to e-invoicing but require separate e-reporting of aggregated daily totals or individual transaction records.
• Relationship: “What’s reported has no corresponding ‘sent’ e-invoice — the report stands alone.”

D. Practical Implications and Why the Distinction Matters

Treating e-invoicing and e-reporting as identical processes leads to significant risks:

• System Architecture & ERP Design: Businesses risk building systems that “either over-report (sending full invoices where only data extracts are required) or under-report (missing mandatory reporting fields that are not on the invoice), leading to rejection, penalties, or failed VAT returns.” Separate data mappings, validation rules, and transmission channels are often required for each obligation.
• Data Quality and Completeness: If reporting requires data not on the invoice (enrichment fields), these must be captured and maintained outside the standard invoice workflow.
• Multi-Country Compliance: Businesses operating across jurisdictions must manage multiple models simultaneously (e.g., Italy’s clearance, France’s hybrid, Hungary’s parallel reporting).
• ViDA and EU-wide Digital Reporting Requirements (DRR): Effective from July 1, 2030, ViDA mandates structured e-invoicing for cross-border B2B transactions and reporting of this data to national tax authorities, which then feed VIES. This model aligns closest with Model B (hybrid), where the e-invoice is the source for derived reporting data. However, specifics like “nature-of-goods” codes and handling of reverse charges are still under debate, highlighting ongoing complexities.
• The “Reporting Gap” Risk: The source warns against the “most dangerous misunderstanding… assuming that if you e-invoice, you have automatically reported.” This is true only in full clearance models. In many others (e.g., Spain’s SII, Hungary’s RTIR), separate reporting obligations exist regardless of how invoices are exchanged with customers. “Fulfilling one does not automatically fulfil the other — except in full clearance models.”

E. The Convergence Trend

The global trend is towards governments wanting both the complete invoice (for audit trail) and granular transaction data (for real-time VAT monitoring). While the ultimate goal is a “single source of truth” where e-invoices automatically generate all reporting, this future is “still years away.” Emerging convergence patterns include:

• Platform-mediated extraction: Certified platforms handle the separation of “sent” and “reported.”
• Full clearance with data reuse: Tax authorities receive the full invoice and extract what they need internally.
• Parallel reporting with future e-invoicing integration: Countries initially adopting e-reporting are moving towards e-invoicing mandates, eventually merging the two flows.
• ViDA as a harmonization layer: Aims to create a common EU reporting standard by 2035, with national systems aligning to the EU model.

III. Conclusion

The distinction between e-invoicing (“what’s sent” to the buyer) and e-reporting (“what’s reported” to the tax authority) is paramount for businesses. While both originate from transactional data, their purpose, content, recipients, and compliance mechanisms differ significantly across jurisdictions. Understanding these nuances is critical for designing compliant systems, ensuring data quality, managing multi-country obligations, and avoiding the “reporting gap” risk. As digital tax mandates proliferate globally, businesses that accurately differentiate between and effectively manage both e-invoicing and e-reporting obligations will be better positioned for future compliance.

Summary

• E-invoicing and e-reporting are complementary but fundamentally different obligations: e-invoicing is about exchanging a structured invoice document between trading partners, while e-reporting is about transmitting a data extract from that invoice (or transaction) to the tax authority — they are not the same thing, even when they share the same source data.
• What is “sent” to the buyer is not the same as what is “reported” to the government: the full invoice travels to the business counterparty, but only a defined subset of data fields — amounts, VAT breakdown, counterparty identifiers, dates — is extracted, transformed, and transmitted to the tax authority as a reporting dataset.
• Understanding this distinction is critical for compliance, system design, and process architecture: businesses that treat e-invoicing and e-reporting as one and the same risk building systems that either over-report (sending full invoices where only data extracts are required) or under-report (missing mandatory reporting fields that are not on the invoice), leading to rejection, penalties, or failed VAT returns.

Introduction: Two Obligations, One Source — But Different Outputs

As governments across Europe and beyond accelerate their digital tax compliance frameworks, two terms dominate the landscape: e-invoicing and e-reporting. They are often mentioned together, sometimes used interchangeably, and frequently misunderstood — even by experienced tax professionals.

The confusion is understandable. Both obligations draw from the same well: the transactional data that sits inside an invoice. But what happens to that data — where it goes, in what form, to whom, and for what purpose — differs fundamentally between the two. [saft-validator.com]

Think of it this way: e-invoicing is about the document. E-reporting is about the data inside (or derived from) that document. [fintedu.com]

When a business issues a structured e-invoice to its customer, it sends a complete, machine-readable document — containing everything from line-item descriptions and quantities to payment terms and bank details. That document serves a commercial purpose: it tells the buyer what to pay, when, and for what.

But when that same business fulfils its e-reporting obligation, it does not send the full invoice to the tax authority. Instead, it extracts a defined subset of fields — the taxable base, the VAT amount, the VAT rate, the counterparty’s tax identification number, the invoice date, and sometimes a transaction type code — and transmits that data extract to the government. In some models, this extraction and transmission happen automatically through a platform; in others, the business must generate and submit the reporting dataset separately. [saft-validator.com]

This article explores that distinction in depth: what exactly is “sent” in e-invoicing, what is “reported” in e-reporting, how invoice data is reused or transformed into reporting datasets, and why getting this wrong can have real compliance consequences.

Part 1: What Is “Sent” — The E-Invoice as a Complete Document

The invoice is a legal and commercial document

An e-invoice, in its structured form (UBL, CII, Factur-X, PEPPOL BIS, or a country-specific XML schema), is a complete document that replaces the traditional paper or PDF invoice. It contains all the information required by VAT legislation (typically Article 226 of the EU VAT Directive) and often much more:

• Header data: invoice number, invoice date, due date, currency, payment terms
• Seller data: name, address, VAT identification number, IBAN, commercial register number
• Buyer data: name, address, VAT identification number, delivery address
• Line items: description of goods or services, quantity, unit price, discounts, line-level VAT rate and amount
• Totals: net amount, total VAT, gross amount, rounding
• References: purchase order number, contract number, delivery note reference
• Attachments: in hybrid formats like Factur-X or ZUGFeRD, a human-readable PDF may be embedded alongside the structured XML

Who receives the e-invoice?

The e-invoice is sent to the business counterparty — the buyer (or, in self-billing scenarios, generated by the buyer on behalf of the seller). The primary purpose is commercial: it triggers a payment obligation, enables the buyer to book the purchase, and allows the buyer to exercise its right to deduct input VAT.

In clearance models (Italy’s SDI, Poland’s KSeF, Turkey’s GIB), the invoice is routed through a government platform that validates and stamps it before delivery to the buyer. In these models, the tax authority sees the full invoice as a by-product of the clearance process — but the primary flow remains seller → platform → buyer. [banqup.com], [edicomgroup.com]

In post-audit models (traditional EU approach, Peppol-based exchange), the invoice goes directly from seller to buyer (or via access points), and the tax authority does not see the invoice at all — unless it requests it during an audit. [fonoa.com]

In hybrid models (France’s Y-schema), the invoice flows through certified platforms (Plateformes Agréées / PAs) that simultaneously deliver the invoice to the buyer and extract reporting data for the tax authority. [cleartax.com], [banqup.com]

Key point: the e-invoice is a rich, detailed document

The full e-invoice contains far more information than any tax authority needs for VAT monitoring purposes. Line-item descriptions, payment instructions, bank account numbers, purchase order references, delivery addresses — these are all essential for the commercial relationship between buyer and seller, but they are not what the tax authority is looking for when it monitors VAT compliance in near-real-time.

This is precisely where e-reporting enters the picture.

Part 2: What Is “Reported” — The Data Extract That Goes to the Tax Authority

E-reporting is not about sending an invoice

E-reporting is the obligation for businesses to digitally submit structured transaction data to the tax authority. Unlike e-invoicing, which concerns the invoice document exchanged between trading partners, e-reporting focuses on transmitting key data extracts — amounts, VAT, counterparty identifiers, dates, and transaction type codes — directly to the government. [saft-validator.com]

The goal is to give tax authorities near-real-time visibility into economic activity, enabling faster VAT gap detection, cross-checking of declared returns against actual transaction volumes, pre-filled VAT returns, and reduced fraud. [einvoice.belgium.be]

What data fields are typically “reported”?

While the exact fields vary by country, the core reporting dataset generally includes:

Data Field	Reported?	On the full e-invoice?
Seller VAT identification number	✅ Yes	✅ Yes
Buyer VAT identification number	✅ Yes	✅ Yes
Invoice number	✅ Yes	✅ Yes
Invoice date	✅ Yes	✅ Yes
Taxable base (net amount)	✅ Yes	✅ Yes
VAT rate(s)	✅ Yes	✅ Yes
VAT amount(s)	✅ Yes	✅ Yes
Transaction type / nature code	✅ Yes (often)	❌ Sometimes not
Currency	✅ Yes	✅ Yes
Credit note indicator	✅ Yes	✅ Yes
Line-item descriptions	❌ No (usually)	✅ Yes
Quantities and unit prices	❌ No (usually)	✅ Yes
Payment terms / due date	❌ No (usually)	✅ Yes
IBAN / bank details	❌ No	✅ Yes
Purchase order reference	❌ No	✅ Yes
Delivery address	❌ No	✅ Yes
Embedded PDF attachment	❌ No	✅ Yes (hybrid formats)

The reporting dataset is a subset — but not always a pure subset

Here is where it gets nuanced. In most cases, the reporting data is a subset of the invoice data: the tax authority receives fewer fields than the buyer. But in some cases, the reporting dataset requires fields that are not present on the invoice itself.

For example:

• Transaction type codes: France’s e-reporting requires businesses to classify transactions (domestic B2B, intra-EU, export, B2C) using specific codes. These codes may not appear on the invoice itself — they are derived from the business context and added during the reporting process. [impots.gouv.fr]
• Payment status data: France also requires the reporting of payment receipt data for services (the “encaissement” status). This is not invoice data at all — it is a lifecycle event that occurs after the invoice is issued. [tradeshift.com]
• Expense classifications: Greece’s myDATA requires both the issuer and the recipient to classify transactions into subcategories (e.g., “revenue from sale of goods,” “expense from acquisition of services”). These classifications are reporting-layer additions, not invoice content. [sovos.com]
• Nature-of-goods fields: Under ViDA’s Digital Reporting Requirements (DRR), there are discussions about requiring nature-of-goods fields for sensitive goods — data that may not be present on a standard invoice. [vatcalc.com]

This means the relationship between the e-invoice and the e-reporting dataset is not simply “full document vs. extract.” It is more accurately described as: the reporting dataset is derived from the invoice, enriched with additional context, and formatted according to the tax authority’s specifications.

Part 3: How Invoice Data Is Reused or Transformed Into Reporting Datasets

The data transformation pipeline

In practice, the journey from invoice to reporting dataset involves several steps:

Step 1 — Invoice creation: The seller’s ERP or billing system generates the invoice with all commercial and tax-relevant fields.

Step 2 — Structured format generation: The invoice data is mapped into a structured format (UBL, CII, Factur-X, or a country-specific schema). This is the e-invoice that will be sent to the buyer.

Step 3 — Data extraction: A subset of fields is extracted from the structured invoice. This extraction may happen within the ERP, within a middleware layer, or within the certified platform (PDP/PA in France, SDI in Italy, NAV Online Számla in Hungary). [saft-validator.com]

Step 4 — Data enrichment: Additional fields that are required for reporting but not present on the invoice are added. This includes transaction type codes, payment status indicators, expense classifications, or sector-specific identifiers.

Step 5 — Format transformation: The extracted and enriched data is transformed into the reporting format required by the tax authority. This may be a different XML schema, a JSON payload, or an API call — often entirely different from the e-invoice format.

Step 6 — Transmission to the tax authority: The reporting dataset is submitted to the government platform, either in real-time (within seconds, as in Hungary’s RTIR), within a short window (4 days in Spain’s SII, 10 days under ViDA DRR), or in periodic batches. [snitechnology.net], [vatcalc.com]

The role of platforms and intermediaries

In many modern e-invoicing/e-reporting ecosystems, the data extraction and transformation happen within the platform, not within the business’s own systems:

• France (Y-schema model): The certified Plateforme Agréée (PA) receives the full e-invoice from the seller, delivers it to the buyer, and simultaneously extracts the VAT-relevant data and transmits it to the DGFiP via the PPF. The business does not need to generate a separate reporting file — the platform handles the data transformation. [docs.oracle.com], [cleartax.com]
• Italy (SDI clearance model): The Sistema di Interscambio receives the full FatturaPA XML invoice, validates it, delivers it to the buyer, and retains a copy for the tax authority. In this model, there is no separate “reporting” step — the clearance process itself gives the Agenzia delle Entrate access to the complete invoice data. The invoice is the report. [edicomgroup.com]
• Hungary (RTIR model): The business extracts invoice header and summary data from its ERP, formats it into the NAV Online Számla XML schema (which is different from any e-invoice format), and submits it via API. The buyer still receives the invoice separately through normal commercial channels. The reporting dataset is a parallel data flow, not derived from an e-invoice exchange. [edicomgroup.com], [avalara.com]
• Spain (SII model): Businesses extract key fields from their issued and received invoices and submit them to the Agencia Tributaria within 4 days. SII does not require the invoice itself to be electronic — only that the key data fields are reported digitally. A business can issue a paper invoice to its customer and still be required to report the transaction data electronically to the tax authority. [saft-validator.com], [snitechnology.net]
• Greece (myDATA model): Businesses transmit income and expense classification data to the AADE through the myDATA platform. The platform creates a digital “book of accounts” for each taxpayer, cross-referencing reported income against expenses claimed by counterparties. Both the issuer and the recipient must report and classify — creating a two-sided reporting model where the data is enriched by both parties. [sovos.com]

Part 4: The Spectrum of Models — From “Invoice = Report” to “Report ≠ Invoice”

Not all countries treat the relationship between the invoice and the report the same way. It is helpful to think of a spectrum:

Model A: The Invoice IS the Report (Clearance Models)

In full clearance models like Italy’s SDI or Poland’s KSeF, the structured e-invoice is routed through a government platform. The tax authority receives the complete invoice as part of the delivery process. There is no separate reporting obligation — the act of issuing the e-invoice through the platform simultaneously fulfils the reporting requirement. [banqup.com], [edicomgroup.com]

What’s sent = What’s reported (the full invoice document).

Model B: The Report Is Extracted FROM the Invoice (Hybrid Models)

In France’s model, the e-invoice flows through certified platforms that extract VAT-relevant data and forward it to the tax authority. The business sends the full invoice to the buyer via the platform, and the platform generates the reporting dataset automatically. There is a clear distinction between the document (sent to the buyer) and the data (reported to the government), but they share the same origin and the extraction is automated. [banqup.com]

For transactions outside the scope of e-invoicing (B2C sales, cross-border B2B), France requires separate e-reporting: the business must generate and submit transaction data that is not derived from an e-invoice at all, but from its own sales records. [impots.gouv.fr]

What’s sent ≠ What’s reported (but they share the same source data, with automatic extraction for e-invoiced transactions).

Model C: The Report Is a Parallel Data Flow (Real-Time Reporting Models)

In Hungary’s RTIR, Spain’s SII, and Greece’s myDATA, the reporting obligation exists independently of any e-invoicing requirement. The business issues invoices (which may or may not be structured e-invoices) and separately submits transaction data to the tax authority. [snitechnology.net]

What’s sent (the invoice) and what’s reported (the data) are separate flows, even though they describe the same underlying transaction.

Model D: The Report Covers What the Invoice Does Not (Gap-Filling Models)

France’s e-reporting for B2C and cross-border transactions is a prime example. These transactions are not subject to e-invoicing, but they are subject to e-reporting. The business must report transaction data — aggregated daily totals for B2C, or individual transaction records for cross-border B2B — to the tax authority. [cleartax.com]

What’s reported has no corresponding “sent” e-invoice — the report stands alone.

Part 5: Why This Distinction Matters — Practical Implications

1. System architecture and ERP design

Businesses that treat e-invoicing and e-reporting as a single process risk building systems that cannot handle the nuances. The e-invoice output (e.g., UBL 2.1 XML sent to the buyer) and the e-reporting output (e.g., a VAT data extract in a different schema sent to the tax authority) may require different data mappings, different validation rules, and different transmission channels. [deloitte.com]

2. Data quality and completeness

If the reporting dataset requires fields that are not on the invoice (transaction type codes, payment status, expense classifications), the business must ensure these fields are captured and maintained outside the invoice workflow. An ERP that generates a perfect e-invoice may still produce an incomplete or incorrect reporting dataset if the enrichment layer is missing. [kpmg.com]

3. Multi-country compliance

A business operating across Europe may face all four models simultaneously:

• Italy: the invoice IS the report (clearance)
• France: the report is extracted from the invoice (hybrid), plus standalone reporting for B2C/cross-border
• Hungary: the report is a parallel data flow (RTIR)
• Belgium: e-invoicing is mandatory since January 2026, but e-reporting (planned for 2028) will add a separate data transmission obligation on top [einvoice.belgium.be]

Building a single, unified process that handles all these variations requires a clear understanding of what is “sent” and what is “reported” in each jurisdiction.

4. ViDA and the EU-wide Digital Reporting Requirements (DRR)

Under ViDA’s DRR pillar, effective from 1 July 2030, businesses engaged in cross-border B2B transactions within the EU must:

• Issue a structured e-invoice compliant with EN 16931 within 10 days of the supply
• Report the invoice data to their national tax authority, which will feed the data into the EU’s VIES for cross-border transaction matching [taxation-c….europa.eu], [sovos.com]

The ViDA model is closer to Model B (hybrid): the e-invoice is the source, and the reporting data is derived from it. But the exact mechanics are still being defined, with Member States debating issues such as:

• Whether the reporting dataset should include fields not present on the invoice (e.g., nature-of-goods codes)
• How to report VAT data that is not on the invoice (e.g., reverse charge self-accounting)
• Whether “days” means working days or calendar days
• How corrections, credit notes, and rejected invoices should be reflected in the reporting data [vatcalc.com]

5. The “reporting gap” risk

Perhaps the most dangerous misunderstanding is assuming that if you e-invoice, you have automatically reported. This is true in clearance models (Italy, Poland), but it is not true in most other models:

• In Spain, you can issue a perfectly valid e-invoice to your customer and still be penalized for failing to report the transaction data to SII within 4 days. [saft-validator.com]
• In Hungary, you can exchange invoices with your trading partner in any format you like, but you must still report the data to NAV’s Online Számla system in real time. [vatcalc.com]
• In France, B2C and cross-border transactions require separate e-reporting that the business must initiate. [impots.gouv.fr]

E-invoicing and e-reporting are two separate compliance obligations. Fulfilling one does not automatically fulfil the other — except in full clearance models.

Part 6: The Convergence Trend — Where Is This Heading?

The global trend is clear: governments want both the invoice (for commercial integrity and audit trail) and the data (for real-time VAT monitoring and fraud prevention). Several convergence patterns are emerging: [deloitte.com]

1. Platform-mediated extraction (France model): The platform handles the separation between “what’s sent” and “what’s reported,” reducing the burden on businesses but requiring trust in certified intermediaries.
2. Full clearance with data reuse (Italy/Poland model): The tax authority receives the full invoice and extracts what it needs internally. The business sends one document; the authority derives the report.
3. Parallel reporting with future e-invoicing integration (Hungary/Spain model): Countries that started with e-reporting are now moving toward e-invoicing mandates, which will eventually merge the two flows. Hungary plans to launch a B2B e-invoicing test environment in 2028, aligned with ViDA. [edicomgroup.com]
4. ViDA as the harmonization layer: The EU’s DRR framework aims to create a common reporting standard across all 27 Member States, with EN 16931 as the invoice standard and a harmonized reporting dataset feeding into VIES. By 2035, all existing national systems must align with the EU model. [taxation-c….europa.eu], [edicomgroup.com]

The end state, still years away, is likely a world where the structured e-invoice is the single source of truth from which all reporting obligations are automatically derived — eliminating the need for separate reporting processes, reducing compliance costs, and giving tax authorities the real-time visibility they seek.

But we are not there yet. Today, the distinction between “what’s sent” and “what’s reported” remains real, consequential, and — for many businesses — a source of confusion and risk.

Conclusion

E-invoicing and e-reporting are two sides of the same coin, but they are not the same side. The e-invoice is a complete document sent to the business counterparty for commercial purposes. The e-reporting dataset is a structured data extract — sometimes a subset of the invoice, sometimes enriched with additional context — sent to the tax authority for VAT compliance purposes.

Understanding this distinction is not an academic exercise. It determines how you design your systems, how you map your data, how you choose your platforms, and how you avoid the compliance gaps that arise when businesses assume that sending an e-invoice automatically means they have reported.

As ViDA, France, Belgium, and dozens of other mandates roll out between now and 2035, the businesses that thrive will be those that understand not just what they need to send and report, but why the two are different — and how to handle both with precision.