← Back to all articles

What is PDF/A-3 and why it matters for e-invoicing

SealDoc Team · · 5 min read

If you have spent any time near European e-invoicing in the last two years, you have probably seen the term PDF/A-3 used as if everyone already knows what it means. Most articles assume the reader understands the difference between PDF, PDF/A, and PDF/A-3, then move on. The differences are not academic. They decide whether an invoice you send today will still be openable, verifiable, and legally valid in 2036.

Here is the version we wish someone had written for us.

PDF, PDF/A, PDF/A-3: three different things

A regular PDF is a presentation format. It can contain anything a designer wants: external font references, JavaScript, embedded video, links to remote resources. That flexibility is great for marketing brochures and terrible for archives. A PDF written in 2005 may already render differently in a 2025 viewer because a font got substituted, an external resource went 404, or a vendor extension was deprecated.

PDF/A (ISO 19005) is a strict subset of PDF designed to render identically forever. It bans the dynamic features. Every font has to be embedded. Every color profile has to be self-contained. No JavaScript, no external content, no encryption. The result is a file that is guaranteed to be openable and visually identical decades from now.

PDF/A-3 is the third revision of that standard, published in 2012. It changed exactly one thing: it lets you embed arbitrary attachments inside the PDF. Earlier versions (PDF/A-1, PDF/A-2) only allowed attachments that were themselves PDF/A-compliant. PDF/A-3 dropped that restriction. You can now embed an XML file, a CSV, a JSON document, or anything else as a structured attachment.

That single change is what made modern e-invoicing possible.

Why e-invoicing needed exactly this

A compliant European e-invoice has to be two things at once:

  1. Machine-readable. The buyer’s accounting system needs to ingest line items, tax rates, and payment terms without human intervention.
  2. Human-readable, for years. Tax law in most EU countries requires the invoice to be archived in a form a human auditor can open and read, for periods between 7 and 10 years.

A pure UBL XML file satisfies the first requirement but fails the second. A pure PDF satisfies the second but not the first. A PDF/A-3 with embedded UBL satisfies both, in a single tamper-evident container, and the visual layer is bit-identical to the structured layer.

This is the architecture behind both Factur-X (the French/German hybrid invoice standard) and ZUGFeRD (its German parent). Both are PDF/A-3 with a specific XML attachment in a specific location with a specific filename. Strip away the marketing names and what they really are is “PDF/A-3, plus a contract about what XML you put inside.”

What PDF/A-3 does not give you

PDF/A-3 is an archival format. It is not a compliance certificate, and it is not a signature. Three things it specifically does not do:

  • It does not validate the embedded XML. You can put a malformed UBL inside a PDF/A-3 and the file will still pass PDF/A-3 validation. The format only guarantees the container, not the cargo.
  • It does not prove when the file was created. A PDF/A-3 file can be re-saved, re-timestamped, and re-shipped without leaving any footprint. If you need to prove “this invoice existed on this date,” you need an RFC 3161 timestamp on top.
  • It does not guarantee delivery. Compliance with the format and compliance with a national mandate (Peppol, KSeF, Chorus Pro) are different problems. PDF/A-3 is necessary but not sufficient.

This is why the SealDoc pipeline emits a PDF/A-3 plus an RFC 3161 timestamp plus an evidence pack with manifest hashes. Each layer answers a different question, and a real audit will want all three.

Common ways pipelines get PDF/A-3 wrong

We see the same five mistakes across customer pipelines:

  1. Half-converted PDFs. A library claims it “outputs PDF/A-3” but skips font embedding for system fonts, which then resolve differently on the auditor’s machine.
  2. Wrong attachment relationship. PDF/A-3 distinguishes Source, Data, Alternative, Supplement, and Unspecified. Factur-X requires Alternative. Many embedders default to Unspecified and the file fails strict validation.
  3. Missing XMP metadata. PDF/A requires self-describing metadata in XMP. A file without the required pdfaid:part and pdfaid:conformance keys is not technically PDF/A-3, regardless of structure.
  4. Color profile drift. A PDF/A-3 has to declare every color space it uses. Pipelines that pass through arbitrary RGB images without an embedded profile silently produce non-conformant files.
  5. Re-rendering an existing PDF. Some pipelines rasterize the input PDF before re-embedding XML. This works visually but destroys the searchable text layer and breaks accessibility.

You can check any of the above with our public validator at /check. Drop a file in, get a verdict in seconds, no signup required. If a file fails, the report tells you exactly which clause of which spec was violated.

When PDF/A-3 is the right choice (and when it is not)

PDF/A-3 is the correct choice when you have to retain a human-readable copy of a structured document for years and you want both layers in one container. That covers e-invoicing, e-receipts, structured contracts, and increasingly e-tickets and customs documents.

It is the wrong choice for ephemeral documents (a delivery note that expires in a week), for documents where the structured payload is the only thing that matters (pure EDI), or where the human-readable layer is purely decorative and will never be audited.

For everyone else in EU B2B in 2026, PDF/A-3 is the format. The technical details above are the reason it works, and the reason the wrong implementation will quietly produce files that pass internal QA and fail at the auditor’s desk three years from now.

← Back to all articles