Compliance you can hand to an auditor

SpecSpec: ISO 19005-4 (PDF/A-4)ISO 19005-4 (PDF/A-4)SpecSpec: ISO 32000-2ISO 32000-2SpecSpec: ETSI EN 319 142-1ETSI EN 319 142-1SpecSpec: EN 16931-1EN 16931-1

At a glance

An auditor does not want to hear that a document is compliant. They want to be handed two things: the document, and the result of a check that says so. This page is about producing both with NextPDF — conformant output, and a validation result you can put in front of the person asking.

The open-source core produces archival PDF/A output and PAdES baseline signatures, and it validates conformance — PDF/A, PDF/UA, and signatures. The advanced editions extend the reach into long-term validation and e-invoicing. Throughout, one rule holds: conformance is a checker’s verdict, not a promise the producer gets to make.

Why this matters

Compliance work has a tell. Someone says “yes, it is conformant,” and then the room goes quiet, because nobody can produce the thing that proves it. The document looks right. The library is reputable. None of that is evidence.

The cost of that gap is asymmetric. A file that merely appears conformant passes review today and fails an external check months later — at a tax authority, in a long-term archive, or in court — when the original context is gone and the failure is expensive to explain. The standards anticipated this exactly. A PDF/A file records its target profile in its metadata, but that identification states the producer’s intent; the determination of conformance is made by a validation process outside the producing software (SpecSpec: ISO 19005-4 (PDF/A-4), §6.7.3ISO 19005-4 (PDF/A-4) §6.7.3). The format itself tells you the producer does not get the last word.

The short version

• You can produce conformant output AND a result that says it conforms. Not a claim — an artifact plus a check.
• The core covers the common cases. It produces PDF/A archival output and PAdES B-B / B-T signatures, and it validates conformance for PDF/A, PDF/UA, and signatures.
• Conformance is a validator’s verdict, scoped to a standard, clause, and level. NextPDF states the profile and the level it targets, never an unqualified “compliant” (SpecSpec: ETSI EN 319 142-1, §6.1ETSI EN 319 142-1 §6.1).
• The advanced editions extend the reach. Long-term validation (PAdES B-LT / B-LTA) and e-invoicing (ZUGFeRD / Factur-X against EN 16931) are commercial-tier capabilities.
• The engine refuses to fake a verdict. It produces a candidate and runs the check; it never stamps a file conformant on its own authority.

How NextPDF approaches it

The approach is one clean separation, applied everywhere: producing the artifact a standard defines is a capability; deciding the artifact conforms is a verdict. NextPDF gives you the first and lets you obtain the second from a checker. It never conflates them.

That separation is what makes the output handable. A signature is the clearest case. Its value is computed over a declared byte range that deliberately excludes the signature itself (SpecSpec: ISO 32000-2, §12.8ISO 32000-2 §12.8), which is precisely why validity is something a third party can recompute from the file rather than take on faith. The producer’s job is to write that structure correctly. The validator’s job is to confirm it. Two jobs, two parties, and the second one is the one an auditor trusts.

So the workflow you hand over has four moves, and the third is the one that turns “should conform” into “does.”

1. Produce a candidateGenerate PDF/A archival output or a PAdES signature with the conformance-relevant structure in place — embedded fonts, declared profile, a signature over a correct byte range.
2. Refuse the impossibleThe engine rejects conformance-breaking combinations (an encrypted PDF/A, a signature level it cannot honor) rather than emitting a file that silently does not conform.
3. Validate independentlyRun a conformance checker — PDF/A, PDF/UA, signature. A passing report is the evidence; the producing library is not.
4. Hand over bothGive the auditor the document and the validation result together. The verdict travels with the artifact.

From obligation to evidence: NextPDF produces a conforming candidate and refuses conformance-breaking operations, an independent validator delivers the verdict, and that report — not the producing library — is what you hand to the auditor.

The middle step is not decoration. When the archival mode is on and an incompatible operation is attempted — turning on encryption, for instance — the engine raises a typed error instead of degrading the file into a non-conforming “archival” document. Refusing loudly is what keeps the candidate honest enough to pass the check that follows.

And the check is graduated, never a single bit. PAdES is leveled by design: B-B, B-T, B-LT, and B-LTA each add to the one before (SpecSpec: ETSI EN 319 142-1, §6.1ETSI EN 319 142-1 §6.1). A B-T signature carries a trusted timestamp that B-B does not. A claim that names the level is an honest claim; a bare “signed” is not. NextPDF makes you name the level, so the result you hand over says exactly what was achieved.

Human-factors note:Human-factors note

The most useful sentence in any compliance conversation is “here is the validator output.” It moves the discussion from trust to evidence. NextPDF is designed so you always have that sentence available: it produces the candidate, refuses to break it, and leaves the verdict to a checker whose result you can attach. That is what makes the output worth handing over.

Practical example

A short, complete shape. It produces a candidate, validates it, and treats the validator’s answer as the evidence — never the producing call.

<?php

declare(strict_types=1);

