EU E-Invoicing & Tax Reporting Knowledge Base

Once an invoice has cleared a tax authority, it is immutable. You cannot edit it. In most systems you cannot cancel it either, and where you can, the window is measured in hours and closing. What you get instead is a third verb: supersede. Issue a new document that points at the old one, and let the tax authority reconstruct the graph.

This is the part of e-invoicing that product teams model last and pay for first. The send is the easy bit — one document, one API call, one status. The lifecycle is a directed graph of documents that reference each other, some of which your counterparty creates, some of which lock others, and all of which are separately reportable.

Cancellation is a narrow exception, and it’s disappearing

India is the clearest illustration because its cancellation rule has a reason nobody expects. An e-invoice can be cancelled on the Invoice Registration Portal only within 24 hours of the IRN being generated — and the reason commonly given is that the IRP doesn’t store e-invoices for longer than that. The window on a legal operation is set by an infrastructure retention policy. After it closes, the portal simply blocks the option.

Three further constraints stack on top:

• Amendment doesn’t exist at all. Once the IRN is generated the data is locked. Taxable value, tax rate, buyer details — none of it can be changed on the original. Changes are made when filing GSTR-1, and those get flagged to the officer, who may come back asking questions.
• Partial cancellation is impossible. It’s the whole invoice or nothing.
• A downstream document can veto it. If an e-way bill is active against the IRN, the IRP will not permit cancellation. The goods are moving; the invoice is pinned.

That last one is the shape of the whole problem. Your invoice is not a leaf node. Something else is holding a reference to it, and that reference removes an operation from your state machine.

Greece removes the operation differently, and SAP Hellas’s August 2024 implementation guide records it precisely: because the solution uses a service provider under the Greek YPAHES framework, the cancel function is no longer available, and companies must issue credit notes as a substitute for cancellations. Read the causation carefully — cancellation wasn’t banned outright, it was removed by the compliance route. The same SAP framework offers submission, cancellation, resubmission and deletion, with deletion only possible while the document is still in created status. Pick the service-provider path and one of those verbs quietly goes away.

Which means the available lifecycle operations are a function of the country and the architecture, not of your product. You do not get to decide whether your users can cancel.

Everything else is a new document pointing at the old one

The universal fallback is the credit note, and it’s worth being precise about what it is: not an edit, not a reversal flag, but a separate fiscal document with its own identity that references the original.

In India, once the 24 hours have passed, a credit note (for a reduction) or debit note (for an increase) referencing the original IRN is the only route — and that note must itself be e-invoiced where the supplier is inside the mandate threshold, generating its own IRN. The correction is recursive: fixing a reported document produces another reported document. In Italy, credit notes (TD04) and debit notes (TD05) go through the SdI referencing the original, on the same clearance path as the invoice itself.

ViDA then does something that makes this explicit in EU law. From 1 July 2030, Article 226 gains point 16: the sequential number of the corrected invoice, on a corrective invoice. The pointer becomes a mandatory legal field. And Article 264 puts point 16 inside the ten data points transmitted to the tax authority for a cross-border supply — so the edge of the graph is itself reported. The authority isn’t inferring the relationship from your reference field. It’s receiving it.

The simplified-invoice rule (Article 226b) has carried the same logic for years: a corrective document needs a specific and unambiguous reference to the initial invoice and to the specific details being amended. Note the second half. Not just “which invoice” — “what changed”.

What ViDA conspicuously does not add is a cancellation message. There is no “unsend” in the reporting model. Corrections are documents, and documents are all the authority sees.

Two countries, one question, opposite answers

Here’s the finding that should kill any attempt at a single global correction policy.

When Italy’s SdI rejects an invoice with a notifica di scarto, the invoice is legally treated as never issued, and the sender has five days to correct and resubmit — reusing the same invoice number and date to avoid penalties. The number must be reused, because as far as the law is concerned nothing was ever issued under it.

In India, after cancelling an IRN, you must not reuse the invoice number to generate a new one. The number is burned.

Same engineering question — is a document number reusable after a failed attempt? — and two mandates give opposite answers, both mandatory, both penalised. If your sequence generator has a global policy on reuse, it is wrong in at least one jurisdiction. This has to be per-country configuration, and it has to sit at the point where numbers are minted, which is usually the last place anyone wants country logic.

The graph has edges you don’t control

The lifecycle isn’t only yours to drive. Three examples, all live:

Your buyer can report you. Italy introduced document type TD29 in version 1.9 of the FatturaPA specification in April 2025, letting a buyer flag a supplier’s omitted or irregular invoice through the SdI — shifting part of the compliance responsibility onto the buyer. TD20 already allowed buyers to self-invoice omitted or irregular supplies. Your invoice’s lifecycle now has state transitions initiated by someone else’s finance team.

The counterparty’s clock is different from yours. In India, if an IRN is cancelled after the data has auto-populated into GSTR-1, the supplier amends GSTR-1 and the buyer’s GSTR-2B adjusts in the next cycle, generated on the 14th of the following month. The correction is instant on your side and up to a month late on theirs. Anything you build that assumes both parties see the same state at the same time is modelling a system that doesn’t exist.

Delivery failure creates obligations, not retries. Italy’s mancata consegna means the invoice is legally issued but the buyer’s channel was unreachable; the SdI parks it in their portal area, and the sender must retain the notification as proof and tell the customer. That’s a lifecycle branch whose next step is a phone call.

Payments and financing hang off the same document

The graph extends past tax. The Euro Retail Payments Board’s 2016 report defines a Request To Pay as a subset extracted from the invoice — the minimum needed to initiate payment, with a link back to the underlying invoice, and usually no tax detail or line items at all. That’s a fourth representation of the same transaction, with its own lifecycle, joined to the invoice by a reference.

