ZUGFeRD 2.5 / Factur-X 1.09

June 10, 2026 · View on GitHub

Source: docs/2.5/Documentation/0_FACTUR-X_1.09_2026_06_10_EN.pdf (Factur-X Specification 1.09, dated 2026-06-10; ZUGFeRD 2.5 == Factur-X 1.09).

Scope: requirements that apply to the PDF carrier file only. XML content rules (cardinalities, business rules outside BR-HYBRID-*, code lists for invoice data) are out of scope.

Carrier-side delta vs 2.4 is minimal. The substantive changes in 1.09 are XML-side — new EXTENDED business terms (BT-173 to BT-180, BT-193, BT-215, BT-216, BG-34, BG-X-94, …), Revised-EN16931-2026 anticipations, and BR-FXEXT-* business-rule churn. Section 6 (PDF/A-3, XMP extension schema, AFRelationship, embedding) is structurally identical to 2.4. The only PDF-carrier-level change is the attachment format list (XLS added). See §11 below for the complete list of editorial points worth noting.

1. Carrier format

  • The PDF envelope SHALL conform to PDF/A-3 (ISO 19005-3, based on ISO 32000-1:2008 = PDF 1.7). (Spec §3 Principle 1; §6 intro; BR-HYBRID-02.)
  • A PDF/A-4f file (ISO 19005-4, based on PDF 2.0 = ISO 32000-2:2020) is also allowed as an option. (Spec §3 Principle 1 footnote; BR-HYBRID-02.)
  • The PDF/A conformance level (3a / 3b / 3u for PDF/A-3) is irrelevant for Factur-X compliance. Level 3a is recommended for accessibility (blind / visually impaired). (§2.2, §6 intro, §6.1.)
  • The source PDF SHALL be PDF/A-3 compliant before the structured invoice data file is embedded. Embedding the XML must not break PDF/A-3 conformance. (§2.2, §6 intro.)
  • One PDF carries exactly one invoice. The PDF is the envelope and the legally relevant artefact (the original tax invoice). (§3 Principle 1.)
  • There is no naming convention for the PDF file itself. (§6 intro.)

PDF/A-3 derived constraints (recap from ISO 19005-3, §6.1)

  • All metadata SHALL be embedded as XMP. Custom properties require an embedded XMP extension schema definition.
  • All fonts used SHALL be embedded (full font or used-glyph subset).
  • No external file references. Embedding is only allowed via the PDF/A-3 associated-file mechanism.
  • No "active" content: no JavaScript actions, no Flash/animations, no multimedia.
  • Permitted embedded image formats: CCITT Group 3, CCITT Group 4, JBIG2, JPEG, JPEG2000.
  • No encryption, no DRM, no authorization controls.

2. Embedded structured invoice file

2.1 File name

  • The XML invoice file SHALL be named factur-x.xml. (§6.2.)
  • Exception: when the XRECHNUNG reference profile is used the file SHALL be named xrechnung.xml. (§6.2.)
  • BR-HYBRID-13 (Fatal): the embedded file name SHALL be one of the values defined in the HybridDocumentFilename code list (i.e. factur-x.xml or xrechnung.xml).
  • BR-HYBRID-14 (Warning): the embedded file name SHOULD match fx:DocumentFileName in XMP.

2.2 MIME type

  • The MIME type registered in the file-specification dictionary SHALL be text/xml. (§6.2.)

2.3 File specification dictionary / stream

  • The XML SHALL be embedded by means of a PDF file specification dictionary. (§6.2.)
  • The embedded file stream dictionary SHOULD contain a /Params dictionary that contains at least a /ModDate entry indicating the last modification date of the embedded file. (§6.2.)
  • The embedded document SHALL be reachable via the Names tree (/Names → /EmbeddedFiles) so PDF tools can list the attachment. (§6.2.) One or two /Kids intermediate levels between /EmbeddedFiles and the leaf entries are permitted, as produced by some PDF/A-3 tools (cf. PDF 1.7 §3.8.5). (§6.2.2 note; §6.4 note.)
  • The structured XML SHALL be registered as an Associated File at document level: the /AF array SHALL be on the document catalogue (Root), and SHALL reference the file specification dictionary of factur-x.xml / xrechnung.xml. (§6.2.1.)
  • BR-HYBRID-12 (Fatal): the embedding method SHALL conform to the current specification so the XML can be reliably extracted.

2.4 AFRelationship (Associated-File relationship)

  • The /AFRelationship key on the embedded file SHALL describe the semantic link between the XML and the visible PDF. (§6.2.2.)
  • BR-HYBRID-11 (Warning): the chosen value SHOULD follow the matrix below. (Identical to 2.4.)
