What is PDF/A-3? The Format Behind Hybrid E-Invoices

Quick Facts

Based on: PDF 1.7 (ISO 32000-1)
Used for: ZUGFeRD and Factur-X hybrid invoices
Full name: PDF/A-3 (ISO 19005-3:2012)
XML syntax: UN/CEFACT CII (Cross Industry Invoice)
Key feature: Allows embedded files of any type
XML filename: factur-x.xml (ZUGFeRD 2.1+)
Common target: PDF/A-3b for e-invoicing
Conformance levels: A (accessible), U (unicode), B (basic)

Definition

What is PDF/A-3?

PDF/A-3 (ISO 19005-3:2012) is the third generation of the PDF/A long-term archival standard. Its defining feature compared to earlier versions: PDF/A-3 allows embedding files of any type as attachments within the PDF document. This capability is what makes hybrid e-invoicing formats like ZUGFeRD and Factur-X possible — a human-readable PDF invoice with machine-readable XML data embedded inside a single file.

PDF/A-3 preserves all the archival guarantees of previous PDF/A versions (visual fidelity, font embedding, no external dependencies) while adding the flexibility to include structured data alongside the visual document.

PDF/A Evolution: Why Version 3 Matters

The PDF/A standard evolved in three main generations:

Version ISO Standard Year Key Feature -----------------------------------------
PDF/A-1 ISO 19005-1 2005 Base archival format. No embedded files allowed. PDF/A-2 ISO 19005-2 2011 Adds JPEG2000, transparency, layers. Embedded files must themselves be PDF/A.
PDF/A-3 ISO 19005-3 2012 Allows embedded files of any type (XML, CSV, CAD, etc.). PDF/A-1 and PDF/A-2 were designed purely for long-term visual preservation. PDF/A-3's breakthrough was recognizing that archival documents often need to carry associated data — invoices need their XML, engineering drawings need their CAD files, contracts need their metadata.

Conformance Levels

Like its predecessors, PDF/A-3 defines three conformance levels:

Level B (Basic): Ensures the visual appearance of the document is preserved. This is the minimum level used by most e-invoicing implementations.

Level U (Unicode): Level B plus the requirement that all text is mapped to Unicode, making it searchable and extractable.

Level A (Accessible): Level U plus full structural tagging for accessibility (tagged PDF).

Most ZUGFeRD/Factur-X implementations target PDF/A-3b (basic conformance), though PDF/A-3u is increasingly recommended for searchability.

How Hybrid Invoices Use PDF/A-3

A ZUGFeRD or Factur-X hybrid invoice is a PDF/A-3 file with a structured XML invoice embedded as an attachment. The result is a single file that serves two audiences:

Humans see a normal, formatted PDF invoice they can view, print, and archive

Machines extract the embedded XML for automated processing, booking, and validation

This "dual representation" approach solves a real problem in the transition to e-invoicing: businesses that have automated invoice processing can use the XML, while those that still rely on manual workflows can use the PDF. One file, zero friction.

Technical Embedding

The XML is embedded at the document level (not page level) using PDF's file attachment mechanism. Two structural elements are required:

1. EmbeddedFiles — Registers the XML as a standard PDF attachment, visible in any PDF viewer's attachment panel.
2. AF (Associated Files) array — A PDF/A-3-specific mechanism that formally associates the embedded file with the document and declares the relationship type.

AFRelationship

The AFRelationship key specifies how the embedded XML relates to the PDF:

Alternative — The XML is an equivalent representation of the same invoice (used in ZUGFeRD 1.0 and 2.0).

Source — The XML is the source data from which the PDF was generated (used in Factur-X/ZUGFeRD 2.1+ for non-German contexts).

Supplement — The XML provides additional information not present in the PDF.

Data — A generic data relationship.

The relationship type signals to processing software whether the XML and PDF should be treated as interchangeable (Alternative) or whether one is derived from the other (Source).

File Naming Conventions

The embedded XML filename varies by standard version: Standard XML Filename
----------------------- ZUGFeRD 1.0 ZUGFeRD-invoice.xml
ZUGFeRD 2.0 zugferd-invoice.xml ZUGFeRD 2.1+ / Factur-X factur-x.xml
XRechnung (via ZUGFeRD) xrechnung.xml Processing software identifies the embedded invoice data by looking for these specific filenames in the PDF's attachment list.

