ZUGFeRD 2.2 / Factur-X 1.0.06
June 10, 2026 · View on GitHub
Source: docs/2.2/DE/Documentation/1. FACTUR-X 1.0.06 EN.pdf
(Factur-X Specification 1.01.06, dated 2022-03-01; ZUGFeRD 2.2 == Factur-X 1.0.06).
Scope: requirements that apply to the PDF carrier file only.
Headline diff vs 2.3 (Factur-X 1.0.07):
- Attachment formats list is shorter: 2.2 allows PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON. The XLSX and ODS formats were added in 2.3.
- No
BR-HYBRID-*rule block (those were introduced in 1.07.2 = 2.3.2). - PDF/A-4f option is already present in 2.2.
Otherwise the carrier rules are identical wording to 2.3 / 2.3.x / 2.4.
1. Carrier format
- PDF envelope SHALL conform to PDF/A-3 (ISO 19005-3, based on ISO 32000-1:2008 = PDF 1.7). (§3 Principle 1; §6 intro.)
- A PDF/A-4f file (ISO 19005-4, based on PDF 2.0 = ISO 32000-2:2020) is allowed as an option. (§3 Principle 1 footnote.)
- PDF/A-3 conformance level (3a / 3b / 3u) is irrelevant; 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. (§3 Principle 1.)
- No naming convention for the PDF file itself.
PDF/A-3 derived constraints (§6.1)
- All metadata SHALL be embedded as XMP.
- All fonts used SHALL be embedded (full or used-glyph subset).
- No external file references; attachments only via the PDF/A-3 associated-file mechanism.
- No active content (no JavaScript actions, no Flash).
- Permitted embedded image formats: CCITT Group 3, CCITT Group 4, JBIG2, JPEG, JPEG2000.
- No encryption, no DRM, no authorization control.
2. Embedded structured invoice file
2.1 File name
factur-x.xml(default). (§6.2.)xrechnung.xmlwhen the XRECHNUNG reference profile is used.
2.2 MIME type
text/xml(always). (§6.2.)
2.3 File specification dictionary / stream
- The XML SHALL be embedded via a PDF file specification dictionary.
- The embedded file stream dictionary SHOULD contain a
/Paramsdictionary with at least a/ModDateentry. (§6.2.) - The embedded document SHALL be reachable via the Names tree
(
/Names → /EmbeddedFiles); one or two/Kidsintermediate levels are tolerated. - The XML SHALL be registered as an Associated File at document
level:
/AFarray on the document catalogue. (§6.2.1.)
2.4 AFRelationship matrix (§6.2.2)
| 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 | Alternative |
Semantics — same as in 2.3 / 2.4. The 2.2 note refers to the Alternative requirement as covering "ZUGFERD 2.2.x = Factur-X 1.0" (no mention of 2.3 because it had not yet been released).
3. PDF/A XMP extension schema (Factur-X 1.0)
| 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):
- Trailing
#is required. 1p0in the URI is the extension-schema version, not the spec version.- The extension schema definition SHALL be embedded in the XMP packet.
XMP fields under the fx: namespace
| Field | Description | Example |
|---|---|---|
fx:DocumentType | Always INVOICE. | INVOICE |
fx:DocumentFileName | File name of the embedded invoice XML; SHALL match the /F key of the file specification dictionary. Fixed to factur-x.xml (or xrechnung.xml). | factur-x.xml |
fx:Version | Version of the XML schema for invoice data; stays 1.0. | 1.0 |
fx:ConformanceLevel | Profile of the structured XML: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG. | EXTENDED |
Legacy: ZUGFeRD 2.0 extension schema (§6.3.2)
Still tolerated ("marked as deprecated, … may change in future"):
| Property | Value |
|---|---|
| Extension schema name | ZUGFeRD PDFA 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 (§6.4)
- Allowed formats: PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON. XLSX and ODS are not yet permitted in 2.2 — they are added in 2.3.
- Standard PDF/A-3 embedding rules apply.
- Factur-X does not require additional XMP metadata for non-invoice attachments.
- Reserved names for alternative representations:
- EDIFACT →
factur-xedifact.edi(TXT file) - UBL →
factur-xubl.xml
- EDIFACT →
5. Visual representation and securing
- §3 Principle 2 — PDF carries all info; XML may be a subset except in DE where mandatory invoice fields must also appear in the XML.
- §3 Principle 4 — issuer ensures consistency between visual and XML representations.
- §5.2 single-page / multi-page good-practice layouts — recommendations.
- §6.5 profile logos may be added (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). Optional.
- §4 security: qualified electronic signature/seal or documented reliable audit trail.
6. Versioning and validation artefacts (§6.6)
fx:Versionstays1.0even though the spec version is 1.01.06.- Spec version reflected in XML BT-24 (e.g. BASIC:
urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) and in versioned validation artefacts (XSD, Schematron). - Upward compatibility: invoices issued under earlier 1.zz versions remain valid in this release.