PDF/A-3B and ZUGFeRD: Is My E-Invoice PDF Really Compliant? (veraPDF)

ZUGFeRD is a hybrid invoice: a human-readable PDF plus the machine-readable XML inside it. The PDF part must be a special archival variant – PDF/A-3. This is exactly where most misunderstandings arise.

> Quick answer: For a PDF to truly be PDF/A-3(-B), among other things all fonts must be embedded, an OutputIntent/ICC colour profile must be present, and the PDF/A metadata must match. A validator like veraPDF checks this but repairs nothing. If the source PDF is not compliant (e.g. non-embedded fonts), only a genuine conversion helps – or you use pure XRechnung.

What PDF/A-3 requires

PDF/A is designed so that a document is displayed identically on any computer and many years from now. This comes with strict rules, the most important being:

1. All fonts embedded – the file must contain the font data itself and must not rely on the reader having, say, Arial installed.
2. OutputIntent / ICC colour profile – the file must define how colours are reproduced.
3. PDF/A XMP metadata – the marking that identifies the file as PDF/A-3.

The common stumbling block: non-embedded fonts

Older ERP and invoicing systems frequently produce PDFs that reference system fonts such as Arial or Arial Bold but do not embed them. Such a file is already not PDF/A compliant – and this cannot be fixed simply by adding the ZUGFeRD XML and PDF/A metadata.

Validating is not converting

An important point: veraPDF only validates, it does not convert. A validator reports „not compliant“ but does not turn a non-compliant file into a compliant one. To actually produce PDF/A-3, you need a genuine conversion step that embeds the fonts and adds a colour profile (e.g. with Ghostscript or the ZUGFeRD reference library Mustangproject).

What is always correct: the XML

Regardless of the PDF container, the decisive, legally authoritative part is the structured XML. At TaxLayer this is fully validated against the KoSIT verification standard and EN 16931 (0 errors). The invoice data itself is therefore correct and compliant – the PDF/A question concerns only the outer shell.

How to reach the goal reliably

• Option A – export PDF/A from the system: if your ERP system can output the invoice as PDF/A (with embedded fonts), the ZUGFeRD file generated from it is compliant.
• Option B – use pure XRechnung: with XRechnung (pure XML), the PDF container is dropped entirely, so the question of PDF/A compliance does not arise.

Conclusion

PDF/A-3 is more than a label: it requires embedded fonts, a colour profile, and the correct metadata. If you are coming from an older system, it is best to export PDF/A directly – or rely on XRechnung, where the PDF container plays no role.

---

The e-invoice XML at TaxLayer is always EN 16931 and KoSIT validated. Questions about PDF/A compliance? Write to info@landauer.de.