PDF/A is the archival flavour of PDF — a guarantee that a document will render the same way in 2050 as it does in 2026. There are four major profiles (PDF/A-1, 2, 3, 4) with sub-conformance levels each. Of these, PDF/A-3 is the one that quietly powers EU e-invoicing, and the only profile in widespread use that allows arbitrary file attachments inside the archival wrapper.

If you’re touching invoices, regulatory filings, or any “PDF + structured data” workflow, PDF/A-3 is the spec you’ll meet. Here’s what it is, how it differs from its siblings, and how to verify a file is actually compliant.

The PDF/A family in one paragraph

Profile	ISO part	Year	Defining feature
PDF/A-1	19005-1	2005	First archival profile. No transparency, no JavaScript, fonts embedded.
PDF/A-2	19005-2	2011	Adds JPEG2000 + transparency + layer support. Better print fidelity.
PDF/A-3	19005-3	2012	Adds embedded file attachments. The wrapper for Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Modern revision; cleaner conformance model, no `b` vs `a` split.

Each profile has sub-levels:

b (basic): visual fidelity is preserved. Anyone can read it; no semantic-content guarantees.
a (accessible): structure tagging + Unicode mapping. Screen readers can extract the text in the correct order.
u (Unicode): Unicode mapping but not full structure. Middle ground.
e / f (PDF/A-4 only): adds engineering 3D content and full forms.

So “PDF/A-3b” means: archival profile 3 (allows attachments), basic level (no accessibility tagging required). That’s the most common variant in invoicing.

What’s special about PDF/A-3

PDF/A-1 and PDF/A-2 forbid arbitrary embedded files. The reasoning: an archival PDF should be self-contained; an embedded data.xlsx could rot independently of the PDF, breaking the archival guarantee.

PDF/A-3 explicitly relaxes that rule under a tightly-scoped condition: every embedded file must be declared with an AFRelationship attribute that says how the file relates to the visible PDF content. Valid values are Source, Data, Alternative, Supplement, Unspecified. The PDF declaration also has to list the attachment in the /AF array and emit XMP metadata describing the attached file.

In other words: PDF/A-3 says “you can attach things, but only if you declare exactly what they are and how they relate to what the human sees”. That declaration is what made PDF/A-3 the vehicle for e-invoicing — the human-readable invoice goes in the PDF, the machine-readable EN 16931 CII XML goes in the attachment, and the AFRelationship="Alternative" declares that the two are alternative representations of the same invoice.

Where PDF/A-3 lives in production

Factur-X (France, mandatory B2B 2026 onwards): PDF/A-3 + CII XML, with the urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# XMP namespace.
ZUGFeRD 2.x (Germany, mandatory receipt 2025): PDF/A-3 + CII XML, with the urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0# XMP namespace.
Engineering CAD archival: PDF/A-3 with an attached native CAD file. The PDF is the rendering; the CAD is the source.
Regulatory submissions: PDF/A-3 with attached XML payloads (FDA submissions, ESEF financial reports for EU-listed issuers).

In all of these, the wrapper isn’t just a container — it’s a contract that says “this PDF and this attached file are the same document, and both must validate”.

How to verify a file is PDF/A-3 compliant

The official conformance checker is veraPDF (verapdf.org), maintained by the PDF Association. It implements the ISO 19005-3 rule set; if veraPDF reports “Pass — PDF/A-3b”, that’s the strongest signal a single engine can give.

But single-engine “Pass” is not the audit-grade standard (Why two PDF/A validators are better than one covers the reasoning). The audit-grade pattern is to run two independent engines and treat the file as compliant only when both pass.

For an e-invoice file specifically, there’s a second engine you also need: Mustang (mustangproject.org) — the de-facto Factur-X / ZUGFeRD checker that validates the embedded CII XML against EN 16931 Schematron. PDF/A-3 conformance alone isn’t enough; the attached XML must also be valid EN 16931 or the AP system on the receiving end will reject the invoice.

Most teams install Java, set up the veraPDF CLI, install Mustang, write a shell script that pipes outputs together. It works but it’s friction.

validator runs all three in the browser:

veraPDF: official reference, PDF/A-3 conformance.
gPdf’s Rust+WASM edge engine: independent re-implementation, second-opinion confirmation.
Mustang: EN 16931 CII XML Schematron, for embedded e-invoice payloads.

Drop the file, all three run in parallel, reports come back side-by-side. JSON downloadable for QA evidence. No login, no quota.

What to actually look for in a PDF/A-3 report

When you run the validator and one of the engines reports an error, the failures typically cluster in a few areas:

Embedded file metadata missing — /AF array not present, or the embedded file isn’t listed in it.
AFRelationship missing or wrong — should be Alternative for e-invoice; Source / Data is what most PDF libraries default to.
XMP namespace missing or wrong — Factur-X and ZUGFeRD have specific namespace URIs; a one-character typo fails the check.
Fonts not subsetted or not embedded — PDF/A requires all glyphs used in the document to be embedded with the font. Edge case: a font reference that’s declared but never actually used can still fail.
Output intent missing — PDF/A requires a colour intent (sRGB or another ICC profile) be declared even if the document is pure black-and-white text.
Document metadata incomplete — /Title, /Producer, /CreationDate must be present in the document info dictionary.

Each of these has a specific spec section the validator references in its report. You fix at the source (or, if you’re generating via gPdf, the API auto-handles all of them and the validator is your public receipt).

TL;DR

PDF/A-3 = PDF/A-2 + the ability to legally embed arbitrary files. That capability is what makes EU e-invoicing tractable: the human-readable invoice + the structured EN 16931 CII XML, in one archival wrapper. Compliance requires the wrapper to satisfy PDF/A-3 and the attached XML to satisfy EN 16931. Both must pass before you ship.

Generate via POST /api/v1/e-invoice/render. Verify at validator. Three engines (veraPDF + gPdf edge + Mustang), one upload, free.