ZUGFeRD 2.5.2 / Factur-X 1.09.2
August 9, 2026 · View on GitHub
Source: docs/2.5.2/Documentation/0_FACTUR-X_1.09.2_EN.pdf
(Factur-X Specification 1.09.2, dated 2026-08-04; ZUGFeRD 2.5.2 == Factur-X 1.09.2).
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.5 is a single new rule. Sections 1 through 6 of the 1.09.2 specification (carrier format, embedding, XMP extension schema, AFRelationship, additional attachments, securing) are textually identical to 1.09 — verified by extracting and diffing the selectable text of both PDFs (only footers and pagination differ). The only change in the HYBRID appendix (3.d) is the new rule BR-FX-DE-04 (Warning, DE) — an XML-content rule about the delivery/service date that cannot be checked at the carrier level. Everything else in 1.09.2 is XML-side Schematron / business-rule maintenance. See §10 below.
Version history recorded in the 1.09.2 document:
- 1.09.1 (2026-06-11): technical correction to the EXTENDED-profile Schematron due to a delivery issue. No specification-document change.
- 1.09.2 (2026-08-04): XML-side rule maintenance (see §10) plus the new BR-FX-DE-04 in the HYBRID appendix.
1. Carrier format
Identical to 2.5 (spec §3 Principle 1; §6 intro; BR-HYBRID-02):
- The PDF envelope SHALL conform to PDF/A-3 (ISO 19005-3, based on ISO 32000-1:2008 = PDF 1.7). A PDF/A-4f file (ISO 19005-4, based on PDF 2.0 = ISO 32000-2:2020) is also allowed as an option.
- The PDF/A conformance level (3a / 3b / 3u) is irrelevant for Factur-X compliance; 3a is recommended for accessibility. (§2.2, §6 intro, §6.1.)
- The source PDF SHALL be PDF/A-3 compliant before the structured invoice data file is embedded. (§2.2, §6 intro.)
- One PDF carries exactly one invoice; the PDF is the envelope and the legally relevant artefact. (§3 Principle 1.)
- There is no naming convention for the PDF file itself. (§6 intro.)
- PDF/A-3 derived constraints (§6.1): XMP metadata, embedded fonts, no external references, no active content, image formats CCITT G3/G4, JBIG2, JPEG, JPEG2000, no encryption / DRM.
2. Embedded structured invoice file
Identical to 2.5 (§6.2, §6.2.1, §6.2.2):
- File name
factur-x.xml;xrechnung.xmlfor the XRECHNUNG reference profile. (BR-HYBRID-13 Fatal; BR-HYBRID-14 Warning.) - MIME type
text/xml. - Embedded via a PDF file specification dictionary;
/Paramswith at least/ModDateSHOULD be present; reachable via the Names tree (/Names → /EmbeddedFiles, one or two/Kidslevels permitted); registered as Associated File at document level (/AFon the document catalogue). (BR-HYBRID-12 Fatal.) /AFRelationshipmatrix (BR-HYBRID-11 Warning) unchanged:
| Profile | France | Germany |
|---|---|---|
| MINIMUM | Data | Data |
| BASIC WL | Data | Data |
| BASIC | Alternative, Source, Data | Alternative |
| EN 16931 | Alternative, Source, Data | Alternative |
| EXTENDED | Alternative, Source, Data | Alternative |
| XRECHNUNG | n/a (not used in France) | Alternative |
3. PDF/A XMP extension schema (Factur-X 1.0)
Identical to 2.5 (§6.3, §6.3.1, BR-HYBRID-03 to -10):
| Property | Value |
|---|---|
| Extension schema name | Factur-X PDFA Extension Schema |
| URI (namespace) | urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# |
| Schema prefix | fx |
- The trailing
#is required;1p0is the extension schema version (stays1p0, independent of the spec version, now 1.09.2). - XMP fields
fx:DocumentType(INVOICE),fx:DocumentFileName,fx:Version(1.0),fx:ConformanceLevel(MINIMUM,BASIC WL,BASIC,EN 16931,EXTENDED,XRECHNUNG) — unchanged. - BR-HYBRID-04 inconsistency persists: the rule text still says
urn:factur-x:pdfa:CrossIndustryDocument:1p0#(without:invoice) while §6.3.1 and the worked example use the longer…:invoice:1p0#form. Treat §6.3.1 as authoritative. (Unchanged since 2.3.2.) - Legacy ZUGFeRD 2.0 extension schema (§6.3.2,
urn:zugferd:pdfa:CrossIndustryDocument:invoice:1p0#, prefixzf,zugferd-invoice.xml, version2p0) still tolerated, still marked deprecated.
4. Additional attachments (other than the invoice XML)
Identical to 2.5 (§3 Principle 1, §6.4):
- Allowed formats: PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON, XLS,
XLSX, ODS (the
XLSaddition happened in 2.5; no further change). - Standard PDF/A-3 embedding rules apply; no extra XMP metadata required for non-invoice attachments.
- Reserved names: EDIFACT →
factur-xedifact.edi(TXT), UBL →factur-xubl.xml.
5. Visual representation and securing
Identical to 2.5: Principles 2 and 4 (§3), good-practice presentation
(§5.2), optional profile logos (§6.5), securing via qualified electronic
signature/seal or documented reliable audit trail (§4), EDI mode only
for the XML part when AFRelationship is Alternative or Source.
6. Hybrid Business Rules (HYBRID) — quick reference
Source: spec appendix "3.d Business Rules for HYBRID Documents". BR-HYBRID-01 through BR-HYBRID-15, the country variants and BR-FX-DE-01 to -03 are textually identical to 2.3.2 / 2.3.3 / 2.4 / 2.5 (verified by extracting the selectable text from the 1.09 and 1.09.2 PDFs). New in 1.09.2: BR-FX-DE-04.
| ID | Level | Rule |
|---|---|---|
| BR-HYBRID-01 | Info | Hybrid = machine-readable XML + human-readable PDF envelope. |
| BR-HYBRID-02 | Fatal | PDF envelope SHALL be PDF/A-3 (PDF/A-4f optionally allowed). |
| BR-HYBRID-03 | Fatal | PDF/A XMP extension schema with the prescribed structure SHALL be used. |
| BR-HYBRID-04 | Fatal | Extension 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-05 | Fatal | Schema namespace prefix SHALL be fx. |
| BR-HYBRID-06 | Fatal | fx:DocumentType value SHALL be from HybridDocumentType. |
| BR-HYBRID-07 | Fatal | fx:ConformanceLevel value SHALL be from HybridConformanceType. |
| BR-HYBRID-08 | Fatal | fx:DocumentFileName value SHALL be from HybridDocumentFilename. |
| BR-HYBRID-09 | Fatal | fx:Version value SHALL be from HybridDocumentVersion. |
| BR-HYBRID-10 | Warning | fx:Version SHOULD be 1.0. |
| BR-HYBRID-11 | Warning | /AFRelationship SHOULD follow the profile × country matrix above. |
| BR-HYBRID-12 | Fatal | XML embedding method SHALL conform to this specification (extractability). |
| BR-HYBRID-13 | Fatal | Embedded file name SHALL be from HybridDocumentFilename. |
| BR-HYBRID-14 | Warning | Embedded file name SHOULD match fx:DocumentFileName. |
| BR-HYBRID-15 | Warning | fx:ConformanceLevel SHOULD match the profile of the embedded XML. |
| BR-HYBRID-DE-01 | Fatal | DE↔DE: MINIMUM profile SHALL NOT be used. |
| BR-HYBRID-DE-02 | Fatal | DE↔DE: BASIC WL profile SHALL NOT be used. |
| BR-HYBRID-FR-01 | Fatal | FR↔FR: XRECHNUNG profile SHALL NOT be used. |
| BR-FX-DE-01 | Fatal | DE: supporting documents proving place/time/kind SHALL be in BG-24 (not in PDF). |
| BR-FX-DE-02 | Fatal | DE: main services SHALL be detailed in the XML. |
| BR-FX-DE-03 | Warning | DE↔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. |
| BR-FX-DE-04 | Warning | New in 1.09.2. DE: an invoice that is not a down payment invoice (type code 386) must contain either BT-72 "Actual delivery date", BG-14 "Invoicing period" or BG-26 "Invoice line period" in each invoice item to indicate the delivery/service date. If BT-72 is not specified, at least the country of delivery (BT-80) must be specified for technical reasons. |
Note on BR-FX-DE-04: although listed in the HYBRID appendix, it is an XML-content rule (invoice type code, BT-72 / BG-14 / BG-26 / BT-80) — like BR-FX-DE-01 and -02 it cannot be verified by inspecting the PDF carrier alone.
7. Versioning and validation artefacts (§6.6)
fx:Versionstays1.0; the spec version (1.09.2) is reflected only in the XML BT-24 specification identifier and the validation-artefact versioning.- The EN 16931 code-list Excel shipped with the release is
v17b, valid from 2026-05-15 (unchanged from 1.09). - §6.6 editorial inconsistency persists: the heading still reads "Factur-X 1.08 maintenance and validation artefacts" and the body still says "which is 1.08 for this current version" — carried over unfixed from 2.4 and 2.5. The document is unambiguously labelled 1.09.2 on the title page, in the footer running header, and in the version-history table.
8. Profiles (recap)
Unchanged: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG.
9. What this means for kaltblut (PDF-carrier scope)
Nothing changes for a PDF-carrier validator:
- The XMP namespace URI is identical to 2.1 through 2.5. A ZUGFeRD 2.5.2 PDF is indistinguishable from a 2.4 / 2.5 PDF by namespace alone — the spec generation is only visible from the BT-24 specification identifier inside the embedded XML (XML-side concern).
- BR-HYBRID-01 to -15, the country variants and BR-FX-DE-01 to -03 are textually unchanged; severities unchanged.
- The new BR-FX-DE-04 (Warning, DE) is not technically checkable at the carrier level (requires the invoice type code and BT-72 / BG-14 / BG-26 / BT-80 from the XML), matching the treatment of BR-FX-DE-01 and -02 — no validator change needed.
- AFRelationship matrix, embedded-file naming,
fx:Version(1.0) and the attachment format whitelist are all unchanged vs 2.5.
10. Out-of-scope changes (XML / Schematron)
The bulk of 1.09.2 is XML-side rule maintenance, outside kaltblut's remit. From the version history, for cross-referencing:
- BASIC WL / BASIC / EN 16931: BR-CO-27 renamed CII-SR-470 (same rule).
- EXTENDED: cardinality of BT-151 / BT-151-0 relaxed from 1..1 to 0..1
in the XSD (to allow BT-X-589 alone in BG-30 for lines with subtype
BT-X-8 =
GROUP/INFORMATION); BR-FXEXT-CO-04 keeps them mandatory forDETAIL/ untyped lines. - EXTENDED: BR-S-1, BR-Z-1, BR-E-1, BR-AE-1, BR-IC-1, BR-G-1, BR-O-1, BR-AF-1, BR-AG-1 deleted and replaced by BR-FXEXT-*-01 equivalents (allowing more than one VAT breakdown BG-23 per category); BR-54 replaced by BR-FXEXT-BR-54-1 / -54-2; BR-FXEXT-08 corrected (BT-131 rounding); BR-FXEXT-06 corrected/clarified.
- CII syntax rules CII-SR-463 to CII-SR-473 added to BASIC WL, BASIC, EN 16931 and EXTENDED; CII-SR-474 added to BASIC WL, BASIC, EN 16931; CII-SR-475 / CII-SR-476 added to EN 16931 and EXTENDED; swapped error messages of CII-SR-471 / CII-SR-472 corrected.
- All Schematron rules now carry their BR ID or a specific
FX-SCH-A-XXXXXXidentifier.
None of these affect detection, extraction, or BR-HYBRID-* validation in kaltblut; they matter only to a downstream XML business-rule validator (e.g. phive-rules-zugferd).