Financing adds a fifth. OASIS built UBL as a general trade format aligned with ISO 20022 and designed to carry invoice financing, factoring and letters of credit. When an invoice is factored, a third party acquires a claim against a document that the tax authority may later treat as never having existed. The credit note that fixes your VAT position is also an event in somebody’s receivables book.

None of this is exotic. It’s the ordinary consequence of one document being referenced by several systems with different rules about what “cancelled” means.

What to model

Immutable documents, mutable graph. Never update a cleared invoice record. Append documents and edges. The tax authority’s view is a log, not a table — model yours the same way and reconciliation gets much easier.

Make the reference a first-class field, not a note. From 1 July 2030 the corrected invoice’s number is a legally mandated field that gets transmitted. Treat “which document does this supersede, and what changed” as structured data from the start; you’ll need both halves.

Model operations as per-country capabilities. Can this document be cancelled? For how long? Can the number be reused? Is a downstream document blocking it? Those are configuration, not code paths — India blocks cancellation with an active e-way bill, Greece removes cancel entirely on the service-provider route, Italy requires number reuse where India forbids it.

Assume corrections are recursive and reportable. A credit note against a reported invoice is itself a reported document with its own identifier and its own failure modes. If your reporting pipeline treats corrections as a special case outside the main flow, you have two pipelines and one of them is undertested.

Give the correction a reason, and keep it. Italy’s ravvedimento operoso lets businesses correct voluntarily and cut penalties substantially, but only where the correction is made before the authority opens a formal inspection — so the timestamp on your correction has money attached. Under ViDA, Article 138(1a) removes the exemption on an intra-Community supply where transmitted data is wrong, unless the failure can be duly justified. “Duly justified” is a field you either populated at the time or cannot reconstruct later.

Frequently asked questions

Can I edit an e-invoice after sending it?

No. In India the data is locked once the IRN is generated and amendment on the portal doesn’t exist. In clearance systems generally, the cleared document is the record; changes come through a new document that references it. Where a portal offers “amendment”, it usually means amending your return, not the invoice — and in India those amendments get flagged for the officer’s attention.

What’s the difference between cancelling and issuing a credit note?

Cancellation removes the invoice from existence, which is why it’s tightly time-boxed or unavailable. A credit note leaves the original standing and reverses its effect with a second document. India permits cancellation for 24 hours, then only credit notes. Greece, on the service-provider route, has no cancellation at all — credit notes substitute for it entirely.

Can I reuse the invoice number after a rejection?

It depends on the country, and the two big mandates disagree. Italy requires you to resubmit a rejected invoice with the same number and date within five days. India forbids reusing the number of a cancelled IRN. Make this configurable per jurisdiction.

Does a credit note need to be e-invoiced too?

Generally yes. In India a credit or debit note must itself be e-invoiced where the supplier is inside the mandate threshold, producing its own IRN. In Italy, TD04 credit notes and TD05 debit notes go through the SdI like any other document. Corrections are not a side channel.

Why can’t I cancel an invoice that has an e-way bill?

Because a downstream document is referencing it. India’s IRP refuses IRN cancellation while an e-way bill is active against it — the goods are in transit under that invoice, so the invoice can’t be unmade. It’s the clearest example of the general rule: your document’s available operations depend on what else in the graph points at it.

On 1 July 2030, Council Directive (EU) 2025/516 deletes Articles 265 to 271 of the VAT Directive. That single provision abolishes the recapitulative statement — the periodic summary of intra-Community supplies, filed after the fact, that has been the archetype of reporting later for three decades. In its place: transmission of transaction data at the moment the invoice is issued.

That is the whole shift in one legal fact. Not new reporting — the same reporting, moved from monthly batch to per-transaction, which is only affordable if it’s derived automatically from a structured invoice. The stated reason is fraud. The Commission’s own evidence for that reason is weaker than almost anyone selling this will tell you, and it’s worth understanding why before you build to it.

What “report later” actually was

The old model has a retronym now — periodic transaction controls, PTC — but its defining feature was never the periodicity. It was that the tax authority saw nothing until it asked.

The 2016 edition of the E-Invoicing and Retention in Europe compendium, compiled by Peters, Schönberger & Partner across 22 European countries, is a complete snapshot of that world. The recurring question in every chapter is how a business ensures authenticity of origin and integrity of content — and the recurring answer is business controls creating a reliable audit trail, matching the invoice against purchase orders and other existing documents. The taxpayer builds the evidence. The taxpayer keeps the evidence, for five years in Greece and Poland, eleven in Croatia, up to 22 in Austria for immovable property. The authority arrives later, if at all.

The clearest expression of the old logic is a small Czech rule the compendium records: invoices may be stored outside the Czech Republic only where there is continuous remote access, and after prior notification to the tax authority. Read that carefully. The authority wanted continuous access to the archive — a standing right to reach the data, exercised on demand. Continuous transaction controls invert it: the authority no longer reserves a right to come and look, because the data arrives on its own.

Same objective, opposite mechanism. Which is why “faster reporting” undersells it.

Nobody called it PTC at the time

Worth stating plainly, because it dates the vocabulary: neither “continuous transaction controls” nor “periodic transaction controls” appears anywhere in the 2016 PSP compendium, in the Euro Retail Payments Board’s 2016 working group report on e-invoicing solutions, or in Billentis’s 2017 business case. Several hundred pages, written by specialists at the centre of European e-invoicing, and the terms are simply absent.

PTC is a retronym. It exists to have something to contrast CTC against, the way “acoustic guitar” only became necessary once electric ones existed. In 2016 this wasn’t a model with a name. It was just how VAT worked.