ProfileFranceGermany
MINIMUMDataData
BASIC WLDataData
BASICAlternative, Source, DataAlternative
EN 16931Alternative, Source, DataAlternative
EXTENDEDAlternative, Source, DataAlternative
XRECHNUNGn/a (not used in France)Alternative

Semantics of the permitted values (from §6.2.2):

  • Data — XML carries data behind the PDF rendering (table/graph source). Used when the PDF visual representation contains more invoicing data than the XML (MINIMUM, BASIC WL).
  • Source — PDF was rendered from this XML; XML is the source of truth.
  • Alternative — both representations are equivalent alternatives of the same invoice content. Required for German use when XML carries all mandatory invoice fields (BASIC, EN 16931, EXTENDED, XRECHNUNG).
  • Supplement and Unspecified exist in PDF/A-3 but are not used for the Factur-X invoice itself.

3. PDF/A XMP extension schema (Factur-X 1.0)

The PDF/A-3 document SHALL carry an XMP extension schema that declares it as a Factur-X invoice and SHALL include the corresponding XMP metadata. (§2.2, §3 Principle 1, §6 intro, §6.3.1, BR-HYBRID-03.)

PropertyValue
Extension schema nameFactur-X PDFA Extension Schema
URI (namespace)urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#
Schema prefixfx

Notes (§6.3.1):

  • The trailing # in the URI is required.
  • The 1p0 in the URI is the extension schema version, not the Factur-X spec version. It stays at 1p0 and is independent of the spec version (currently 1.09).
  • The extension schema definition (PDF/A "extension schemas") describing these custom properties SHALL be embedded in the XMP packet, not merely referenced (§6.3 intro).
  • Inconsistency to be aware of: BR-HYBRID-04 (Fatal) states the URI SHALL be urn:factur-x:pdfa:CrossIndustryDocument:1p0# (i.e. without the :invoice segment). §6.3.1 and the worked example use the longer …:invoice:1p0# form. Treat §6.3.1 as authoritative for actual files pending erratum. (Unchanged from 2.3.2 / 2.3.3 / 2.4.)

XMP fields under the fx: namespace

FieldDescriptionExample
fx:DocumentTypeDocument type. SHALL be INVOICE (HybridDocumentType list).INVOICE
fx:DocumentFileNameFile name of the embedded invoice XML. SHALL match the /F key of its file specification dictionary. From HybridDocumentFilename list (factur-x.xml or xrechnung.xml).factur-x.xml
fx:VersionVersion of the XMP extension schema. From HybridDocumentVersion list. BR-HYBRID-10 (Warning): SHOULD be 1.0.1.0
fx:ConformanceLevelProfile of the structured XML. From HybridConformanceType list: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG. BR-HYBRID-15 (Warning): SHOULD match the profile of the embedded XML.EXTENDED

Hybrid business rules summary (unchanged vs 2.4):

  • BR-HYBRID-03 (Fatal): PDF/A extension schema (XMP) following the defined structure SHALL be used.
  • BR-HYBRID-04 (Fatal): the URI in the extension schema SHALL be the prescribed namespace.
  • BR-HYBRID-05 (Fatal): the schema prefix SHALL be fx.
  • BR-HYBRID-06 (Fatal): fx:DocumentType value SHALL come from the HybridDocumentType code list.
  • BR-HYBRID-07 (Fatal): fx:ConformanceLevel value SHALL come from the HybridConformanceType code list.
  • BR-HYBRID-08 (Fatal): fx:DocumentFileName value SHALL come from the HybridDocumentFilename code list.
  • BR-HYBRID-09 (Fatal): fx:Version value SHALL come from the HybridDocumentVersion code list.

Example XMP block (§6.3.1)

<rdf:Description rdf:about=""
    xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#">
  <fx:DocumentType>INVOICE</fx:DocumentType>
  <fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
  <fx:Version>1.0</fx:Version>
  <fx:ConformanceLevel>EXTENDED</fx:ConformanceLevel>
</rdf:Description>

Attribute-style form is also accepted:

<rdf:Description xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#"
    fx:ConformanceLevel="BASIC"
    fx:DocumentFileName="factur-x.xml"
    fx:DocumentType="INVOICE"
    fx:Version="1.0"
    rdf:about=""/>

Legacy: ZUGFeRD 2.0 extension schema (§6.3.2)

Still tolerated by Factur-X 1.09 ("marked as deprecated, … may change in future"). Same structural rules as §6.3 but:

PropertyValue
Extension schema nameZUGFeRD PDF/A Extension Schema
URIurn:zugferd:pdfa:CrossIndustryDocument:invoice:1p0#
Schema prefixzf
zf:DocumentTypeINVOICE
zf:DocumentFileNameFixed zugferd-invoice.xml
zf:Version2p0
zf:ConformanceLevelOne of MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED

