E‑Invoicing & E‑Reporting Explained: XML Is the Invoice, the PDF Is Only Its Picture

For more episodes, click E‑Invoicing & E‑Reporting Explained: From Invoice to Intelligence (WIP) – VATupdate

Executive Summary

This briefing highlights a critical shift in the understanding of what constitutes a legally valid invoice under modern e-invoicing and e-reporting mandates. Increasingly, the structured XML transmitted to tax authorities is the sole legally relevant invoice, while human-readable formats like PDFs are merely visualisations or convenience copies. Confusing these roles, or allowing material discrepancies between the XML and its PDF representation, creates significant compliance risks, including potential duplicate VAT liabilities. This issue, recently emphasized by Polish KSeF guidance, is universal and requires proactive governance and rigorous process control.

Key Themes and Important Ideas

The Core Distinction: XML is the Invoice, PDF is the Picture

Under virtually all clearance and continuous-transaction-control (CTC) e-invoicing mandates, the structured data file (XML) is the definitive legal document. The PDF, or any paper document, serves as a human-readable representation for convenience, approval, or archiving, but it does not hold the same legal weight as a separate invoice.

Quote: “Under virtually every clearance and continuous-transaction-control mandate, the structured XML transmitted to (or cleared by) the authorities is the single legally relevant invoice. The PDF or paper document that businesses still generate is a visualisation – a convenience copy for reading, approval, dispute handling and archiving – and not a second invoice.”
Structured Invoice Definition: A structured invoice is machine-readable, with every value (seller, buyer, amounts, VAT) in defined fields processable by software. The European standard EN 16931 (UBL or UN/CEFACT CII) is the typical model. A “PDF by e-mail” is an image of data, not structured data itself.

The Risk of Discrepancy: A “Second Invoice” and Duplicate VAT

The primary compliance risk arises when a PDF visualisation deviates materially from its underlying XML. Such a PDF risks being treated as a separate, additional invoice by tax authorities.

Quote: “Confusing the two is where compliance risk begins, because tax law attaches consequences to whichever document actually shows the VAT.”
Duplicate VAT Mechanism: Article 108 of the Polish VAT Act (and Article 203 of the EU VAT Directive) dictates that a person issuing a document showing VAT can be liable to pay that VAT, even if the underlying supply was correctly invoiced via XML. If a PDF “carries the core features of an invoice but differs materially from the KSeF XML, it risks being regarded as an additional invoice, creating duplicate-VAT exposure.”

High-Risk vs. Low-Risk Differences

Not all discrepancies between XML and PDF are equally problematic:

Higher-Risk Differences (Material): These alter the commercial or fiscal understanding of the supply and can lead to duplicate VAT exposure. Examples include:
A different buyer or delivery entity.
Changed descriptions, quantities, or units.
Inconsistent net, VAT, or gross values.
Different payment or settlement terms.
An additional transaction shown only on the PDF.
Manually inserted data that alters the meaning of the supply.
Low-Risk Differences (Cosmetic): These are generally defensible as they do not change the substance. Examples include:
Company logo, layout, font choice, or pagination.

Architectural Models for E-Invoicing

Two main architectures address the relationship between XML and its visualisations:

Separate XML and PDF (e.g., Poland KSeF, Italy SdI):The XML is transmitted to a government platform for validation/clearance.
The PDF is generated separately from the same source data.
The XML is authoritative; the PDF is a courtesy copy.
Challenge: Keeping these physically distinct artifacts consistent is a “process discipline, not an automatic guarantee.”
Hybrid Files (e.g., Factur-X / ZUGFeRD):The EN 16931 XML is embedded within a PDF/A-3 file.
The PDF layer is human-readable, while the embedded XML is machine-readable.
Advantage: “Reconciliation problem is largely solved by design” if the PDF layer is genuinely rendered from the embedded XML.
Challenge: Risk still exists if the PDF layer is edited or generated from a different or abbreviated dataset than the embedded XML.