One detail cuts against the neat chronology, though. Greece’s 2016 answer on ensuring authenticity already listed, alongside signatures and EDI, both special safe appliances (electronic tax machines) and clearance of sales transactions through a payment service provider. The country that would go on to build myDATA was already describing clearance mechanisms in a post-audit questionnaire. The shift was visible before it had a label.

What replaces it, and when

The mechanics under ViDA are precise, and the dates are the deliverable:

• Invoice deadline compresses. For intra-Community supplies and reverse-charge transactions, the invoice must be issued within ten days of the chargeable event (Article 222) — down from the fifteenth day of the following month.
• The report leaves at issue. Data is transmitted per individual transaction at the moment the invoice is issued or should have been (Article 263(1)). Self-billed invoices get five days. The customer reports within five days of receiving the invoice, unless the member state waives it (Article 262(4)).
• The payload is fixed. Ten data points for the supplier — Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where applicable (Article 264). Identical in every member state, with no possibility of requesting additional data.
• Missing the report has teeth. Article 138(1a) removes the exemption for an intra-Community supply where the supplier hasn’t met the transmission obligation, or where the data transmitted doesn’t contain the correct information — unless the failure can be duly justified to the competent authorities.
• Summary invoices survive, narrowed. Article 223 keeps periodic invoices where VAT on the different supplies becomes chargeable in the same calendar month, issued within ten days of month end — and lets member states exclude them entirely in fraud-sensitive sectors. Note this: the original ViDA proposal abolished summary invoices outright. The adopted text kept them. Commentary written from the draft still says otherwise.
• Domestic systems get five more years. Member states with a domestic real-time transaction-based reporting obligation in place on 1 January 2024 have until 1 January 2035 to align.

Reporting later doesn’t disappear so much as shrink to a residue: the VAT return itself survives, and Article 273 explicitly lets member states keep national tools like SAF-T alongside the real-time obligations. What dies on 1 July 2030 is the periodic transaction listing.

The official case for it — and where the numbers don’t hold

ViDA’s recital 3 makes the argument: the VAT gap was estimated at €93 billion across the Union in 2020, a significant part of it fraud, and in particular intra-Community missing trader fraud, estimated at around €40 to €60 billion. Recital 4 supplies the mechanism: transaction-by-transaction transmission lets administrations cross-check data, increases control capacity, and deters non-compliance.

Then compare that with what the Commission has published since.

The VAT gap in Europe — report 2025, released on 11 December 2025, puts the EU VAT compliance gap at €128 billion for 2023 — 9.5% of the total VAT liability, against total VAT revenue of €1,223 billion. That’s an increase of 1.6 percentage points on 2022, and the Commission’s own Mind the Gap report describes it as reversing the progress observed during the pandemic. Over the longer run the picture is better: 11.1% in 2019 down to 9.5% in 2023. Both statements are true, which is why you’ll see the same report cited as evidence of success and of failure.

The harder problem is the fraud number. A Commission-commissioned study estimating the MTIC gap at EU level using Intrastat mirror-trade statistics put it at between €12.5 billion and €32.8 billion annually across 2010 to 2023 — an average annual loss of 1.2–3.1% of actual VAT revenue. Set that beside the directive’s own €40–60 billion. The upper bound of the Commission’s later estimate is below the lower bound of the figure in the recital.

And the study’s conclusion is more awkward still: the MTIC gap has been broadly stable over time, which the Commission reads as suggesting that factors other than MTIC fraud drive the fluctuations in the VAT compliance gap. If carousel fraud is stable and the gap moves anyway, then the gap is mostly being moved by something CTC doesn’t target — bankruptcies, insolvency, administrative error, real-terms revenue decline. The 2025 report’s own context supports that: between 2021 and 2023 theoretical VAT liability rose 17.3% while actual revenues grew 14.4%, and bankruptcies rose across most of the EU.

Three more figures worth holding:

• The two best-performing member states run no CTC mandate. Austria’s 2023 compliance gap is about 1.0%, Finland’s about 3.0% — the lowest in the EU. Neither has continuous transaction controls. Whatever they’re doing works without it.
• The gap is concentrated. Around 75% of the EU compliance gap comes from six countries: France, Germany, Italy, Poland, Romania and Spain. This is not an EU-wide compliance problem being solved with an EU-wide instrument.
• The policy gap dwarfs the compliance gap. Revenue forgone through reduced rates and exemptions ran to roughly €743 billion in 2023 — around six times the entire compliance gap. The largest hole in EU VAT revenue is a deliberate policy choice, not fraud.

None of that makes CTC pointless. Faster data genuinely does help administrations that are under-resourced rather than under-informed, and the Commission’s own analysis attributes diverging national trends partly to digital reporting reforms. But the honest summary is that the reforms have yet to reverse the recent increase in the EU-wide gap, and the specific fraud they target is a smaller and steadier problem than the directive that targets it asserts. Anyone quoting €40–60 billion in 2026 is quoting a recital, not a measurement.

Why it’s happening anyway

Because the argument for CTC was never really only about fraud — it’s about latency, and latency is what the sources actually show changing.

Look at what the working implementations do. SAP’s August 2024 guide for Greek e-invoicing describes real-time submission through a certified service provider, with myDATA returning a MARK, a UID and an authentication code that must then be printed on the invoice. Sigitek’s SAP solution for India pushes every billing document as JSON to the Invoice Registration Portal via an authorised GSP, which validates the reference number against the GST system’s central registry, signs the data, returns it with a QR code, forwards it to the GST and E-Way Bill systems — and auto-populates the GSTR-1 return on a T+1 basis.