4. Additional attachments (other than the invoice XML)

PDF/A-3 allows further embedded files; Factur-X imposes the following constraints (§3 Principle 1, §6.4):

  • Only the following formats may be attached: PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON, XLS, XLSX, ODS. (Δ vs 2.4: XLS added to the list — the previous releases only listed XLSX.)
  • The PDF/A-3 embedding rules (MIME type, file-specification dictionary, Names tree, AF entry) apply to each attachment.
  • Factur-X does not require any additional XMP metadata structures for non-invoice attachments. Standard PDF/A-3 embedding suffices.
  • Reserved attachment file names for alternative representations of the same invoice:
    • EDIFACT representation → factur-xedifact.edi (TXT file)
    • UBL representation → factur-xubl.xml
  • Each attached document should be qualified to indicate its function (invoice data, voucher, general conditions of sale, etc.).

German-specific rule (BR-FX-DE-01, Fatal): in DE↔DE transactions, supporting documents that prove place / time / kind of supplied goods or services SHALL be referenced via BG-24 in the XML. Embedding them in the PDF (visible content, additional embedded file, or external document) is not sufficient by itself.

5. Visual representation (the PDF "image" of the invoice)

  • Principle 2 (§3): the human-readable presentation SHALL contain all invoice information; the XML may carry a subset. In DE the XML additionally has to carry all mandatory invoice information.
  • Principle 4 (§3): the issuer is responsible for consistency between the visual representation and the XML; data present in both must match.
  • Good-practice presentation (§5.2) — recommendations, not technical requirements:
    • Single-page invoice: header with labelled/tabulated references; line items in columns; explicit VAT breakdown.
    • Multi-page invoice: first page = header + footer only; following pages = line items in columns.
  • Profile logos (§6.5) may be added to the visual representation to signal that the PDF is a Factur-X file and identify its profile (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). Optional.

6. Securing the PDF envelope

