Picture this. A finance team has been archiving client statements and transaction records as PDF/A for the last six years. Every file carries the right metadata tag. Every employee believes the job is done the moment the file is saved. Then a regulator shows up for a routine review, runs a handful of those files through a validator, and half of them fail.
Nobody touched the files. Nobody changed the process. The files were simply never actually compliant, they only claimed to be. And that gap between "claims to be PDF/A" and "is actually PDF/A" is one of the most common and most expensive blind spots in document archiving today.
If you're dealing with rejected archives, failed audits, or you just want to get ahead of the problem before it becomes one, here's what's actually going wrong and how to build a process that holds up under scrutiny.
Why PDF/A compliance matters more than most teams realize
PDF/A isn't just "PDF, but archived." It's an ISO-standardized format built specifically so that a document opens and displays exactly the same way today, in ten years, and in fifty years, regardless of what software or fonts happen to be installed on the machine viewing it.
That matters a lot when regulation is involved. Laws like GDPR require organizations to keep personal data secure, unaltered, and retrievable on request. Financial regulations such as MiFID II require firms to retain client communications and transaction records for years in a format that can't be quietly altered. Get it wrong, and penalties can reach into the single-digit percentages of a company's total annual revenue, which for a large organization is not a small number.
So when a PDF/A archive turns out to be non-compliant, it's rarely treated as a technical hiccup. It's treated as a compliance failure, and the organization is the one expected to explain how it happened.
The most common reasons PDF/A files fail validation
Most PDF/A failures trace back to a short list of recurring issues. Here's where things usually go wrong.
Fonts that aren't fully embedded
This is, by a wide margin, the most frequent cause of failure. PDF/A requires every font used in a document to be fully embedded, so a viewer never has to rely on having that font installed locally. In practice, a lot of conversion tools embed a font subset rather than the complete font, and that partial embedding is often enough to fail a strict validation check. Research into real-world PDF/A files has repeatedly found that font issues account for the majority of non-conformance cases.
Color spaces that aren't device-independent
PDF/A requires color to be defined using device-independent ICC profiles so a document renders consistently no matter what monitor, printer, or software opens it. A surprisingly common mistake is a document built around a color space like plain sRGB without the required ICC profile attached, which technically breaks the standard even if the file looks fine on screen.
Metadata that doesn't match reality
Every PDF/A file needs XMP metadata declaring which part of the standard it conforms to (PDF/A-1, -2, or -3) and which conformance level it's claiming (like A, B, or U). If that metadata is missing, malformed, or simply inaccurate, the file fails before an auditor even gets to the content.
A messy incremental update history
An incremental update adds new data onto the end of an existing PDF rather than rewriting the whole file. It's a useful feature in ordinary PDFs, but PDF/A treats it carefully:
- •PDF/A-1 doesn't allow incremental updates at all. Any edit has to produce a full rewrite of the file.
- •PDF/A-2 and PDF/A-3 allow incremental updates, but the appended content has to be just as conformant as the original. Adding a revision with a non-embedded font, for example, breaks the whole file.
- •The version number in the file's header also needs to match the version declared inside the document's internal catalog. A mismatch here is an easy thing to miss and an easy way to fail validation.
Converting to PDF/A is not the same as validating it
This is the part that trips up the most organizations, and it's worth being blunt about it.
Conversion takes a file, whether it started as a Word doc, an HTML page, or a regular PDF, and turns it into a PDF/A file. As part of that process, the tool stamps the new file with metadata declaring it PDF/A compliant.
Validation is a completely separate step where a program actually checks whether the file lives up to that claim.
Here's the catch: the metadata added during conversion is a claim, not a guarantee. A file can say it's PDF/A-2b in its metadata and still fail an actual PDF/A-2b check. Conversion tools are generally optimized to produce output that looks right, not to prove that every rule in the specification has been satisfied.
Making this worse, a lot of free and open-source validators lean on heuristics rather than checking against the full specification line by line. They'll often report that a file is "probably" compliant, which sounds reassuring but isn't the same thing as a real pass. And a visual check, someone opening the file and confirming it looks correct, tells you nothing about whether the underlying structure meets the standard.
At minimum, every PDF/A file needs to:
- •Embed all fonts, images, and content directly, with nothing referenced externally
- •Avoid audio, video, JavaScript, and XFA forms entirely
- •Skip LZW compression, encryption, and password protection
- •Give every interactive form field a proper appearance dictionary
- •Store metadata using the XMP standard
Skip validation, and you're trusting that every one of these boxes got checked correctly, without ever actually confirming it.
Conformance levels aren't interchangeable
Another quiet source of failed audits is conformance-level mismatch, where a file claims a level of compliance it doesn't actually meet.
Two things worth understanding here:
The standards themselves are different from each other. PDF/A-1, PDF/A-2, and PDF/A-3 were published years apart and don't have identical rules. PDF/A-1, for instance, doesn't support transparency or layers and only offers conformance levels A and B. PDF/A-2 added support for transparency, layers, and even embedding other PDF/A files, along with a new level, U.
Conformance levels build on each other. Level U includes everything required for level B, and level A includes everything required for level U, plus more. Picking the right level isn't just a technical detail, it's a decision with real consequences for how usable your archive will be years down the line. A claims archive where documents need to remain searchable and text-extractable, for example, needs at least level U. Level B alone won't guarantee that.
Level U specifically is about text integrity. It ensures the underlying Unicode text in the document can be reliably extracted or searched later, which matters enormously for any archive that might need to be reviewed or searched years after filing.
What an audit-proof PDF/A pipeline actually looks like
A defensible archiving process generally follows this shape:
Normalize the source document → Convert to PDF/A → Validate independently → Archive the file
The "validate independently" step is the one most organizations skip, and it's the one that matters most. If the same tool that converts your file is also the one certifying that the conversion worked, you're really just checking the tool's output against its own understanding of the specification. Any systematic misinterpretation baked into that tool will pass every internal check and only surface when an outside auditor runs the file through a different, stricter validator.
A solid audit trail should include:
- •A record of who converted each file and when
- •The name and version of the tool used
- •An independent validation report confirming the claimed conformance level, ideally timestamped and stored alongside the document itself
Auditors generally expect to see generation and validation handled by separate tools, machine-readable validation reports kept as evidence, and genuine consistency between what a document claims and what it actually contains. Under regulations like GDPR and MiFID II, the responsibility for proving that integrity sits entirely with the organization holding the archive, not with the software vendor.
The bottom line
A PDF/A file that hasn't been independently validated is really just a file that hopes it's compliant. That might be fine for years, right up until a regulator asks to see the archive. Building validation into the pipeline as a separate, independent step is what turns a hopeful archive into a defensible one, and it's a far cheaper habit to build now than a fine to pay later.