That last clause is the point. The return isn’t abolished; it’s pre-filled. Once the authority holds the transaction data, the periodic filing stops being a declaration the taxpayer composes and becomes a statement the authority proposes. That is a different relationship, and it’s a far more attractive prize for a tax administration than any individual fraud case.

It’s also why e-reporting drives e-invoicing rather than the reverse. The new Article 217 defines an electronic invoice as one in a structured format allowing automated processing — “at least in relation to the data referred to in Articles 262 and 271b”, the reporting articles. Recital 11 is explicit that the invoice should carry all the data to be transmitted, in structured format, so the transmission can be automated from it. The authority’s data needs set the floor for the document your buyer receives.

What to do about it

Three things follow, regardless of what you think of the fraud case.

Model latency, not frequency. The design constraint isn’t “report more often”. It’s that the report is emitted by the act of invoicing, synchronously, with a legal consequence on failure. Any architecture that treats reporting as a nightly job is building the wrong thing.

Assume the return gets pre-filled. India already does it on a T+1 basis. If your reconciliation process assumes you are the authoritative source of your own VAT position, that assumption has a shelf life.

Watch the domestic layer, not the EU one. The intra-EU set is ten fields, fixed everywhere from 2030. Domestic reporting is optional for member states and its content is defined nationally under Article 271b(4) — that’s where the divergence and the cost live, and it runs to 2035.

Frequently asked questions

What are continuous transaction controls?

Any regime where transaction data reaches the tax authority at or near the moment of the transaction, rather than in a periodic filing afterwards. It covers both clearance models, where the authority validates the invoice before it’s valid, and real-time reporting, where a copy or subset travels to the authority on a separate leg. ViDA mandates the second for intra-EU supplies from 1 July 2030.

Is the VAT return being abolished?

No. ViDA abolishes recapitulative statements — the periodic listing of intra-Community transactions — from 1 July 2030 by deleting Articles 265 to 271. The VAT return itself remains, and Article 273 lets member states keep national reporting tools such as SAF-T. What changes is that the return increasingly gets pre-populated from data the authority already holds.

Does CTC actually reduce VAT fraud?

The evidence is more equivocal than the marketing. ViDA’s recital estimates missing trader fraud at €40–60 billion a year; a Commission study using mirror-trade statistics puts the MTIC gap at €12.5–32.8 billion and finds it broadly stable across 2010–2023. The EU compliance gap rose to €128 billion in 2023 while digital reporting was spreading. Digital reporting is one of several factors the Commission credits for diverging national trends — but the causal claim is not settled, and the two lowest-gap member states have no CTC at all.

When does my country switch?

For intra-EU B2B, 1 July 2030 everywhere. Domestically it varies: member states have been free to mandate e-invoicing without a derogation since 14 April 2025, which is why national mandates are arriving first, and those with a real-time domestic system already in place on 1 January 2024 have until 1 January 2035 to converge.

Do summary invoices still work?

Yes, with limits. Article 223 as amended allows periodic invoices covering supplies whose VAT becomes chargeable within the same calendar month, issued within ten days of month end, and lets member states exclude them in fraud-sensitive sectors. The ViDA proposal would have removed them entirely; the adopted directive did not.

All three, depending on which layer is asking. VAT law lists 15 mandatory particulars in Article 226 of the VAT Directive, rising to 17 on 1 July 2030. ViDA’s digital reporting will transmit exactly 10 of those 17 to the tax authority for a cross-border supply. EN 16931’s core invoice model defines around 170 business terms — 176 by the most-cited count, and even that figure is contested — of which roughly 25 are mandatory. And the UBL syntax that carries all of it has no published field count at all.

That gives three numbers and one non-answer to “what’s on an invoice” — and the part that breaks data models is that the sets are not nested. Each layer makes something mandatory that the others don’t ask for. There is no superset invoice to model against.

The three layers, and what each one is actually for

The confusion is structural, not sloppy. Each layer was defined by a different body answering a different question.

• The legal invoice — Article 226 of the VAT Directive. Question: what must a document say to establish a VAT position? Roughly 15–17 particulars, and it is a closed list.
• The reportable set — Article 264 as replaced by ViDA. Question: what does the tax authority need transmitted? Ten data points for cross-border B2B, fixed EU-wide.
• The core invoice — EN 16931, built by CEN/TC 434 under Directive 2014/55/EU. Question: what must two systems agree on to process an invoice automatically across borders? Around 170 business terms.
• The commercial invoice — the UBL 2.1 or UN/CEFACT CII document that actually gets sent. Question: what could a trading document ever need to carry? Effectively uncountable.

Only the first is law. The second is law about the first. The third is a standard the law now points to. The fourth is a container.

The legal layer: Article 226 is a closed list of 15, going to 17

Article 226 opens by saying that only the details it lists are required for VAT purposes. The word “only” is doing real work: this is a ceiling, not a floor. The European Commission’s own explanatory notes on the 2010 invoicing rules make the point explicitly when discussing exchange rates — a requirement to state the conversion method would be a detail above those required in Article 226, and therefore not permitted.

The list runs to 15 numbered points: issue date, sequential number, the supplier’s VAT number, the customer’s VAT number where they’re liable, the full name and address of both parties, quantity and nature of the supply, the supply date, the taxable amount per rate, the VAT rate, the VAT amount, exemption or reverse-charge references, and the special-scheme mentions. Points 7a (cash accounting) and 11a (“Reverse charge”) sit inside that structure as insertions rather than extensions.

The floor is much lower than most product teams assume. Under Article 226b, a simplified invoice needs five details — issue date, identification of the supplier, identification of the type of goods or services, the VAT amount payable or the information needed to calculate it, and, for a corrective document, a reference to the original. The fifth is conditional, so the practical minimum is four. Article 220a makes simplified invoices available where the invoice does not exceed EUR 100.

