← Back to all articles

PDF/A-3 vs PDF/A-1: which archival format does EU e-invoicing require?

SealDoc Team · · 5 min read

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 EU e-invoicing compliance, it is not. The mandates require PDF/A-3B specifically, and using PDF/A-1 or plain PDF means your archive is legally incomplete even if the numbers on the page are correct.

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 e-invoicing.

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. Without a Factur-X invoice, you do not meet the e-invoicing mandate in France, Germany, Belgium, or any other country that has adopted the hybrid format.

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 archival purposes, it is not an acceptable format under most European tax laws.

A PDF/A-1 document is archival-safe for visual content. It will render consistently. But it cannot legally contain the embedded XML that e-invoicing compliance requires. 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.

Belgian, French, and German tax law all require that archived invoices are preserved in a format that guarantees integrity and long-term readability. PDF/A-3 satisfies the readability requirement. The XML attachment satisfies the structured-data requirement. The combination is what makes the document legally sufficient as an 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

Every document SealDoc produces is PDF/A-3B conformant. We validate the output internally 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.

← Back to all articles