use NextPDF\Contracts\PdfDocumentInterface;
use NextPDF\Conformance\ConformanceValidator;
use NextPDF\Conformance\ConformanceTarget;
use NextPDF\Conformance\ValidationReport;

/**
 * Produce a candidate, then prove it with an independent check.
 *
 * The producing call returns bytes that SHOULD conform. Only the
 * validator's report turns "should" into something an auditor accepts.
 *
 * @param PdfDocumentInterface $candidate A document composed for archival
 *                                        (fonts embedded, profile declared)
 */
function archivalEvidence(
    PdfDocumentInterface $candidate,
    ConformanceValidator $validator,
): ValidationReport {
    // 1. The producing call states intent; it does not certify.
    $bytes = $candidate->getPdfData();

    // 2. The check is the verdict. Conformance is decided here, by the
    //    validator, against the named target — not by the line above.
    $report = $validator->validate($bytes, ConformanceTarget::PdfA);

    // 3. Hand BOTH over: the bytes plus the report. The report names the
    //    target, the level, and every requirement that was checked.
    return $report;
}

The variable is named $candidate on purpose, and the report is the return value on purpose. The document is what you produced; the report is what proves it. An auditor asked you to demonstrate conformance — so you give them the demonstration, not the producer’s word for it.

Common misconception

The misconception that fills archives with unpreserved files and inboxes with rejected invoices is simple: “the library says PDF/A, so the file is PDF/A.” It is not the library’s verdict to give. A producer can emit a file intending to conform and still miss a normative requirement; only a validation process turns intent into a determination. Treating the producing call as proof is the core error, and it is exactly the error an auditor is trained to catch.

A second, subtler trap is hearing “NextPDF is standards-compliant” as one total guarantee. There is no such thing. Conformance is per standard, per clause, and per level. The right claim names which profile, which level, and shows the check.

Limits and boundaries

• NextPDF produces a conforming candidate and validates it; it does not certify conformance. The validator’s report is the evidence. The producing library never issues its own certificate.
• Validation is a checker result, not an absolute guarantee. A clean run means the file met the requirements the validator checked, against the edition of the standard it implements. It is the strongest evidence available, not a metaphysical proof.
• The core’s reach is PDF/A archival output and PAdES B-B / B-T signatures, plus conformance validation for PDF/A, PDF/UA, and signatures. It does not silently provide the advanced-edition capabilities.
• Long-term validation (B-LT / B-LTA) and e-invoicing (ZUGFeRD / Factur-X against EN 16931) are advanced-edition capabilities. EN 16931-1 defines the semantic invoice model the payload is validated against (SpecSpec: EN 16931-1, ScopeEN 16931-1 Scope); honoring it is commercial tier, not core.
• Legal effect is a separate question from technical conformance. Whether a signature is legally sufficient in a jurisdiction is decided by law and the receiving authority, not by a validator. NextPDF speaks to the technical result; your compliance team speaks to its legal weight.

Conformance reach across editions — edition availability

Edition	Availability
Core	○ Produces PDF/A archival output and PAdES B-B / B-T signatures, and validates conformance for PDF/A, PDF/UA, and signatures. The output and the validation result are both available to hand over.
Pro	○ Adds long-term validation — PAdES B-LT / B-LTA — embedding the revocation evidence and document timestamps that keep a signature verifiable after the certificate expires.
Enterprise	○ Adds e-invoicing (ZUGFeRD / Factur-X against EN 16931) and a structural conformance policy and report — still a structure check, with the final determination belonging to a validator and your compliance team.

The deeper compliance tooling, and the cited conformance boundary for every advanced-edition capability, live on the compliance and conformance page. When you need to run the check, the PDF/A and PDF/UA validation troubleshooting guide walks through reading and fixing a failing report.

Related docs

• Archival and PDF/A — what PDF/A guarantees, and why proving conformance is a separate job from producing it.
• Validating a signature properly — the full set of checks behind “the signature is valid.”
• The standards landscape — the map of standards bodies and how a clause becomes tested behavior.
• PAdES baseline profiles — B-B, B-T, B-LT, and B-LTA as a progression, and how to pick the level your obligation needs.
• Invoices and e-invoicing — the hybrid PDF / structured-data invoice against EN 16931, end to end.

Glossary

• Conformance — agreement of a file with a standard’s normative requirements, as decided by a validation process, scoped to a specific standard, clause, and level.
• Candidate — a file produced intending to conform, before an independent validator has confirmed that it does.
• Validator / conformance checker — independent software that judges a file against a standard’s requirements and produces the result that an auditor relies on.
• PDF/A — the ISO 19005 family: a constrained PDF profile for long-term preservation, designed to reproduce a document’s static appearance over time.
• PDF/UA — the ISO 14289 family: the accessibility profile that defines how a tagged PDF conveys structure to assistive technology.
• PAdES — PDF Advanced Electronic Signatures, the ETSI EN 319 142 family of signature profiles (B-B, B-T, B-LT, B-LTA) that ISO 32000-2 references for PDF signing.
• EN 16931 — the European standard defining the semantic data model of a core electronic invoice, the obligation a hybrid e-invoice payload is checked against.