Council Directive (EU) 2025/516 — ViDA — adds two points with effect from 1 July 2030: point 16, the sequential number of the corrected invoice on a corrective invoice, and point 17, the supplier’s bank account numbers, virtual account numbers, or any other identifier unambiguously identifying the accounts the invoice can be paid into. Point 11a also gains a “triangular transaction” mention. Seventeen points, from a single date.

Be careful with secondary sources here. A large amount of published commentary still describes the ViDA proposal, which added three points — the third being the payment due date — with effect from 2028. The adopted directive contains two, from 2030. If your data model has a mandatory payment-due-date field because of ViDA, it was built from a draft.

The reporting layer: ViDA transmits 10 of the 17, and the buyer’s name isn’t one

This is the number almost nobody has, because it requires reading Article 264 as replaced by ViDA rather than a summary of it. From 1 July 2030, for an intra-Community supply under Article 138(1) and for supplies where the customer is liable under Articles 194 to 197, the data transmitted is: Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17 — plus 11a where applicable. Ten data points, eleven with the reverse-charge mention.

What’s missing from that list is more instructive than what’s in it:

• Point 5 — the full name and address of both parties. Not reported. The VAT identification numbers are, and the authority resolves identity through VIES.
• Points 9 and 10 — the VAT rate and the VAT amount. Not reported by the supplier. An intra-Community supply under Article 138 is exempt, so there is no rate to report.

The asymmetry goes further. For intra-Community acquisitions under Article 20, Article 264(c) requires points 1 to 4, 6, 7, 8, 9, 10, 11, 16 and 17 — twelve. The acquirer reports the rate and the amount that the supplier didn’t, because in the acquirer’s country the transaction is taxable. Supplier and customer report the same transaction with different field sets. Any model that assumes one invoice produces one report will be wrong on both counts.

Two more constraints matter for anyone building this:

Cross-border is fixed; domestic is not. Recital 18 of ViDA states the reportable data should be the same in every member state, with no possibility for them to request additional data. But Article 271b(4), governing optional domestic digital reporting, says member states determine the data to be transmitted themselves. So there is no single reporting layer — there is one harmonised set for intra-EU, and up to 27 national sets for domestic. Greece’s myDATA already illustrates the shape: SAP’s implementation guide for Greek e-invoicing records the XML as carrying invoice type, total amount, net amount, VAT category, classification category and classification type, with the platform returning a MARK, a UID and a QR code that then have to be printed back onto the document.

The structured requirement attaches to the reportable subset, not the document. The new Article 217 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”. That qualifier is why hybrid formats survive: ZUGFeRD and Factur-X are compliant because the reportable data sits in the XML, whatever the PDF layer does.

The core layer: EN 16931, and why nobody agrees on the count

The directive asked CEN to build a semantic data model of the core elements of an electronic invoice. The Euro Retail Payments Board’s 2016 working group report quotes the directive’s own definition of those core elements: the essential information components an e-invoice must contain to enable cross-border interoperability, including what’s needed for legal compliance — to which the ERPB added, pointedly, that fiscal compliance is included too.

Ask how many business terms that produced and you get four answers. Material from CEN/TC 434’s own presentations describes about 160 elements in 33 element groups, with some 25 mandatory and 9 datatypes. Aleksandra Bal, writing in Forbes in January 2025, says over 160 semantic data fields. ValidateFin’s guide says approximately 170 business terms and business term groups. InvoStaq says 176. Nobody is lying: BT identifiers aren’t contiguous, business groups (BG) can be counted as fields or as containers, and the standard has been revised.

For a data team the useful number is the mandatory one — roughly 25 — because that’s the validation floor. Everything else is optional, conditional, or narrowed by whichever Core Invoice Usage Specification applies. CIUS restricts (Peppol BIS Billing 3.0 is a CIUS of EN 16931 on UBL 2.1); Extensions widen, and the European Commission maintains a registry of both. The German XRechnung Extension for the construction sector adds sub-invoice lines beneath a single invoice line and lets GAEB data ride along as an embedded XML attachment — an entire industry’s data model bolted onto the side of the core.

Here is the collision with the legal layer. EN 16931 makes fields mandatory that VAT law never asks for: CustomizationID (BT-24), ProfileID (BT-23) and BuyerReference (BT-10) are required for a valid Peppol BIS invoice and have no existence in Article 226 at all. They are routing and validation metadata. Article 226 says “only these”; the standard says “also these”. Both statements are true, because they are different instruments doing different jobs — and ViDA’s Article 218(4) confirms it by requiring member states to ensure e-invoices do two separate things: include the information required by the Directive, and respect the technical standards. Two tests, not one.

When they genuinely conflict, tax law wins over the technical standard. That’s the ordering to encode.

The commercial layer: UBL has no field count, and that’s the point

The UBL 2.1 Invoice element has roughly fifty direct children, and reading them tells you what layer you’re in. Alongside ID and IssueDate sit ProfileExecutionID, CopyIndicator, PricingCurrencyCode, PaymentAlternativeCurrencyCode, AccountingCostCode, LineCountNumeric and WithholdingTaxTotal. None of those is a VAT concept. Several aren’t an invoicing concept.

Asking for the total field count is an ill-posed question. UBL splits elements into cbc (common basic components — the leaves) and cac (common aggregate components — containers that expand recursively into addresses, parties, items, prices and tax categories, each drawn from a shared library used by every UBL document type, not just invoices). OASIS designed UBL as a generic interchange format to be restricted or extended per industry, aligned with ISO 20022 and built to carry invoice financing, factoring and letters of credit. The invoice is a projection of a much larger library, so the count depends entirely on where you stop expanding the tree — which is why no authoritative figure is published, and why claims of “thousands of fields” can’t be sourced to OASIS.

