Archiving Invoices as PDF/A: What the Format Forbids, and Why Your Pipeline Should Care

A client in Germany asked me last year whether the invoices I send will "still open in ten years." It was not small talk. German bookkeeping rules expect business documents to stay readable and unaltered for a decade, and "it's a PDF" is not the same as "it's an archival PDF." The format designed for that promise is PDF/A — and the first time you convert real-world invoices to it, several of them fail, for reasons that teach you a lot about what an ordinary PDF quietly depends on.

What PDF/A actually is

PDF/A is a restricted profile of PDF (ISO 19005). The restriction is the point: an archival file must be completely self-contained, because anything it references externally — a font on someone's machine, a color profile on a server, content fetched at view time — is a thing that can be gone in ten years. So PDF/A requires all fonts embedded, device-independent color, no encryption, no JavaScript, no audio/video, no external references. If a file validates as PDF/A, any conforming reader, decades from now, should render it the way it looks today.

The levels matter when you choose a target. PDF/A-1 is the oldest and strictest (and has no support for transparency or layers). A-2 allows those and is the common default for business documents. A-3 goes one step further and permits embedded files inside the PDF — which is how the ZUGFeRD/Factur-X e-invoicing formats carry their machine-readable XML inside a human-readable invoice. If a client says "we need PDF/A," the follow-up question is always "which level," and for e-invoicing in the EU the answer is usually A-3 for a reason that has nothing to do with archiving.

Why real invoices fail conversion

In my experience, in order of frequency:

1. Unembedded fonts. The invoice template uses a font the generator references but does not embed. It renders fine on the machine that made it and substitutes silently everywhere else. This alone fails most first attempts.
2. Encryption or permissions flags left on by an earlier tool in the chain — PDF/A forbids encryption outright, including the "you may view but not copy" kind.
3. Device-dependent color (plain RGB with no output intent) — the converter usually fixes this by embedding a standard profile, but only if you let it.
4. Transparency and blend modes in logos and stamps, which fail A-1 and pass A-2. Choosing the level is choosing how much of your existing artwork survives.

The pipeline habit

Conversion belongs in the pipeline, not in someone's Friday afternoon. When an invoice is issued, the same job that produces the PDF should produce the archival copy and validate it — conversion without validation is a hope, not a control. I run invoices through a PDF-to-PDF/A converter for one-offs; in an automated pipeline the equivalent step is whatever converter you host, followed by a validator (veraPDF is the reference open-source one) whose report gets stored with the file. The validation report is the artifact your future self, or an auditor, actually wants.

Two operational notes. Keep the original alongside the archival copy: conversion can alter appearance subtly — color conversion is the usual suspect — and the pair costs little storage. And convert at issue time, not in a bulk job years later, because the fonts and templates that make conversion easy are the ones you still have today.

"Will it open in ten years" turns out to be an engineering question with a testable answer. PDF/A is how you get to say yes and show the report.