E-invoicing and E-reporting Are Two Obligations, Not One

A business can pass every validation gate its invoicing mandate imposes, deliver every document to every buyer, and still be in breach of the law that arrived on the same day. E-invoicing and e-reporting are announced together, funded as one project and sold as one product. They are two obligations with different subjects, and only one of them is about a document.

The confusion is structural rather than careless. Scope the work outward from the invoicing mandate and the reporting obligation looks like a delivery detail — the same document, copied to a third party. Read from the other end it cannot possibly be that. An administration that only ever saw invoices would have no view of the transactions for which no invoice is required, and those are exactly the transactions where tax goes missing.

So the useful question at the start of a mandate programme is not which format to produce. It is which of your transactions produce a structured invoice, which produce a report, and which produce both — because the second set is always larger than the first, and the work nobody planned for lives in the difference.

Two obligations, two subjects

E-invoicing governs a document that passes between two commercial parties. It has a recipient with a direct interest in it, because the buyer needs a valid invoice to exercise the right to deduct. The rules on what that document must contain, in what form and by when it must be issued sit in VAT law and long predate any structured format. A mandate changes the form and the route. It does not change the fact that the obligation runs to the buyer.

E-reporting governs a statement made to the administration about transactions. There is no commercial counterparty, nobody's deduction depends on it, and — this is the part that gets missed — it is defined over transactions rather than over documents. A transaction that produced no invoice can still be reportable. One whose invoice was issued abroad, under another country's rules and in a format your own mandate does not accept, is still yours to report when you owe the tax.

The French platform model is the clearest illustration, because the reform names the two flows separately from the outset instead of leaving a business to find the second one late.

The four axes on which they differ

Counterparty, trigger, payload and deadline. Each one diverges, and each divergence produces its own class of unplanned work.

The fifth column is the one worth reading twice. Neither failure announces itself. A reporting feed built as a branch of the invoicing pipeline will run cleanly for years and be silently incomplete from the first day.

What falls in the reporting net and not the invoicing net

It is short enough to work through in an afternoon with the general ledger open.

• Sales to private consumers. No structured invoice is required, and often no invoice at all. The transaction is still turnover.
• Supplies to and purchases from counterparties in other Member States or outside the EU. A domestic mandate does not reach a foreign trading partner, which is why cross-border flows are handled by digital reporting requirements under the VAT in the Digital Age package rather than by a national invoicing rule.
• Purchases on which you account for the tax yourself. Under a reverse charge or on an intra-Community acquisition, the document arrives from someone who was never subject to your mandate. It may be a PDF. The obligation attaches to you regardless.
• Self-billed supplies. The invoice exists, but you did not issue it, and the system that would have reported it never saw it.
• Anything documented by something that is not a full invoice. Simplified invoices, till receipts and summary documents are still evidence of transactions and are frequently reportable.
• Payment information. Where a Member State collects the tax on services at the point of payment, the report can be triggered by a receipt that no invoice records.

None of these produce a structured outbound invoice under your own mandate, and several produce no outbound document at all. Every one still has to reach the administration through some channel, and the billing system does not know they exist.

Deadlines that only look like one deadline

An invoice issue deadline comes from VAT law and is counted from the supply, in a period long enough to batch. A reporting deadline is counted from issue or from the transaction, and the trend across Europe is downward. Hungary's real-time invoice data reporting requires the report to follow issue immediately and without human intervention, which is a technical requirement disguised as a timing one: nothing that needs a person to press a button can satisfy it.

Two deadlines that differ by weeks look like one on a plan drawn at the altitude of "go live". They stop looking like one the first month a report is late for invoices that were themselves timely.

Clearance narrows the gap without closing it

Where the administration sits inside the exchange, the act of invoicing discharges the reporting obligation for the transactions that pass through the platform. That is a genuine reduction in work.

It is also bounded in a way the marketing rarely states. The platform sees what is routed through it. Consumer sales, foreign counterparties and purchases on which you self-account sit outside it by construction, so a clearance regime still leaves a second channel — usually periodic, usually built later and by different people. The architectural difference is set out in clearance and network exchange compared.

Correction travels down both routes

A wrong invoice is corrected by a document with a counterparty: a credit note, or a corrected invoice, subject to the same form and delivery rules as the original. A wrong report is corrected by a mechanism the administration defines, with its own window and its own penalties.

The two do not always move together. A report can be wrong while the invoice is right, because a transmission failed or a field was mapped for the buyer and not for the administration. The invoicing system will not raise it: from its point of view the document was accepted. Somebody has to compare what was reported against what was booked, and that reconciliation is a standing operational task rather than a project deliverable.

What actually decides the scale of the work

Not the format, and not the platform. It is where the data comes from.

Invoicing data comes from billing, which is one system with one owner. Reporting data has to come from the ledgers — receivable, payable, expenses, point of sale — because that is the only place where transactions with no outbound invoice are recorded at all. Spain's immediate supply of ledger records makes the point structurally: the obligation is expressed over the VAT books, not over the invoice file, and a business that reads it as an invoicing requirement builds the wrong thing.

The test to apply before signing anything is blunt. Ask the vendor which of your reportable transactions their product will not see, and treat a confident answer of "none" as a reason to keep asking.