XMP Metadata

PDF/A-3 hybrid invoices must include specific XMP metadata properties in the document's metadata stream:

DocumentType — Always "INVOICE"

DocumentFileName — The embedded XML filename (e.g., "factur-x.xml")

Version — The XML schema version (e.g., "1.0")

ConformanceLevel — The Factur-X/ZUGFeRD profile (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED)

These metadata fields are defined in a custom XMP extension schema and are required for ZUGFeRD/Factur-X conformance validation.

ZUGFeRD and Factur-X Profiles

The XML embedded in a PDF/A-3 hybrid invoice follows the UN/CEFACT CII (Cross Industry Invoice) syntax. Different profiles control how much data the XML contains: Profile Data Completeness Use Case ------------------------------------- MINIMUM Reference number + totals only Archive reference BASIC WL Header + totals, no line items Simple invoices BASIC Full invoice including line items Standard B2B EN 16931 Full EN 16931 compliance EU e-invoicing (CIUS) EXTENDED Beyond EN 16931 (additional fields) Complex invoices |

For EU e-invoicing compliance, the EN 16931 profile is the target. It makes the XML a proper CIUS of the European standard, suitable for cross-border trade and DRR reporting.

Creating PDF/A-3 Hybrid Invoices

Generating a valid PDF/A-3 hybrid invoice requires:

1. PDF/A-3b (minimum) conformance — All fonts embedded, no external references, no JavaScript, no encryption, correct color profiles.
2. Document-level XML attachment — The CII XML file attached using both EmbeddedFiles and AF mechanisms.
3. Correct AFRelationship — Set to Alternative or Source depending on the ZUGFeRD/Factur-X version.
4. XMP metadata — Custom extension schema with DocumentType, DocumentFileName, Version, and ConformanceLevel.
5. Valid CII XML — The embedded XML must pass Schematron validation against the selected profile's rules.

Libraries commonly used for PDF/A-3 generation include PDFlib, iText, Apache PDFBox, and various open-source ZUGFeRD libraries (Mustangproject for Java, Factur-X for Python).

Why ERP Developers Need to Know This

1. Germany's B2B e-invoicing transition. Germany requires all businesses to receive e-invoices since January 2025. ZUGFeRD (PDF/A-3 + CII XML) is one of the three accepted formats alongside XRechnung and pure CII. Many German SMEs prefer ZUGFeRD because it maintains the familiar PDF workflow.

2. France's e-invoicing mandate. Factur-X is one of the three formats accepted by France's PPF system (alongside UBL and CII). The EN 16931 profile of Factur-X is the practical choice for French B2B invoicing.

3. Backward compatibility. PDF/A-3 hybrid invoices work even when the receiver has no e-invoicing capability — they just see a normal PDF. This makes ZUGFeRD/Factur-X ideal for the transition period where some customers are ready for automated processing and others are not.

4. Archival compliance. PDF/A-3 satisfies the EU's 10-year archival requirements for invoices out of the box. The format is self-contained and guaranteed to render identically for decades.

5. Validation complexity. You need to validate both layers: the PDF must conform to PDF/A-3 (veraPDF is the reference validator), and the embedded XML must pass Schematron validation against the relevant profile.

Relation to Invoice Navigator

Invoice Navigator validates the XML data embedded within ZUGFeRD and Factur-X PDF/A-3 invoices. The engine extracts the CII XML from the PDF attachment, determines the applicable profile from the XMP metadata, and runs the corresponding Schematron rules — catching errors in the machine-readable layer that would be invisible in the visual PDF.

XML Examples

UBL (Peppol, XRechnung)

<!-- PDF/A-3 is used with CII syntax, not UBL.
     UBL invoices (Peppol, XRechnung) are standalone XML files
     and do not use the PDF/A-3 container format.
     
     For reference, this is the UBL equivalent of a ZUGFeRD field:
     The PDF/A-3 embedded XML uses CII, not this UBL syntax. -->
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>

CII (ZUGFeRD, Factur-X)

<!-- CII XML embedded inside a PDF/A-3 container (Factur-X/ZUGFeRD) -->
<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <!-- EN 16931 profile = CIUS-compliant -->
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>INV-2026-0042</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260326</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <!-- This XML is saved as factur-x.xml and embedded
       in the PDF/A-3 container with AFRelationship=Source -->
</rsm:CrossIndustryInvoice>