The practical consequence: Peppol BIS Billing 3.0 doesn’t ship its own XSD. It reuses the UBL 2.1 schema unmodified and layers Schematron rules on top. The constraint lives outside the syntax, because the syntax constrains almost nothing.

What the gap costs: a real mapping table

SAP Hellas’s August 2024 implementation guide for Greek e-invoicing contains the artefact most articles on this topic don’t have — an actual field mapping, ERP to tax-authority message. The proxy structure runs to around 170 distinct field names across eleven structures: header, B2G details, issuer, counter party, recipient, distribution details, payment details, line details (separately for SD and FI documents), taxes, summaries, VAT analysis and contract order details. The marker “NP” — not provided — appears more than 120 times.

That ratio is the story. The message schema carries slots for VAT_MEDIATOR, TRANSPORTER, SENDER, DISPATCH_ADVICE, LOT_NUMBER, ORDER_CODE, BANKS and MISCELLANEOUS_DATA, and for a normal Greek B2G invoice every one of them is empty. Meanwhile the fields that are populated pull data from places no invoice model would predict:

• CPV codes. Required by the tax authority for B2G, maintained in table T604F, and mapped per material on the International Trade tab of the material master. The guide notes that for FI invoices to public bodies a material code and plant have to be maintained during posting purely so the CPV code can be derived — a pure accounting document forced to carry logistics master data.
• The contracting authority. Carried by a special partner record whose Name1 through Name4 fields hold the authority name, authority code, contract type code and contract reference code. Four legal identifiers stuffed into four name fields, because the data model had nowhere else to put them.

None of those fields is in Article 226. None is in the ViDA reportable ten. Two of them aren’t in EN 16931’s core. They are the expensive ones anyway, because field-level mismatches surface as exceptions — and exceptions are where the cost lives. Billentis’s 2017 business case puts typically 20–30% of all invoices into exception handling under scan-and-capture or image-PDF workflows, against Finnish State Treasury estimates of about 10 euros to process an invoice semi-automated and about 1 euro fully automated.

Why the layers don’t nest, and how to model them anyway

Take four fields and check them against each layer:

• Buyer name and address — required by Article 226(5), required by EN 16931, not reported under ViDA.
• CustomizationID (BT-24) — required for a valid Peppol BIS invoice, absent from VAT law entirely.
• Supplier IBAN — absent from VAT law until 1 July 2030, then mandatory under Article 226(17), and reported.
• CPV code — not in VAT law, not in the EN 16931 core, mandatory for Greek B2G.

No layer contains another. Which gives four concrete rules:

Don’t build a canonical superset invoice. There is no schema that is simultaneously the legal minimum, the reportable set, the interoperable core and the syntax. Model the semantics once and project into each target, rather than growing one table until it satisfies everybody.

Model the legal set as the closed list it is. Seventeen points from July 2030, sourced from Article 226 — not inherited from whatever XSD your access point handed you.

Treat the reporting set as two things, not one. Ten fixed fields for intra-EU, set by Article 264 and identical in every member state. And a per-country data set for domestic reporting, defined nationally under Article 271b(4), which means the domestic reporting layer is a configuration surface, not a constant.

Bind to syntax at the edge. EN 16931 is syntax-neutral by design, with UBL 2.1 and UN/CEFACT CII as the two official bindings and lossless conversion between them. Model against the semantic layer; serialise late.

Frequently asked questions

Is EN 16931 the same thing as UBL?

No. EN 16931 is a semantic data model — it defines what an invoice means. UBL 2.1 is one of two XML syntaxes officially bound to it; UN/CEFACT CII is the other, used by ZUGFeRD, Factur-X and optionally XRechnung. The same EN 16931 invoice can be expressed in either, and converted between them without loss.

How many EN 16931 fields are actually mandatory?

Around 25 of roughly 160–176, depending on whose count you use. But a CIUS can make an optional core field mandatory in a given country or network, so the real answer is: 25 plus whatever your target CIUS adds. Validate against the CIUS, not the core.

Does a VAT-compliant invoice automatically pass EN 16931 validation?

No, and the reverse is also false. A paper invoice carrying every Article 226 detail is legally valid and fails EN 16931 outright. An EN 16931 invoice can be technically conformant while missing something national tax law requires. ViDA’s Article 218(4) treats these as two separate tests precisely because they are.

What exactly will ViDA report to the tax authority?

For an intra-EU B2B supply from 1 July 2030: Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where relevant — ten data points, eleven with the reverse-charge mention. Not the parties’ names and addresses. Not the VAT rate or amount, for exempt intra-Community supplies. The customer’s report of the same transaction carries twelve.

Which layer wins when they conflict?

Tax law, over any technical standard. In practice the sharper version of the question is which representation wins inside a hybrid invoice — and in Germany, the structured part governs where the PDF and XML disagree.

Both answers are correct, and which one applies depends on which directive is asking. Under the VAT Directive, an electronic invoice is one issued and received “in any electronic format” — a PDF qualifies. Under Directive 2014/55/EU, which governs invoicing to the public sector, an e-invoice must arrive in a structured format that a machine can process on its own — a PDF does not qualify. The same file can therefore be a fully valid e-invoice when you email it to a customer and not an e-invoice at all when you send it to a public authority in the same country on the same afternoon.

That gap is not a drafting accident. It exists because the two laws are asking different questions, and it is scheduled to close on 1 July 2030 — earlier in the member states that have already moved.

