VATupdate

Share this post on

FacebookXEmailLinkedInWhatsApp
World

VAT headaches: E-Invoicing Mismatches – When the Legal Invoice and the ERP Output Differ

3 weeks ago
83 views
8 min read

Slide deck

For all episodes of ‘VAT Headaches: The Errors, Pitfalls and Grey Zones That Keep VAT Experts Awake at Night – VATupdate

Executive Summary

  • The issue: Under modern clearance and continuous-transaction-control (CTC) mandates, the structured file (XML) transmitted to or cleared by the tax authority is the single legally relevant invoice, while the PDF or ERP printout your business, customer and auditors actually look at is only a visualisation. When the two diverge — different amounts, VAT codes, dates, or line items — you no longer have “one invoice in two forms”. You have a legal document and a commercial document that disagree. [vatupdate.com], [myinvoice.llc]
  • The VAT risk: A PDF that materially deviates from its underlying XML can be treated by a tax authority as a separate, additional invoice. Under Article 203 of the EU VAT Directive (and its national transpositions, such as Article 108 of the Polish VAT Act), whoever issues a document showing VAT can be liable to pay that VAT — even if the same supply was already correctly invoiced through the cleared XML. The result is duplicate VAT, disputed input-tax deduction for the customer, and reconciliation headaches. [vatupdate.com]
  • The takeaway: The XML and its human-readable rendition must be derived from a single source of truth and validated against each other. Treat the PDF as a picture of the legal invoice, never as a parallel document that can drift. Governance, not goodwill, keeps them aligned. [vatupdate.com], [pokutsoft.com]
  1. Two representations, one invoice — until they aren’t

For most of VAT’s history, “the invoice” was the document you could hold, read and file: paper, then a PDF. Digitalisation has quietly inverted that. Under virtually every clearance and CTC mandate, the structured XML transmitted to (or cleared by) the authorities is the invoice; the PDF or paper copy that businesses still generate is a convenience copy for reading, approval, dispute handling and archiving — not a second invoice. [vatupdate.com]

This is not a stylistic preference. The EU’s VAT in the Digital Age (ViDA) package changes the very definition of an electronic invoice from a digital document to structured, processable data — an invoice issued, transmitted and received in a structured electronic format (such as XML) that supports automatic processing. A PDF sent by email is an image of data, not structured data, and will fail the form requirement for the cross-border Digital Reporting Requirements. The legal package rests on Directive (EU) 2025/516 and Regulation (EU) 2025/517, with the harmonised regime taking effect in July 2030. [rtcsuite.com], [fiskaly.com] [vatupdate.com], [edicomgroup.com]

The semantic backbone is the European standard EN 16931, which defines every value — seller, buyer, amounts, VAT breakdown — as a labelled field in one of two permitted syntaxes (UBL 2.1 or UN/CEFACT CII). The 2026 revision (EN 16931-1:2026) was ratified specifically to support B2B transactions and Digital Reporting Requirements under ViDA. The moment your ERP produces a PDF whose figures are not a faithful rendering of those EN 16931 fields, you have manufactured a mismatch. [blog.seeburger.com], [invoicenavigator.eu]

  1. Where the mismatch actually comes from

Mismatches are rarely the result of fraud. They are the by-product of two systems generating two outputs from different logic:

  • The commercial PDF path — driven by the ERP’s output/print program, sales templates, rounding conventions, currency formatting and free-text descriptions built for the customer’s eye.
  • The structured e-invoice path — driven by a mapping layer, tax-determination engine or middleware that populates EN 16931 fields for the clearance platform.

When these two paths are not fed from a single source of truth, drift is almost guaranteed. Common divergence points include:

  • Rounding and VAT breakdown: the PDF rounds at document level while the XML rounds per VAT rate (or vice versa), producing a different total VAT (BT-110) than the printed figure. The updated Factur-X/ZUGFeRD specifications specifically corrected rounding and VAT-breakdown rules for exactly this reason. [vatupdate.com]
  • Aggregated vs. component lines: the commercial invoice shows a bundle or kit as one line, while downstream tax and reporting systems require component-level detail — the driver behind the new sub-line handling in Factur-X 1.09.2 / ZUGFeRD 2.5.2. [vatupdate.com]
  • VAT treatment: the PDF states “reverse charge” in free text, but the XML carries the wrong VAT category code (e.g. UNTDID 5305 “AE”), or an exemption reason is present in one representation and absent in the other. [pokutsoft.com]
  • Timing and identity: different issue dates, invoice numbers, or currency/decimal handling (ISO 4217 minor units) between the two outputs. [pokutsoft.com]
  1. The core legal risk: a “second invoice” and duplicate VAT