E-Reporting and Data Consistency

E-reporting involves transmitting transaction data to authorities, often derived from invoices. The same economic event can exist in three forms: the structured invoice (XML), its visualisation (PDF), and one or more reporting datasets.

Quote: “Each is derived from the same source, and each must remain consistent with the others.”
Discrepancies across these forms are “exactly the kind of mismatch a data-driven tax administration is now built to detect automatically.”

Archiving Requirements: Storing the “Original”

Archiving rules mandate retaining the “original” format.

For pure-XML mandates, the XML file is the tax-relevant document.
For hybrid formats (e.g., Factur-X), the PDF/A-3 with its embedded XML is the original.
EU Framework (Article 233 of the EU VAT Directive): Authenticity of origin, integrity of content, and legibility must be guaranteed throughout the retention period.
National requirements for retention periods and formal preservation (e.g., Italy’s conservazione sostitutiva) still apply.

Practical Compliance Recommendations

To mitigate compliance risks, businesses should:

Adopt one controlled XML-to-PDF template: Generate visualisations automatically and prohibit manual amendments to generated PDFs.
Put material information in the structured file: Ensure essential payment or transaction data is in the XML, not solely on the PDF.
Run a field-by-field reconciliation: Test that all critical data elements (parties, descriptions, amounts, terms) match exactly between the PDF and XML.
Keep cosmetic freedom, avoid substantive edits: Branding is fine; altering commercial or VAT substance is not.
Include required verification elements: Add QR codes or verification references to PDFs to link them back to the authoritative XML.
Watch hybrids as closely as separate files: Ensure the rich PDF layer genuinely reflects the embedded XML.
Archive the original format for the full period: Preserve the XML (or PDF/A-3 for hybrids) with guaranteed authenticity, integrity, and legibility, aligned with national rules.

Conclusion

The transition to mandatory e-invoicing fundamentally redefines the invoice. While the PDF remains a necessary tool for human interaction, its legal status has been “demoted.” The structured XML is now the legal invoice, and any material divergence in its human-readable “picture” can lead to serious compliance issues, particularly the risk of duplicate VAT. Adopting a rigorous approach to governance, automated generation, and data consistency across all representations is crucial to navigating this new regulatory landscape.

Quote: “The shift to mandatory e-invoicing does not abolish the PDF – it demotes it. The structured XML is now the invoice in law; the PDF is its picture. That reordering is easy to state and easy to get wrong, because most finance and IT processes were built around a world where the readable document was the invoice.”

Extended article

The XML Is the Invoice, the PDF Is Only Its Picture: Keeping Human-Readable Copies Faithful to the Structured File

Published on VATupdate.com – practical guidance for tax, finance and IT teams operating under e-invoicing and e-reporting mandates.

Summary

Under virtually every clearance and continuous-transaction-control mandate, the structured XML transmitted to (or cleared by) the authorities is the single legally relevant invoice. The PDF or paper document that businesses still generate is a visualisation – a convenience copy for reading, approval, dispute handling and archiving – and not a second invoice. Confusing the two is where compliance risk begins, because tax law attaches consequences to whichever document actually shows the VAT.

The recent Polish debate on KSeF crystallises a wider truth: a PDF that departs materially from its underlying XML (different buyer, amounts, VAT, payment terms or extra transactions) may be treated as a separate invoice, triggering the “who invoices VAT, pays VAT” rule (Article 108 of the Polish VAT Act; Article 203 of the EU VAT Directive). Purely cosmetic differences – logo, layout, font, pagination – are far easier to defend and generally unproblematic.

The practical answer is governance, not creativity: one controlled XML-to-PDF template, no manual edits to generated visualisations, all material data placed in the structured file rather than only on the PDF, and archiving of the original format (the XML, or the PDF/A-3 for hybrids) for the full retention period. Authenticity, integrity and legibility must survive from issuance to audit, in line with Article 233 of the EU VAT Directive.

