Glossary Term

Hybrid invoice

An invoice that bundles a human-readable PDF and a structured XML representation of the same data into a single file. The PDF is for people; the embedded XML is for software. ZUGFeRD and Factur-X are the two flagship hybrid formats; both use PDF/A-3 as the carrier.

Quick Facts

Carrier
PDF/A-3 (ISO 19005-3:2012)
Profiles
MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG
Validation
veraPDF (PDF/A-3) + EN 16931 Schematron
Latest release
ZUGFeRD 2.4 / Factur-X 1.0.8 (15 Jan 2026)
Standards body
FeRD (Germany) + FNFE-MPE (France)
Flagship formats
ZUGFeRD (DE), Factur-X (FR) — unified spec
Required metadata
AFRelationship (Source/Data/Alternative), XMP descriptor
Embedded XML schema
UN/CEFACT Cross Industry Invoice (CII)

Definition

What it is

A hybrid invoice is a single file that contains two synchronized representations of the same invoice: a PDF rendering that a person can open and read, and a structured XML payload — embedded as an attachment inside the PDF — that software can parse without OCR. Whoever receives the file gets to choose: a buyer with an automated AP system imports the XML; a buyer who is still in the print-and-staple era opens the PDF.

The model exists because Europe's transition from paper to fully structured e-invoicing is uneven. A hybrid format means the issuer doesn't have to ship two files (with the risk that they drift apart) and doesn't have to know the recipient's capabilities in advance. It also degrades gracefully: a recipient who upgrades their AP later can re-process old archived hybrid invoices and extract structured data they previously ignored.

The PDF/A-3 carrier

Hybrid invoicing is built on PDF/A-3 (ISO 19005-3:2012), the first PDF/A profile that allows arbitrary file attachments in an archival-grade PDF. Earlier PDF/A profiles (1, 2) explicitly forbade attachments because attachments could not themselves be guaranteed archivable; PDF/A-3 lifted this restriction on the condition that the relationship between the PDF and the attachment is declared in metadata. Concretely, the embedded XML must be referenced from the PDF's AFRelationship entry as Source, Data, or Alternative so a conforming reader knows the attachment is the structured equivalent of the visible content, not a separate document.

XMP metadata at the document level identifies which hybrid profile is in use — urn:zugferd:pdfa:CrossIndustryInvoice:2p3:basic, for example — so an automated system knows which schema to expect before it cracks the file open.

The two flagship formats

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) was published by FeRD in 2014. It uses UN/CEFACT Cross Industry Invoice (CII) as the embedded XML schema and ships in profiles of ascending completeness: MINIMUM, BASIC WL (without lines), BASIC, EN 16931 (formerly COMFORT), EXTENDED, and XRECHNUNG.

Factur-X is the French variant, jointly maintained by FNFE-MPE in France and FeRD in Germany. From version 2.1 / 1.0.05 (2019) onwards, ZUGFeRD and Factur-X are the same specification under two names: same CII schema, same PDF/A-3 carrier, same conformance levels. The latest joint release is ZUGFeRD 2.4 / Factur-X 1.0.8, scheduled for 15 January 2026, aligning with EN 16931:2024 amendments and the upcoming French B2B mandate of September 2026.

A few other hybrid attempts exist (PDF + UBL has been proposed by some Peppol AP vendors, and Italy's FatturaPA can technically wrap a PDF as an attachment), but in practice "hybrid invoice" in the EU means ZUGFeRD/Factur-X.

Why ERP vendors care

From an integration perspective, hybrid invoices are deceptively simple: produce the EN 16931 XML, render the PDF, embed the XML as an /EmbeddedFile with the right AFRelationship, set the XMP metadata, and you're done. The pitfalls live in the details:

  • Profile mismatch. Issuing under the EN 16931 profile but populating fields only present in EXTENDED produces a file that validates as EXTENDED but identifies as EN 16931. Receivers reject it.

  • PDF/A-3 conformance, not PDF/A-1. Most PDF libraries default to PDF/A-1 or no PDF/A at all. Reaching A-3 requires explicit configuration.

  • Visual–data divergence. The PDF total and the XML total must match exactly, including currency rounding. A common bug: the rendering pipeline rounds line subtotals before summing while the XML sums unrounded values.

  • Embedded fonts and color profiles. PDF/A-3 still requires fully embedded fonts and a declared output intent (typically sRGB).

  • Validation. A hybrid invoice has to pass both PDF/A-3 validation (veraPDF is the open-source reference) and EN 16931 schema + Schematron validation on the embedded XML.
  • Relation to other formats

    Hybrid is one of three EN 16931 syntaxes used in practice:

  • UBL 2.1 — Pure XML, used by Peppol BIS Billing 3.0, XRechnung's UBL profile, and most Nordic systems.

  • UN/CEFACT CII D16B — Pure XML, used by XRechnung's CII profile and by the embedded XML inside ZUGFeRD/Factur-X.

  • Hybrid (ZUGFeRD / Factur-X) — PDF/A-3 wrapping CII XML.
  • From September 2026, French recipients must accept all three; from January 2025, German B2B recipients have already been required to accept structured invoices in EN 16931-conformant form, with hybrid being the most common transitional choice.

    XML Examples

    CII (ZUGFeRD, Factur-X)

    <rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
                              xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">
      <rsm:ExchangedDocumentContext>
        <ram:GuidelineSpecifiedDocumentContextParameter>
          <ram:ID>urn:cen.eu:en16931:2017</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">20260507</udt:DateTimeString>
        </ram:IssueDateTime>
      </rsm:ExchangedDocument>
      <!-- ... SupplyChainTradeTransaction, etc. ... -->
    </rsm:CrossIndustryInvoice>

    Related Content