PDF/A-3 and e-invoicing
A hybrid e-invoice is a file that can be used by two different readers: a person can open it and see an invoice, while an accounting system can open it and find structured XML. PDF/A-3 makes this possible. It is the first part of ISO 19005 to allow a file of any format to be embedded inside an archival PDF.
Why the container has to be PDF/A at all
An invoice is a record that is subject to a retention obligation, which is commonly ten years in the EU. In most regimes, the visual document is the legally meaningful artefact, so it must still render correctly at the end of that period. This means that fonts must be embedded, colours defined, and nothing must be external or encrypted. This is precisely the issue that PDF/A is designed to address, which is why e-invoicing specifications are based on it rather than plain PDF.
The formats you will actually encounter
Beneath the national names lies one semantic model: EN 16931. This model defines what an invoice is. The formats differ in terms of their syntax and how they are transported.
| Format | Shape | Where it is used |
|---|---|---|
| ZUGFeRD / Factur-X | Hybrid: PDF/A-3 with embedded CII XML | Germany (ZUGFeRD) and France (Factur-X); the same specification under two names. |
| XRechnung | Pure XML (UBL or CII) | German public-sector invoicing. A national CIUS of the EN 16931 semantic model. |
| FatturaPA | Pure XML, submitted through a state exchange system | Italy, the earliest large-scale mandatory e-invoicing regime in the EU. |
| Peppol BIS Billing | Pure XML (UBL) over the Peppol network | Cross-border exchange across the EU and beyond. |
Only the first row is a PDF issue. The rest are XML documents that never go through a PDF toolchain.
What PDF/A-3 requires of the container
- PDF/A-3 requires everything that PDF/A-2 requires, such as embedded fonts, defined output intent and conformant metadata. It also requires that the file is not encrypted or contain executable content. It requires an embedded file stream for the XML payload, reachable from the document catalog's names tree and, in the e-invoicing profiles, also from the page's file attachment relationship, an AFRelationship value on the embedded file (
/Data,/Sourceor/Alternative) declaring how the attachment relates to the visible document, an XMP extension schema in the document metadata identifying the profile, its version and the filename of the payload, letting a receiving system detect a hybrid invoice without opening the attachment.
Finally, none of that removes the usual PDF/A obligations. A ZUGFeRD file with a perfect XML payload and an unembedded font is not a valid e-invoice. It fails as a PDF/A-3 document and will be rejected by most receiving systems on that basis.
Proper validation requires two checks
A hybrid invoice has two independent failure modes, and tools tend to cover only one:
- The container. Is it a conformant PDF/A-3 file, with the attachment, relationship and XMP extension schema the profile requires? That is a PDF validation problem.
- The payload. Is the XML valid against its schema, and does it satisfy the EN 16931 business rules and any national CIUS on top? That is an XML/Schematron problem.
Where gopdfrab is heading
Today gopdfrab verifies and converts PDF/A-1b.
What the current implementation does give you is the layer underneath: a pure-Go engine you can call on every invoice as it arrives rather than in a nightly batch, including from a serverless function. The PDF/A-1b clauses that e-invoices most often trip over are already covered: unembedded fonts, missing output intents, metadata mismatches. Those checks carry forward unchanged into the later parts.
Frequently asked
Why do e-invoices use PDF/A-3?
PDF/A-3 is the first PDF/A part that allows a file of any format to be embedded in an archival PDF. That lets one document be both a human-readable invoice and a machine-readable XML record, with no chance of the two drifting apart in separate files.
Is ZUGFeRD the same as Factur-X?
They are the same specification published under two names, ZUGFeRD in Germany and Factur-X in France, and they are technically interchangeable at equivalent versions. Both embed a CII XML document in a PDF/A-3 container.
How is XRechnung different?
XRechnung is a pure XML format, not a hybrid PDF. It is the German public-sector standard and defines a national specialisation (CIUS) of the EN 16931 semantic model. A ZUGFeRD file at the XRechnung profile carries XRechnung-compliant XML inside a PDF/A-3 container.
Can gopdfrab produce or validate a ZUGFeRD invoice?
No. That requires PDF/A-3, which gopdfrab does not implement yet. It is also not an XML validator, and a valid e-invoice needs its XML checked against EN 16931 as well as its container checked against PDF/A-3.