Here is where a formatting nuisance becomes a tax liability. Tax law attaches consequences to whichever document actually shows the VAT. If the PDF visualisation materially deviates from its underlying XML, a tax authority can treat that PDF as a separate document showing VAT. [vatupdate.com]

The mechanism is Article 203 of the EU VAT Directive (transposed, for example, as Article 108 of the Polish VAT Act): a person who enters VAT on an invoice is liable to pay that VAT — regardless of whether the underlying supply was already correctly invoiced elsewhere. If the cleared XML shows €257.78 of VAT and the emailed PDF shows a different figure, you risk being assessed on both. Polish KSeF guidance recently made this concrete, but the exposure is universal across clearance and CTC regimes. [vatupdate.com]

The downstream damage compounds:

  • The customer’s deduction is jeopardised — they may hold a PDF that no longer matches the only invoice the authority recognises, undermining their input-VAT claim.
  • Reconciliation and audit fail — pre-filled returns and authority cross-matching (the new Central VIES under ViDA) compare reported XML data against declared positions; a divergent PDF cannot be reconciled cleanly. This is the same trap explored in the companion piece The Return That Files Itself? Pre-Filled VAT Returns and the Illusion of Accuracy: reported does not mean correct. [vatupdate.com] [vatupdate.com]
  1. Hybrid formats reduce the risk — but do not eliminate it

The Franco-German hybrid formats Factur-X (France) and ZUGFeRD (Germany) were designed precisely to close the gap: a single PDF/A-3 file carries a human-readable page with the EN 16931 CII XML embedded inside it. Compliant receivers extract and process the XML; everyone else reads the PDF — one artefact, two representations, bound to the same source. The formats are technically identical from ZUGFeRD 2.1 onward, and the latest releases — Factur-X 1.09.2 / ZUGFeRD 2.5.2 — were published on 4 August 2026, effective 1 September 2026. [myinvoice.llc], [invoicenavigator.eu] [vatupdate.com]

But bundling the two into one file does not guarantee they agree. Nothing physically prevents an ERP from embedding an XML that says one thing and printing a PDF layer that says another. The hybrid container makes alignment easier to achieve and easier to audit — it does not make it automatic. For fully electronic B2B relationships, pure UBL/CII formats such as Peppol BIS Billing 3.0 avoid a rendered layer altogether, and a human-readable PDF can be re-derived from the XML on demand rather than produced independently. [pokutsoft.com], [fakturate.com]

  1. Governance: keeping the legal invoice and the ERP output in lockstep

The fix is process control, not luck. Practical safeguards:

  • Single source of truth. Generate both the XML and the visualisation from the same validated data set. Never let the print program and the mapping engine calculate independently. [vatupdate.com]
  • Render, don’t re-author. Produce the human-readable PDF from the cleared XML (as EN 16931 rendering tools do), so the picture cannot drift from the data. Tools that re-derive every total from the XML and display a “totals reconcile” badge illustrate the principle. [pokutsoft.com]
  • Validate against EN 16931. Run the XML through official Schematron/business-rule validation (EN 16931, Peppol, national CIUS such as XRechnung or KoSIT) before transmission, so structural and arithmetic errors are caught upstream. [fakturate.com]
  • Reconcile the two representations. Where a separate PDF must exist, run an automated field-level comparison (amounts, VAT codes, dates, invoice number) against the XML and block release on any material delta. [vatupdate.com]
  • Fix the “PDF by email” habit. Under Belgium’s B2B mandate (since 1 January 2026), France’s reception mandate (from 1 September 2026) and Germany’s phased rollout, a standalone PDF is no longer a compliant invoice where a mandate applies — retiring parallel PDF flows removes a whole class of mismatches. [fakturate.com], [e-invoice.app]
  1. Bottom line

In the digital age, the XML is the invoice; the PDF is only its picture. Structured data and commercial output are not two invoices to be kept “roughly consistent” — they are one legal instrument and its rendition, and tax authorities attach VAT consequences to whichever document shows the VAT. Treat every divergence between the cleared file and the ERP printout as a potential Article 203 exposure, engineer both outputs from a single validated source, and validate them against each other before anything leaves your system. Alignment is cheaper than a duplicate-VAT assessment. [vatupdate.com], [rtcsuite.com]

Further reading on VATupdate.com

Latest Posts in "World"

Sponsors:

Pincvision
Fiscal Solutions Bottom

Advertisements:

  • RTC