ZUGFeRD 2.3 / Factur-X 1.0.07
June 10, 2026 · View on GitHub
Source: docs/2.3/Documentation/1. FACTUR-X 1.0.07 EN.pdf
(Factur-X Specification 1.0.07, dated 2024-09-18; ZUGFeRD 2.3 == Factur-X 1.0.07).
Scope: requirements that apply to the PDF carrier file only.
Headline diff vs 2.3.2:
- No
BR-HYBRID-*rule block. That table was introduced in spec version 1.07.2 (= ZUGFeRD 2.3.2). All carrier requirements in 2.3 are expressed purely as prose in §§2.2, 3, 6.x. - Cosmetic: the spec version is rendered as both "1.0.07" and "1.01.07" in the document (mixed notation). They refer to the same release.
Apart from that, the carrier requirements are identical in wording to 2.3.2 / 2.3.3 / 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; the PDF is the envelope and the original tax 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).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 references the file specification dictionary. (§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 later versions: Data (PDF richer than XML),
Source (XML generated the PDF), Alternative (equivalent
representations).
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 (1.0.07).- 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 XMP extension 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 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 (§6.4)
- Allowed formats: PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON, XLSX, ODS.
- 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.0.07.- 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). - Bug-fix releases use a third numbering level (1.01.07.01).
- Upward compatibility: invoices issued under earlier 1.zz versions remain valid in this release.