The two definitions, side by side

Article 217 of the VAT Directive (2006/112/EC, as amended by Directive 2010/45/EU) defines an electronic invoice as one containing the information the Directive requires, issued and received in any electronic format. It says nothing about structure, syntax, or machine readability. A scanned image, an emailed PDF, an EDIFACT message, and a UBL XML file all sit in the same legal box.

Directive 2014/55/EU defines it differently: an invoice issued, transmitted and received in “a structured electronic format which allows for its automatic and electronic processing”. The Euro Retail Payments Board’s 2016 working group report spelled out what that phrase does in practice — the invoice has to enable fully digital processing with no human copy-pasting or retyping data. That is a technical test, not a legal-form test, and a PDF fails it.

Why the VAT rule ignores format

VAT law does not ask whether a machine can read your invoice. It asks whether you can prove the invoice is genuine and unaltered. Article 233 requires authenticity of origin, integrity of content, and legibility from the moment of issue until the end of the storage period — and it lets you satisfy that through business controls creating a reliable audit trail, an advanced or qualified electronic signature, or EDI.

Business controls are the low-tech option, and they are why PDFs pass. In Austria, for instance, the requirement is an internal control procedure with an audit trail — matching the invoice against existing business documents such as the purchase order. Nothing about that requires structured data.

The 2016 edition of the E-Invoicing and Retention in Europe compendium, compiled by Peters, Schönberger & Partner with local tax practitioners in each market, asked the same question in 22 European countries: does an electronic invoice have to be in a structured data format such as XML? Every one of the 22 answered no, and every one confirmed PDF or PDF/A was acceptable for both issuance and storage. The nuances were small: Hungary restricted formats to a whitelist (which included .pdf) and required a digital signature or EDI, Romania then required an extended digital signature based on a qualified certificate and noted XML and PDF were merely preferred, and the UK’s HMRC listed EDI, XML, comma-delimited ASCII and PDF as examples without mandating any.

Retention rules were the opposite of harmonised. The same compendium recorded periods ranging from five years (Greece, Poland) to eleven (Croatia), with Austria stretching to 22 years for immovable property and Belgium to 15 for investment goods. France added a format condition that still catches people: electronic invoices must be archived in their original format for three years, within an overall ten-year retention period.

Why the public-procurement rule doesn’t

Directive 2014/55/EU exists to make invoices flow into government finance systems without anyone rekeying them. It commissioned CEN to build EN 16931 — a semantic data model for the core elements of an invoice, with a list of compliant syntaxes (UBL and UN/CEFACT CII, both XML). Per the European Commission’s own compliance roadmap, all central contracting authorities had to be able to receive and process EN 16931-compliant invoices by 18 April 2019, with an optional 12-month extension pushing sub-central authorities to 18 April 2020.

Here is the caveat almost every summary skips: the Directive obliges the contracting authority to receive and process compliant e-invoices. It does not, by itself, oblige the supplier to send them. Whether you must issue structured invoices to the public sector is a question of national transposition — and many member states went further than the Directive required. Greece is the clear case: Law 4601/2019 (articles 148–154) transposed the Directive, and ministerial decision ΚΥΑ 63446/2-6-2021 then defined the national B2G invoice format, with GSIS acting as the national Peppol authority.

Legal but useless: what the format actually costs

The VAT-legal PDF and the structured e-invoice are separated by roughly an order of magnitude in processing cost, and the sources are unusually specific about it.

Billentis’s 2017 business-case report cites Finnish State Treasury estimates that an incoming paper invoice costs the receiving company 30–50 euros. Moving to electronic invoicing cuts that to about 10 euros with a semi-automated process — and to about 1 euro when the process is fully automated. The PDF lands you in the middle tier. The structured invoice is what buys the bottom one.

Why the middle tier is expensive is not mysterious. Under a scan-and-capture or image-based PDF workflow, Billentis reports that typically 20–30% of all invoices have to be handled as exceptions in one form or another, which is where the processing cost concentrates. When a recipient feeds an emailed PDF into the same capture pipeline it uses for scanned paper, the report notes the resulting data quality is only slightly better than with paper. The invoice arrived instantly and cost nothing to post — and then joined the same queue.

The report’s modelled recipient case (an industrial company with 5,000 employees, staff costed at 60 euros per hour) puts full paper processing at 17.60 euros per invoice against 6.40 euros for an electronic, automated flow — a 64% saving. On the issuing side the same case shows 11.10 euros against 4.50, or 59%. That distribution is the point Billentis draws out: the benefits of image-based PDFs sit mainly with the supplier, which is why larger recipients stay sceptical of them. Analysis from Politecnico di Milano, also cited in the report, put net benefits at 4–12 euros per invoice for VAT-compliant e-invoicing, rising to as much as 65 euros per cycle where the whole trade process is integrated.

These are 2017 figures; read them as a ratio, not a price list. The ratio is the argument. It is the same one behind Billentis’s estimate of a minimum 40 billion euro annual saving potential in Europe’s public sector, of which under 10% was then being exploited — an estimate whose model assumed 40% of e-invoices were unstructured PDFs and 60% structured XML, and which noted that administrations insisting on structured data only would do better.

What changes on 1 July 2030

ViDA — Council Directive (EU) 2025/516, adopted 11 March 2025 and in force since 14 April 2025 — resolves the contradiction by deleting one side of it. From 1 July 2030, Article 217 is replaced: an electronic invoice will mean one that, “at least in relation to the data referred to in Articles 262 and 271b”, has been issued, transmitted and received in a structured electronic format allowing automated processing. Recital 9 says plainly that this is being done to align the VAT definition with the one in Directive 2014/55/EU.

Four details matter more than the headline:

