PDF/A is an ISO-standardised subset of PDF (ISO 19005) meant for long-term archiving: a file should look the same in ten years as it does today, whichever program opens it. PDF/A-3 — part three, ISO 19005-3 — adds a single capability, and that one capability is what makes hybrid invoices possible at all.
What PDF/A requires
The standard strips out of PDF everything that makes a document depend on its surroundings:
- Fonts must be embedded. A file may not rely on the font being present on the reader’s machine — otherwise the line breaks change and amounts move.
- Colours must be self-describing, through an embedded colour profile rather than a setting on the display device.
- No external dependencies: no JavaScript, no encryption, no references to files that live elsewhere.
- Metadata in XMP, machine-readable and inside the document itself.
For an invoice this is more than formalism: German retention is eight years, and a document whose appearance depends on an installed font is no longer a reliable record after eight years.
Why part three specifically
PDF/A-1 and PDF/A-2 do not allow arbitrary attachments — PDF/A-2 admits only other PDF/A files. Only PDF/A-3 permits embedding any file in the PDF and marking it as an equal part of the document.
The hybrid format stands or falls on that. A ZUGFeRD or Factur-X file is a PDF/A-3 with exactly one special attachment: an XML file, usually factur-x.xml, carrying the same invoice in CII structure. The human sees the page, the software reads the attachment — and the two stay together through forwarding, filing and archiving, because they are one file.
Conformance levels A, B and U
Within PDF/A-3 there are three levels that demand different amounts:
| Level | What it additionally requires |
|---|---|
| B (Basic) | appearance is preserved — the document always looks the same |
| U (Unicode) | additionally: text can be reliably extracted as Unicode |
| A (Accessible) | additionally: structure tagging for accessibility and reading order |
For e-invoices PDF/A-3B is the usual and sufficient level — the machine-readable data sits in the XML attachment anyway, not in the text of the page. E-Rechnung Pro produces files at that level.
An attachment alone is not enough
This is where hand-built files most often fail — and it is invisible as long as you only look at the PDF. The specification requires the attachment to be declared, in two places:
AFRelationshipon the embedded object. For the invoice XML this isData— it tells the recipient that the attachment is the data belonging to the document, not some extra.- XMP metadata in the PDF naming the format, version and profile.
A PDF that has “an XML attached” is not yet an e-invoice. Without the declaration the recipient’s software will not find the attachment at all — or will find it and not know what it means. The file opens perfectly, the page is readable, and it still fails validation. That is the most common surprise with a first self-generated file.
Namespaces in the embedded XML
Opening the XML for the first time, you trip over long URIs at the top of the document. Those are namespaces: they say which vocabulary an element comes from, and stop identically named elements from different standards getting mixed up.
In a ZUGFeRD file two are chiefly in play:
urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100— the invoice’s root vocabulary;urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100— the reusable building blocks inside it.
This matters in practice to anyone writing their own parser: mixed namespace versions are a common reason a file from another system suddenly cannot be read. Anyone using an existing library need not think about it — the library manages namespaces itself, and editing them by hand is almost always a mistake.
What goes wrong during generation
| Validation finding | Cause |
|---|---|
| Font not embedded | the generator’s default font, treated as “present anyway” |
| Colour profile missing | output in RGB with no embedded profile |
| Transparency or layers | a logo in the PDF rendered with transparency |
| Attachment without a relationship | AFRelationship not set |
| XMP metadata missing or mismatched | the PDF was post-processed with another tool |
The last row is the most treacherous: a valid file that then passes through a tool which does not know PDF/A — for merging, stamping or compressing — comes out as an ordinary PDF. The attachment may still be inside; the declaration is gone.
Archiving: why one file beats two
What has to be kept is the structured part, unaltered and traceable — in Germany for eight years. This is exactly where the hybrid format pays off: there is no structured part that could get separated and lost. Filing a PDF and an XML as two files means guaranteeing their belonging together yourself — through file names, through an archive system, through discipline. A PDF/A-3 carries both inside itself.
Readability comes on top: in eight years any common reader will still display the PDF. Whether your current accounting software still exists is another question — the page stays readable.
Frequently asked questions
Is every PDF/A-3 an e-invoice?
No. PDF/A-3 is the envelope. The file becomes an e-invoice only through the embedded EN 16931 XML and its correct declaration.
Can I turn an existing PDF into PDF/A-3 afterwards?
Technically yes, and that is exactly what converters do. Whether it succeeds depends on the source PDF: if fonts are not embedded or transparency is present, the document has to be adjusted. The route in detail is in Convert a PDF invoice.
Which conformance level do I need?
B is enough for e-invoices. A becomes interesting if you have to meet accessibility requirements anyway — for that the PDF needs full structure tagging, and that does not happen by itself.
How do I see whether my PDF really is PDF/A-3?
Most reliably through validation — the container layer checks precisely that. The reader does not show it dependably: it will happily display a document that misses the standard.
May I attach further files?
PDF/A-3 allows it. On an invoice, think twice: every extra attachment is something the recipient has to interpret, and the invoice XML must stay unambiguously identifiable.
Is PDF/A-3 recognised everywhere?
As an archiving format, yes — it is an ISO standard. But whether a recipient accepts your invoice depends on the profile and the completeness of the data inside, not on the container.
In short
- PDF/A secures readability over years: embedded fonts, own colour profiles, no external dependencies.
- Part 3 allows arbitrary attachments — without it there would be no hybrid invoice.
- Level B is enough; U and A demand more without being necessary for an invoice.
- The attachment must be declared —
AFRelationship: Dataplus XMP. Without that it is a PDF with a file in it, not an e-invoice. - Post-processing destroys conformance. Stamping, merging and compressing after generation is the quiet killer.
- One file instead of two is the real gain for the eight-year retention.
Want to check whether your file passes the container layer? Upload it without signing up — or create a free account and produce invoices as valid PDF/A-3 from the start.