1. Why this question suddenly matters

Ten years ago an invoice was, for most businesses, a PDF sent by e-mail or a sheet of paper. Today, in a fast-growing list of jurisdictions, the legally binding invoice is a structured data file – an XML document that a machine reads and that the tax authority receives, validates or clears in near real time. Yet the PDF has not disappeared. Businesses keep producing a human-readable rendering for their own records, for customers who still want something to look at, and because auditors routinely ask for a legible document. This companion piece to From Invoice to Intelligence: E-Invoicing & E-Reporting Explained focuses on one deceptively simple question with real VAT consequences: when the XML and the PDF describe the same sale, which one is the invoice – and what happens if they disagree?

The trigger for this article is a Polish contribution reminding taxpayers that a KSeF invoice PDF must remain faithful to the underlying XML (see KSeF invoice PDFs must remain faithful to the underlying XML). The point is Polish in its detail but universal in its logic, and every business rolling out e-invoicing should internalise it now.

2. The core distinction: structured invoice versus visualisation

2.1. What “structured” really means

A structured invoice is machine-readable: every value – seller, buyer, line items, quantities, net amounts, VAT rates and totals – sits in a defined field that software can process automatically, without OCR or template matching. In the EU this semantic model is the European standard EN 16931, typically expressed in one of two syntaxes (UBL or UN/CEFACT CII). A “PDF by e-mail” is not a structured invoice: it is an image of data, not the data itself.

2.2. The visualisation is a copy, not an invoice

Because raw XML is inconvenient for everyday commercial use, businesses render it as a PDF or a printout. Most mandates leave the visual design free – companies may use their own branding, table structure and layout. That flexibility stops at the substance: the visualisation must faithfully reproduce the transaction and VAT data of the structured file. It is a human-readable representation of the cleared invoice, not an alternative commercial document that a business is free to re-write.

3. Two architectures for the same problem

3.1. Separate XML and PDF (Poland, Italy and most CTC systems)

In clearance and continuous-transaction-control (CTC) models, the XML is transmitted to a government platform and the PDF is generated separately, on the side, from the same source data. Italy’s Sistema di Interscambio (SdI) is the archetype: the FatturaPA XML that passes SdI validation is the invoice, while a PDF may be supplied only as a courtesy copy and never substitutes the required XML. Poland’s KSeF works on the same principle: the FA(3) structured file cleared by the system is authoritative, and the PDF is merely its visualisation. Here the two artefacts are physically distinct, so keeping them consistent is a process discipline, not an automatic guarantee.

3.2. Hybrid files: one container, two layers (Factur-X / ZUGFeRD)

The Franco-German Factur-X / ZUGFeRD format takes a different route: it embeds the EN 16931 CII XML inside a PDF/A-3 file. The person sees a normal PDF; the software extracts the attached XML. Because the two layers live in one artefact generated from a single dataset, the reconciliation problem is largely solved by design – provided the PDF layer is genuinely rendered from the same XML and not edited afterwards. France’s 2026 reform relies heavily on this hybrid approach, alongside pure UBL and CII flows.

The lesson is that hybrids reduce, but do not eliminate, the discipline problem: if a system produces a rich-looking PDF layer but embeds an abbreviated or inconsistent XML, the same divergence risk returns – now hidden inside a single file.

4. The Polish warning, generalised: when a PDF becomes a second invoice

4.1. The duplicate-VAT mechanism

Under Article 108 of the Polish VAT Act – the national expression of Article 203 of the EU VAT Directive (2006/112/EC) – a person who issues a document showing VAT can be liable to pay that VAT, even where the underlying supply has already been correctly invoiced. If a PDF carries the core features of an invoice but differs materially from the KSeF XML, it risks being regarded as an additional invoice, creating duplicate-VAT exposure on top of the properly cleared transaction.

4.2. Higher-risk versus low-risk differences

