PDF/A-3 vs PDF/A-1: which format do hybrid e-invoices need?

When people say “save the invoice as a PDF for archival,” they usually mean a regular PDF, or sometimes a PDF/A without being specific about which version. For everyday document storage that is fine. For e-invoicing, the version matters. EU law does not require PDF/A: an e-invoice is structured data. Hybrid formats such as Factur-X and ZUGFeRD carry that data inside a PDF/A-3 file, because PDF/A-3 allows embedded files; PDF/A-1 and plain PDF cannot carry it that way.

Here is why the distinction matters and what each version actually does.

What PDF/A is

PDF/A is an ISO standard for long-term archival of PDF documents. The “A” stands for Archive. A PDF/A file is a PDF that has been stripped of features that could cause it to render differently in the future: embedded JavaScript, encryption, external font references, and links to external content. The idea is that a PDF/A file opened in 2050 should look identical to the same file opened today, on any compliant viewer.

The ISO standard has three generations:

• PDF/A-1 (ISO 19005-1, published 2005): based on PDF 1.4. Allows embedded fonts and ICC colour profiles. Prohibits encryption, external content, and transparency.
• PDF/A-2 (ISO 19005-2, published 2011): based on PDF 1.7. Adds support for transparency, JPEG 2000 compression, and embedded PDF/A files within a PDF/A container.
• PDF/A-3 (ISO 19005-3, published 2012): based on PDF 1.7, same as PDF/A-2, with one critical addition: allows embedding of arbitrary file formats as attachments.

That last point is why PDF/A-3 exists, and why it is the only version that works for hybrid e-invoices such as Factur-X.

The critical difference: file attachments

PDF/A-1 does not allow embedded file attachments. If you try to attach an XML file to a PDF/A-1 document, the resulting file is no longer conformant PDF/A-1. A validator will flag it.

PDF/A-3 explicitly allows embedding any file type as an attachment, provided the attachment is described with the correct metadata (a relationship descriptor that says what role the attachment plays in the document). This is precisely the mechanism Factur-X and ZUGFeRD use: the CII XML invoice data is attached to the PDF as a file named factur-x.xml, with the relationship type set to Alternative (meaning the attachment contains the same data as the visual PDF, just in machine-readable form).

A Factur-X invoice is:

• PDF/A-3B as the outer container (the B suffix means basic conformance level, the minimum required)
• A rendered PDF invoice as the visual layer
• A CII XML file embedded as an attachment with the correct Factur-X metadata

Without PDF/A-3, you cannot embed the XML. Without the embedded XML, you do not have a Factur-X invoice. That matters only on the hybrid route: EU law does not require PDF/A, and a pure XML invoice such as UBL or CII meets the mandates in France, Germany and Belgium just as well.

What plain PDF and PDF/A-1 give you

A plain PDF is not guaranteed to render consistently over time. It may contain embedded JavaScript, external font references, or features tied to a specific PDF renderer version. For long-term archiving, that makes it a weak choice.

A PDF/A-1 document is archival-safe for visual content. It will render consistently. But PDF/A-1 does not allow embedded files, so it cannot carry the XML of a hybrid e-invoice such as Factur-X. If someone hands you a Factur-X invoice saved as PDF/A-1, either they are wrong about it being Factur-X, or the file is non-conformant and will fail validation.

What ISO 19005-3 requires in practice

The PDF/A-3 standard (ISO 19005-3) imposes the same constraints as PDF/A-2 on the visual document, and adds specific rules for attachments:

• Every embedded file must have a Desc metadata entry describing it.
• The AFRelationship key must be set on every attachment, identifying the relationship between the attachment and the document (values include Source, Data, Alternative, Supplement, and Unspecified).
• For Factur-X specifically, the attachment must use Alternative, signalling that the XML and the PDF carry the same information.
• The MIME type of the attachment must be declared.

If any of these conditions are not met, the file does not conform to PDF/A-3, and therefore does not conform to the Factur-X specification.

How to validate conformance

The standard validation tool for PDF/A is VeraPDF, an open-source validator maintained by the PDF Association and the Open Preservation Foundation. VeraPDF checks:

• Which PDF/A version and conformance level the file claims to be
• Whether the file actually meets that version’s requirements
• For PDF/A-3, whether embedded attachments are correctly described

Running a Factur-X invoice through VeraPDF will tell you whether it is genuinely PDF/A-3B conformant. A pass on PDF/A-3B is a strong signal that the archival layer is correct.

Our free Validator tool runs the equivalent checks on any file you upload. You get a plain-English report showing PDF/A conformance level, Factur-X profile detected, embedded XML validity against EN 16931, and any errors that would cause rejection by a compliant accounting system.

Why this matters for archiving

Belgian, French, and German tax law all require that the integrity and readability of archived invoices stay guaranteed throughout the retention period, but none of them prescribes PDF/A: an e-invoice is structured data. On the hybrid route, PDF/A-3 covers long-term readability and the XML attachment carries the structured data. The combination makes the document a sound archival invoice.

If you archive plain PDF invoices today, you may be creating a compliance gap that only becomes visible during an audit. Most tax authorities have a window of 7 to 10 years in which they can request original invoice documentation. “We stored it as a PDF” is not the same as “we stored it in a format that a court can verify has not been altered and will still be readable on any compliant viewer in 2035.”

PDF/A-3 closes the readability gap. An RFC 3161 timestamp closes the integrity gap. Together, they give you an archive you can defend.

SealDoc and PDF/A-3

SealDoc checks every document against PDF/A-3B with veraPDF before returning it, so you are not relying on a claim: you can confirm it independently with VeraPDF or our Validator tool. The embedded Factur-X XML is generated from the same source data as the visual PDF, so the two representations are always consistent.

If you are converting existing invoices to PDF/A-3, upload them to the Validator first. We will tell you what profile they are, whether they pass, and what is missing if they do not.