ZUGFeRD 2.4 / Factur-X 1.08
June 10, 2026 · View on GitHub
Source: docs/2.4/EN/Documentation/0_FACTUR-X_1.08_2025_12_04_EN.pdf
(Factur-X Specification 1.08, dated 2025-12-04; ZUGFeRD 2.4 == Factur-X 1.08).
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.
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.xmlorxrechnung.xml). - BR-HYBRID-14 (Warning): the embedded file name SHOULD match
fx:DocumentFileNamein 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
/Paramsdictionary that contains at least a/ModDateentry 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/Kidsintermediate levels between/EmbeddedFilesand 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
/AFarray SHALL be on the document catalogue (Root), and SHALL reference the file specification dictionary offactur-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
/AFRelationshipkey 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.
| 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 |
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).SupplementandUnspecifiedexist 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.)
| Property | Value |
|---|---|
| Extension schema name | Factur-X PDFA Extension Schema |
| URI (namespace) | urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# |
| Schema prefix | fx |
Notes (§6.3.1):
- The trailing
#in the URI is required. - The
1p0in the URI is the extension schema version, not the Factur-X spec version. It stays at1p0and is independent of the spec version (currently 1.08). - 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:invoicesegment). §6.3.1 and the worked example use the longer…:invoice:1p0#form. Treat §6.3.1 as authoritative for actual files pending erratum.
XMP fields under the fx: namespace
| Field | Description | Example |
|---|---|---|
fx:DocumentType | Document type. SHALL be INVOICE (HybridDocumentType list). | INVOICE |
fx:DocumentFileName | File 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:Version | Version of the XMP extension schema. From HybridDocumentVersion list. BR-HYBRID-10 (Warning): SHOULD be 1.0. | 1.0 |
fx:ConformanceLevel | Profile 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:
- 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:DocumentTypevalue SHALL come from the HybridDocumentType code list. - BR-HYBRID-07 (Fatal):
fx:ConformanceLevelvalue SHALL come from the HybridConformanceType code list. - BR-HYBRID-08 (Fatal):
fx:DocumentFileNamevalue SHALL come from the HybridDocumentFilename code list. - BR-HYBRID-09 (Fatal):
fx:Versionvalue 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.08 ("marked as deprecated, … may change in future"). Same structural rules as §6.3 but:
| Property | Value |
|---|---|
| Extension schema name | ZUGFeRD PDF/A Extension Schema |
| URI | urn:zugferd:pdfa:CrossIndustryDocument:invoice:1p0# |
| Schema prefix | zf |
zf:DocumentType | INVOICE |
zf:DocumentFileName | Fixed zugferd-invoice.xml |
zf:Version | 2p0 |
zf:ConformanceLevel | One 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, XLSX, ODS.
- 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
- EDIFACT representation →
- 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 "Business Rules HYBRID".
| 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-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. |
8. Versioning and validation artefacts (§6.6)
- The XMP value
fx:Versionstays1.0even though the Factur-X spec version increases (currently 1.08). - 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 - Validation artefacts (XSD, Schematron) versioned alongside the spec (1.08, 1.08.x for bug-fix releases).
- XML BT-24 (specification identifier), e.g. for BASIC:
- Factur-X invoices issued under earlier 1.zz versions remain valid in the latest 1.zz revision (upward compatibility).