Following the Polish guidance, the differences that matter are those that change the commercial or fiscal understanding of the supply:

a different buyer or delivery entity;

changed descriptions, quantities or units;

inconsistent net, VAT or gross values;

different payment or settlement terms;

an additional transaction shown only on the PDF;

manually inserted data that alters the meaning of the supply.

By contrast, purely graphical differences – a company logo, column positions, font choice or pagination – are generally defensible, provided the content matches and the document clearly functions as the visualisation of a specified cleared invoice. Where the system allows it, optional business information should be placed in available structured fields (for KSeF, the FA(3) fields) rather than added only to the external PDF.

5. E-reporting: the same data, transformed again

E-invoicing and e-reporting are related but distinct. E-invoicing concerns the exchange of the invoice itself; e-reporting concerns the transmission of transaction data to the authorities, whether extracted from the invoice or reported separately (for example for cross-border, B2C or payment data). The same economic event may therefore exist in three shapes at once: the structured invoice (XML), its visualisation (PDF), and one or more reporting datasets. Each is derived from the same source, and each must remain consistent with the others. A discrepancy between what was cleared, what was shown to the customer and what was reported is exactly the kind of mismatch a data-driven tax administration is now built to detect automatically.

6. Archiving: which version is the “original”?

6.1. Store the original format, not the printout

Archiving rules answer the “which version” question bluntly: keep the original. For pure-XML mandates, the tax-relevant document to preserve is the XML file; a PDF rendering is useful for reading but does not replace it. For hybrids, the original is the PDF/A-3 with its embedded XML. Under the EU framework, authenticity of origin, integrity of content and legibility must be guaranteed throughout the retention period – the trio set out in Article 233 of the EU VAT Directive.

6.2. National detail still matters

Retention periods and formal requirements remain national. Belgium’s tax administration sets out its expectations on legibility, authenticity and integrity in its e-invoicing archiving FAQ. France’s 2026 reform requires a compliant electronic archiving system and preservation of the exchanged invoice version together with related documents and audit-trail evidence (see France’s 2026 e-invoicing archiving requirements). Italy imposes certified electronic preservation (conservazione sostitutiva) for ten years. The common thread: the archived file must be provably identical to the one issued or received.

7. Practical compliance recommendations

Adopt one controlled XML-to-PDF template. Generate every visualisation automatically from the approved structured payload, and prohibit manual amendments to generated PDFs.

Put material information in the structured file. Never place essential payment or transaction data only on the PDF; use the available structured fields (e.g. FA(3) for KSeF) so nothing lives outside the cleared XML.

Run a field-by-field reconciliation. Test that parties, descriptions, quantities, net, VAT and gross amounts and payment terms on the PDF match the XML exactly before any customer-facing document is released.

Keep cosmetic freedom, avoid substantive edits. Branding, layout and fonts are fine; anything that changes the commercial or VAT substance is not.

Include required verification elements. Where a cleared invoice is used outside the system, add the prescribed QR code or verification reference so the PDF can be tied back to the authoritative file.

Watch hybrids as closely as separate files. Do not let a rich PDF layer sit on top of an abbreviated embedded XML; the two layers must be generated from the same complete dataset.

Archive the original format for the full period. Preserve the XML (or PDF/A-3 for hybrids) with guaranteed authenticity, integrity and legibility, and align retention with each country’s rules.

8. Conclusion

The shift to mandatory e-invoicing does not abolish the PDF – it demotes it. The structured XML is now the invoice in law; the PDF is its picture. That reordering is easy to state and easy to get wrong, because most finance and IT processes were built around a world where the readable document was the invoice. The Polish KSeF debate is a timely reminder that a stray divergence between the picture and the file is not a cosmetic issue but a potential duplicate-invoice, duplicate-VAT problem. Treat the visualisation as a faithful, controlled rendering of the cleared data – never as a document your teams are free to reshape – and the risk largely disappears.