§4 lists two acceptable modes (the choice is the issuer's; both are allowed, neither is mandated by the spec):

  • Qualified electronic signature / qualified electronic seal applied to the PDF envelope.
  • Documented reliable audit trail linking the invoice to the underlying delivery / service.

EDI mode (Directive 2006/112/EC art. 233 §2b, as amended by Directive 2010/45/EU and ViDA 2025/516) is considered unsuited to the hybrid invoice as a whole, but may be applied to the XML part alone when AFRelationship is Alternative or Source. (§4.)

7. Hybrid Business Rules (HYBRID) — quick reference

All BR-HYBRID-* rules apply to FR + DE unless noted. Source: spec appendix "3.d Business Rules for HYBRID Documents". Text and severities are byte-identical to 2.4 (verified by extracting selectable text from both PDFs).

IDLevelRule
BR-HYBRID-01InfoHybrid = machine-readable XML + human-readable PDF envelope.
BR-HYBRID-02FatalPDF envelope SHALL be PDF/A-3 (PDF/A-4f optionally allowed).
BR-HYBRID-03FatalPDF/A XMP extension schema with the prescribed structure SHALL be used.
BR-HYBRID-04FatalExtension schema URI SHALL be urn:factur-x:pdfa:CrossIndustryDocument:1p0# (see note in §3 above; §6.3.1 uses the longer …:invoice:1p0# form).
BR-HYBRID-05FatalSchema namespace prefix SHALL be fx.
BR-HYBRID-06Fatalfx:DocumentType value SHALL be from HybridDocumentType.
BR-HYBRID-07Fatalfx:ConformanceLevel value SHALL be from HybridConformanceType.
BR-HYBRID-08Fatalfx:DocumentFileName value SHALL be from HybridDocumentFilename.
BR-HYBRID-09Fatalfx:Version value SHALL be from HybridDocumentVersion.
BR-HYBRID-10Warningfx:Version SHOULD be 1.0.
BR-HYBRID-11Warning/AFRelationship SHOULD follow the profile × country matrix above.
BR-HYBRID-12FatalXML embedding method SHALL conform to this specification (extractability).
BR-HYBRID-13FatalEmbedded file name SHALL be from HybridDocumentFilename.
BR-HYBRID-14WarningEmbedded file name SHOULD match fx:DocumentFileName.
BR-HYBRID-15Warningfx:ConformanceLevel SHOULD match the profile of the embedded XML.
BR-HYBRID-DE-01FatalDE↔DE: MINIMUM profile SHALL NOT be used.
BR-HYBRID-DE-02FatalDE↔DE: BASIC WL profile SHALL NOT be used.
BR-HYBRID-FR-01FatalFR↔FR: XRECHNUNG profile SHALL NOT be used.
BR-FX-DE-01FatalDE: supporting documents proving place/time/kind SHALL be in BG-24 (not in PDF).
BR-FX-DE-02FatalDE: main services SHALL be detailed in the XML.
BR-FX-DE-03WarningDE↔DE: as of 2025-01-01 the XML is the invoice. PDF/A technical errors are downgraded from Fatal to Warning provided the XML is valid and extractable.

8. Versioning and validation artefacts (§6.6)

  • The XMP value fx:Version stays 1.0 even though the Factur-X spec version increases (now 1.09).
  • Spec version is reflected in:
    • XML BT-24 (specification identifier), e.g. for BASIC: urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic — unchanged across the 1.zz family.
    • Validation artefacts (XSD, Schematron) versioned alongside the spec (now 1.09, 1.09.x for bug-fix releases).
  • Factur-X invoices issued under earlier 1.zz versions remain valid in the latest 1.zz revision (upward compatibility).

Editorial inconsistency in §6.6

The §6.6 heading still reads "Factur-X 1.08 maintenance and validation artefacts" and the body still states "The versioning of the validation artefacts corresponds with the versioning of the Factur-X Standard documentation, which is 1.08 for this current version". This is a copy-paste oversight from 2.4 — the document is unambiguously labelled 1.09 in its title page, footer running header ("Factur-X Specification 1.09"), and the version-history table on page 8 (1.09 / 2026-06-10). Treat 1.08 here as a typo for 1.09 pending an erratum.

9. Profiles (recap)

Unchanged vs 2.4. The six profiles defined in §3 / §7 are:

  • MINIMUM
  • BASIC WL (Basic Without Lines)
  • BASIC
  • EN 16931 (formerly COMFORT)
  • EXTENDED — substantively expanded in 1.09; this is the carrier-independent XML change. (See §11 below.)
  • XRECHNUNG (reference profile; XML defined and maintained by KoSIT)

10. What this means for kaltblut (PDF-carrier scope)

Nothing structural changes for a PDF-carrier validator:

  • The XMP namespace URI is identical to 2.1 through 2.4 (urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#). A ZUGFeRD 2.5 PDF is indistinguishable from a 2.4 PDF by namespace alone — the spec generation can only be inferred from the BT-24 specification identifier inside the embedded XML (XML-side concern, not carrier).
  • The BR-HYBRID-* rule set, severities, and country variants are byte-identical to 2.4.
  • The AFRelationship matrix is unchanged.
  • The embedded XML file name convention is unchanged (factur-x.xml or xrechnung.xml).
  • The fx:Version value remains 1.0.

The only carrier-level Δ is the attachment format whitelist gaining XLS (legacy Excel binary). A validator that enforces the whitelist should accept XLS from 2.5 onward; in 2.4 it was not listed.

11. Out-of-scope changes (XML / EXTENDED-profile)

The bulk of 1.09 is XML-side and lies outside kaltblut's remit. Captured here purely as context for cross-referencing:

  • New Business Terms in EXTENDED (mostly to anticipate the Revised EN 16931 2026): BT-177 / BT-177-1, BT-193 / BT-193-1, BT-216, BT-215, BT-173, BT-174, BT-175, BT-176, BT-X-591, BT-X-592, BG-34, BT-180, BT-179, BG-X-94 (with BT-X-600, BT-X-598, BG-X-93).
  • EXTENDED cardinality changes: BT-160 → 0..1, BT-161 → 0..1, BT-131-00 → 0..1, BT-131 → 0..1.
  • EXTENDED business-rule churn: BR-FXEXT-BR-27 and BR-FXEXT-BR-28 deleted (negative unit prices now allowed); BR-38, BR-44 replaced by BR-FXEXT-BR-38, BR-FXEXT-BR-44; BR-CO-06/08/16/22/24 replaced by BR-FXEXT-CO-* equivalents.
  • VAT-calculation BRs updated to anticipate the Revised EN 16931: 2026 BR-FXEXT-S-08, S-09, Z-08, E-08, IC-08, AE-08, AF-08, AG-08; BR-S-10, BR-Z-10, BR-AF-10, BR-AG-10 deleted.
  • ID CTC FR codes updated: EXT-FR-FE-178, EXT-FR-FE-179, EXT-FR-FE-180.
  • All-profile EN 16931 code-list refresh, valid from 2026-05-15 (Excel file 2_EN16931 code lists values v17b - … - Fx 1.09.xlsx).
  • All-profile CEN validation-rule refresh, valid from 2026-05-15.

None of these affect detection, extraction, or BR-HYBRID-* validation in kaltblut; they would only matter to a downstream XML business-rule validator (e.g. phive-rules-zugferd).