• Hybrid invoices survive. Recital 9 explicitly covers invoices that combine a structured part with an unstructured human-readable part, provided all reportable data sits in the structured part. ZUGFeRD and Factur-X are not casualties. PDF-only is.
• EN 16931 becomes the default, not the ceiling. The new Article 218(3) requires e-invoices to comply with the European standard, while letting member states allow other standards for domestic supplies outside the cross-border reporting scope.
• Consent disappears. Under the revised Article 232, issuing an EN 16931-compliant e-invoice to a taxable person will not require the recipient’s acceptance.
• The stakes rise from inconvenience to deductibility. ViDA lets member states provide that a customer may deduct or reclaim VAT only if it holds an e-invoice issued in the required format. At that point “legal but useless” stops being the failure mode; “not deductible” replaces it.

Two dates qualify the 2030 headline. Since 14 April 2025, member states no longer need a Commission derogation to mandate domestic e-invoicing — which is why the national mandates are arriving early. And member states that already had a domestic real-time transaction reporting obligation in place on 1 January 2024 have until 1 January 2035 to align those domestic systems.

Germany and Greece already flipped the definition

Germany is the cleanest illustration, because it changed the definition itself rather than bolting a reporting platform on top of the old one. Under the Wachstumschancengesetz, § 14 UStG redefined the electronic invoice with effect from 1 January 2025: a PDF sent by email is no longer an E-Rechnung but a sonstige Rechnung — an “other invoice”. The receiving obligation carried no transition period at all; every domestic business has had to be able to receive EN 16931-compliant invoices since 1 January 2025, and per the Federal Ministry of Finance’s guidance an email inbox is technically sufficient. Issuance is phased: paper and other electronic formats (with recipient consent) run through 2026, only businesses under 800,000 euros in prior-year turnover keep them in 2027, and from 1 January 2028 all domestic B2B invoices must be structured. In a hybrid invoice, the BMF’s October 2025 letter makes the structured part authoritative — and if the PDF layer disagrees with the XML, the divergent PDF can be treated as an additional invoice, with § 14c VAT liability attached.

Greece shows the same shift arriving through the tax-reporting door rather than the VAT-definition door. Authorised by Council Implementing Decision (EU) 2025/502, mandatory B2B e-invoicing went live on 2 March 2026 for businesses with over 1 million euros of 2023 revenue (penalties from 3 May 2026), with all remaining established businesses following on 1 October 2026. Invoices clear through myDATA, which returns a MARK and QR code — and an invoice never transmitted through the platform is not deductible for the buyer, regardless of whether the underlying transaction was real.

The pull-through effect was visible in Greece before either mandate. SAP’s August 2024 implementation guide for Greek e-invoicing records that once a company was issuing B2G invoices through a certified provider, the tax authority’s e-books rules forced it to submit all wholesale invoices — B2B included — through that same provider. The B2G requirement reached into B2B years ahead of the B2B mandate.

Set that against the 2016 compendium, where the Greek answer was the same as everyone else’s: no format required, PDF is fine. That answer was correct when it was written. It had an expiry date nobody printed on it.

Four things people get wrong

“PDFs are being banned”

No. Hybrid formats that embed structured data in a PDF container remain valid under ViDA, and member states can still permit other formats for transactions outside the reporting scope. What is ending is the PDF that contains nothing a machine can extract.

“It’s electronic, so it’s an e-invoice”

Only under Article 217 as it reads until 30 June 2030, and only where no national mandate says otherwise. In Germany that sentence has been wrong since January 2025.

“The B2G directive forces suppliers to send structured invoices”

It forces authorities to receive them. Your obligation to send comes from national law, which varies by country.

“An e-invoice is an e-invoice for both parties”

Not necessarily. Under the French rules recorded in the 2016 compendium, a recipient who printed an electronic invoice and deleted the data file was no longer holding an electronic invoice at all — on their side. Status can depend on what the receiver does after delivery, which is also why archiving the structured original matters: France requires the original format for three years, and Germany requires at least the structured part of an E-Rechnung to be kept intact.

Frequently asked questions

Is a PDF invoice legal in the EU?

Yes, for VAT purposes, under the current Article 217 definition — provided you can ensure authenticity of origin, integrity of content and legibility, typically through business controls with a reliable audit trail. That changes where a national mandate has already redefined the term, as in Germany since January 2025 and Greece for in-scope businesses since March 2026.

Does a PDF invoice need a digital signature?

Generally no. In the 22 countries surveyed in the 2016 PSP compendium, almost all answered that no digital signature was required where authenticity and integrity were otherwise ensured; Hungary (signature or EDI) and Romania (extended signature on a qualified certificate) were the exceptions of the time. Signatures are one permitted method under Article 233, not a requirement.

Is ZUGFeRD or Factur-X a PDF or an e-invoice?

Both, and that is the point. They are hybrid formats: a human-readable PDF carrying structured XML. ViDA’s recital 9 confirms hybrids fall inside the new definition as long as all reportable data is in the structured part. In Germany, the structured part governs if the two layers disagree.

Do I still need the buyer’s consent to send an e-invoice?

Today, yes in most cases — Article 232 makes electronic invoicing subject to recipient acceptance, though the 2016 compendium found that acceptance could usually be given tacitly, in Hungary even by simply paying the invoice. From 1 July 2030 consent falls away for EN 16931-compliant invoices issued to taxable persons, and member states have been able to remove it domestically since April 2025.

How long do I have to keep an electronic invoice?

There is no single EU answer. Periods in the 2016 compendium ran from five years to eleven, with longer terms for real estate and investment goods. Check the rule in each country where you are established or registered, and check the format condition as well as the duration.