E-invoicing is an exchange: a supplier sends a structured document to a buyer so the buyer can book it and pay it. E-reporting is a transmission: a taxpayer sends fiscal data to a tax authority so the authority can cross-check it. Different recipient, different payload, different deadline, different consequence when it fails. They are two flows that happen to be derived from the same source document.
They get conflated because one service provider usually sells both, and because in some countries the same API call does both. But they are independent axes. Sweden, Finland and Norway have mandatory invoice exchange over Peppol with no tax authority controls involved at all — mandatory e-invoicing, zero e-reporting. Meanwhile India’s mandate is routinely called “e-invoicing” and its output is frequently an emailed PDF. Getting the distinction right determines what you build.
The two flows, side by side
Under ViDA — Council Directive (EU) 2025/516, the adopted text — the two flows are defined in different chapters of the VAT Directive, and every parameter differs.
- Recipient. E-invoicing: the buyer. E-reporting: the tax authority that issued the VAT number used for the transaction (Article 262(2)).
- Payload. E-invoicing: the invoice, complying with EN 16931 by default (Article 218(3)). E-reporting: ten data points (Article 264).
- Deadline. E-invoicing: within ten days of the chargeable event (Article 222). E-reporting: at the moment the invoice is issued or should have been (Article 263(1)).
- Who acts. E-invoicing: the supplier. E-reporting: the supplier and the customer, within five days of receiving the invoice — unless the member state waives it (Article 262(4)).
- Harmonisation. E-reporting for cross-border is identical in every member state, with no possibility of requesting additional data. Domestic e-reporting is whatever each member state decides (Article 271b(4)).
One document, two consumers, and the consumers want different things. There is also a third: the ERPB’s 2016 working group report defines a Request To Pay as a subset extracted from the invoice, carrying the minimum needed to initiate payment plus a link back to the underlying invoice — and it notes that this message usually contains no tax details and no line items at all. Three parties, three data sets, one source document.
The buyer gets the invoice. The authority gets ten fields.
The concrete version comes straight from Article 264 as replaced by ViDA. From 1 July 2030, for an intra-Community supply, what gets transmitted to the tax authority is Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where applicable. Ten data points.
Not on that list: point 5, the full name and address of both parties. The authority resolves identity from the VAT numbers via VIES; it doesn’t need the street. Also not on the list, for the supplier: the VAT rate and the VAT amount — an intra-Community supply is exempt, so there is no rate to report. The customer’s report of the same transaction does carry the rate and the amount, because in the customer’s country the transaction is taxable. Supplier reports ten fields, customer reports twelve, same transaction.
Now compare that with what the buyer needs from the same document: line-level descriptions and quantities, the purchase order reference, the delivery address, payment terms, the supplier’s bank details, an accounting cost code for coding it to the right centre. Almost none of that is reportable. It is the entire reason the invoice exists.
The two data sets overlap. Neither contains the other.
Different failure modes, and this is where it gets expensive
If e-invoicing fails, the buyer doesn’t get an invoice, and eventually somebody calls somebody. It’s a commercial problem with a commercial remedy.
If e-reporting fails, the tax consequences are structural. ViDA amends Article 138(1a) so that the exemption for an intra-Community supply does not apply where the supplier has not met the Articles 262 and 263 transmission obligation, or where the data transmitted doesn’t contain the correct information required by Article 264 — unless the supplier can duly justify the failure to the competent authorities. Miss the report, and a zero-rated cross-border supply becomes a taxable one.
On the other side, ViDA adds a subparagraph to Article 168 letting member states provide that a customer may deduct or reclaim VAT only where it holds an electronic invoice issued in accordance with Article 218(3). Note the scope: that option attaches to transactions subject to the domestic reporting requirements of Article 271a(1). It is an option, not an obligation, and it is national.
So the same missing message costs a late payment on one plane and an exemption on the other. Systems that treat the report as a downstream side effect of a successful invoice send are mis-modelling the risk — the report has the sharper teeth.
Where the tax authority actually sits: the corner models
The ERPB’s 2016 report categorises e-invoicing solutions by the number of intermediary platforms in the presentation flow: Supplier Direct, where the supplier runs the whole lifecycle and the payer comes to the supplier’s portal; Buyer Direct, where suppliers post into a platform on the buyer’s side; the three-corner network, where one service provider sits between both parties; and the four-corner network, where each party has its own provider and flows are routed between the two platforms.
The tax authority is not a corner in any of them. That isn’t an oversight in 2016 — it’s the definition. E-invoicing was a two-party exchange, and intermediaries were counted by how many sat in the presentation path.
When tax authorities arrived, the industry had to invent a fifth corner, and the name it settled on gives the game away: DCTCE, Decentralized CTC and Exchange. Two functions, named separately, in one acronym. France’s model is drawn as a Y for the same reason — two branches for exchange (issuing and receiving through approved platforms) and a third branch for e-reporting, submitting invoice, transaction and payment data to the tax authority through the public portal.
And here the vendor pages that inspired this article contradict each other outright. Some describe the five-corner model as one where invoices must first pass through a government platform to be validated and registered before continuing to the buyer. Others describe the same model as one where a copy is sent to the tax authority before or immediately after delivery, while the invoice reaches the buyer through their own access point. Those are different architectures, and the difference is load-bearing: one commentary notes the decentralised version is gaining ground precisely because pre-clearance submission undermines established billing processes and makes the authority’s portal a single point of failure.
Both descriptions are accurate — about different systems. Clearance (the authority is in the exchange path, and the invoice isn’t valid until it comes back) and near-real-time reporting (the authority gets a copy on a separate leg) are distinct designs. ViDA mandates the second for intra-EU: transmit at the time of issue. It does not put the authority between supplier and buyer.
The mandates called “e-invoicing” that are really e-reporting
Two of the clearest examples come from implementation guides rather than marketing pages.
India. Sigitek’s SAP e-invoicing solution documentation describes the flow: every SAP billing document is pushed as JSON to the Invoice Registration Portal via an authorised GSP; the IRP checks the IRN against the GST system’s central registry for uniqueness, signs the invoice data, adds a QR code and returns the digitally signed JSON with the IRN to SAP; the IRP then shares the signed data with the GST system and the E-Way Bill system, and GSTR-1 is auto-populated on a T+1 basis. The buyer appears nowhere in that flow. The last step in the vendor’s own architecture diagram is “Print or Email Invoice”. The structured data goes to the government; the buyer gets a printout with a QR code on it.
Greece. SAP’s August 2024 implementation guide describes the same shape. Invoices route through a certified service provider to myDATA, which returns a MARK, a UID and an authentication code — and the requirement is then that the QR code, MARK, UID, authentication code and the provider’s name are printed on the invoice. Real-time submission, rendered as ink.
In both cases the mandate is an e-reporting mandate wearing an e-invoicing label. The tell is simple: ask who receives the structured data. If the answer is “the tax authority, and the buyer gets a PDF”, that’s e-reporting. The exchange plane hasn’t been digitised at all.
The one place they genuinely couple
The flows are separable, but not independent — and the dependency runs one way.
The new Article 217, applying from 1 July 2030, defines an electronic invoice as one issued, transmitted and received in a structured electronic format allowing automated processing — “at least in relation to the data referred to in Articles 262 and 271b”. Articles 262 and 271b are the reporting articles. The reporting requirement is what sets the structured minimum for the invoice. ViDA’s recital 11 says it plainly: the invoice should contain, in structured format, all the data that has to be transmitted to the authority, so that transmission can be automated from it.
That single qualifier explains two things people find confusing. It’s why hybrid formats like ZUGFeRD and Factur-X survive — the reportable data is in the XML, so the PDF layer is legally irrelevant. And it’s why e-reporting is driving e-invoicing rather than the other way round: the tax authority’s data needs define the floor of the format your buyer receives. Not the buyer’s needs. Not yours.
Meanwhile the old periodic report dies. ViDA deletes Articles 265 to 271 from 1 July 2030 — recapitulative statements disappear, replaced by transaction-by-transaction transmission. That’s the actual reform: not new reporting, but the same reporting moved from monthly batch to per-transaction, which is only affordable if it’s derived automatically from a structured invoice.
How to tell which one you’re being sold
Four questions cut through most vendor pages:
- Who receives the structured data? Buyer, authority, or both. “Both” is a five-corner or DCTCE architecture. “Authority only” is e-reporting with an e-invoicing label.
- Is the authority in the path or beside it? Clearance means the invoice isn’t valid until the platform returns an identifier. Reporting means a copy travels separately and the invoice is valid regardless.
- What happens if the report fails but the invoice arrives? If the answer is “nothing”, the flows are decoupled. If it’s “the exemption goes”, you’re inside Article 138(1a).
- Which data set is being mapped? Ten header fields is a reporting integration. Around 170 EN 16931 business terms is an invoicing integration. They’re different projects with different costs.
Frequently asked questions
Is e-reporting just e-invoicing sent to the government?
No. Under ViDA it’s a defined subset — Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17 — transmitted per transaction on its own leg, without the parties’ names and addresses. In some national systems a full invoice copy does go to the authority, which is why the misconception is durable, but the EU cross-border design transmits data, not documents.
Can you have e-invoicing without e-reporting?
Yes, and several countries do. Invoice exchange over Peppol is mandatory in Sweden, Finland and Norway, and it isn’t a CTC model because there are no tax authority controls involved. Mandatory structured exchange, no fiscal transmission.
Can you have e-reporting without e-invoicing?
Yes — that’s what India and Greece currently demonstrate at the buyer’s end, where the structured data reaches the tax authority and the counterparty receives a printed or emailed document carrying a QR code.
Do both the supplier and the buyer have to report under ViDA?
By default yes: the supplier at the time of issue, the customer within five days of receiving the invoice. But Article 262(4) lets member states drop the customer-side obligation, and ViDA’s recitals explain why — the customer’s report exists to cross-check the supplier’s, so a member state that already has assurance the supplier will report can waive it.
Does ViDA make my country’s clearance system illegal?
No. Member states with a domestic real-time transaction-based reporting obligation in place on 1 January 2024 have until 1 January 2035 to align those domestic systems, and Article 273 lets existing general reporting obligations continue until a compliant system replaces them. The convergence is real but slow, and it applies to domestic flows — the intra-EU leg is harmonised from 2030.