ZUGFeRD 2.1 / Factur-X 1.0.05
June 10, 2026 · View on GitHub
Sources (all under docs/2.1/EN/Documentation/EN/):
ZUGFeRD-2.1-Specification.pdf(24 pages, dated 2020-03-24) — the ZUGFeRD-only consolidated specification text.ZUGFeRD-2.1-Specification_TA.pdf— Technical Appendix (XML / business-term data dictionary).ZUGFeRD-2.1-Specification_TA_Supplement-A.pdf— Technical Supplement Part A. PDF carrier rules for the primaryfactur-x.eunamespace (fx:prefix).ZUGFeRD-2.1-Specification_TA_Supplement-B.pdf— Technical Supplement Part B. PDF carrier rules for the legacyzugferd.denamespace (zf:prefix, version2p0), kept for backward compatibility with ZUGFeRD 2.0.
ZUGFeRD 2.1 == Factur-X 1.0.05.
Scope: requirements that apply to the PDF carrier file only.
Headline diffs vs 2.2 (Factur-X 1.0.06):
- No PDF/A-4f option. Only PDF/A-3 is acceptable as carrier.
- No XRECHNUNG reference profile in the AFRelationship matrix (XRECHNUNG was added in 2.2).
- The structured XML file may be named
factur-x.xml(primary, Supplement A) orzugferd-invoice.xml(legacy, Supplement B). Two parallel extension schemas (fx:andzf:) are defined; an invoice may use either. - Attachment format list is given by MIME type (per EN 16931), not by extension. Only PDF, PNG, JPEG, CSV/text, XLSX, ODS are accepted in BASIC / BASIC WL / EN 16931 / MINIMUM profiles. EXTENDED profile permits any valid MIME type. (2.2 dropped the profile-dependence and listed extensions instead.)
- §6.1 in 2.1 does not list the PDF/A-3 image-format whitelist (CCITT G3/G4, JBIG2, JPEG, JPEG2000) explicitly. The restriction still applies because it is inherited from ISO 19005-3. 2.2 added this restriction explicitly to its prose.
- "fx:Version" example value: Supplement A's table shows
1p0; the worked XMP example shows1.0. Both forms appear in the same document; later spec versions standardise on1.0.
1. Carrier format
- PDF envelope SHALL conform to PDF/A-3 (ISO 19005-3, based on ISO 32000-1 = PDF 1.7). (Supplement A / B §2.)
- No PDF/A-4f option in this version.
- PDF/A-3 conformance level (3a / 3b / 3u) is irrelevant. (Supplement A / B §2.)
- The source PDF SHALL be PDF/A-3 compliant before the structured invoice data file is embedded. (Supplement A / B §2.)
- One PDF carries exactly one invoice data document. (Spec §3.1 plus Supplement A / B §2 point 2.)
- No naming convention for the PDF file itself. (Supplement A / B §2.)
PDF/A-3 derived constraints (Supplement A / B §2.1)
- A PDF/A XMP extension schema SHALL declare the PDF/A property and conformance level.
- All metadata SHALL be embedded in XMP form (Document Information Dictionary alone is no longer permitted).
- All fonts SHALL be embedded (full or used-glyph subset).
- External files (non-invoice) may only be embedded via the PDF/A-3 associated-file mechanism.
- No active content (no JavaScript actions, no Flash animations).
- No encryption, no DRM, no usage-rights authorization control.
(Note: the explicit "permitted image formats" whitelist that appears in 2.2 onward is absent from the 2.1 supplement text but applies anyway via ISO 19005-3.)
2. Embedded structured invoice file
2.1 File name
factur-x.xml— primary, used with thefx:namespace (Supplement A §2.2).zugferd-invoice.xml— legacy, used with thezf:namespace (Supplement B §2.2). Retained for backward compatibility with ZUGFeRD 2.0; supplement B states "ZUGFeRD 2.0 is considered as outdated" and "should not be used in new implementations".
2.2 MIME type
text/xml(always). (Supplement A / B §2.2.)
2.3 File specification dictionary / stream
- The XML SHALL be embedded via a PDF file specification dictionary. (Supplement A / B §2.2.)
- The stream dictionary SHOULD have a
/Paramsentry. If/Paramsis present, it SHALL contain a/ModDatevalue (last modification date of the embedded file). An empty/Paramsdictionary is not permitted. (Supplement A note p. 8; Supplement B §2.2.) - The embedded document SHOULD be included in the Names object tree so that conformant PDF tools can list it.
- The XML SHALL be registered as an Associated File at document
level via the
/AFarray on the document catalogue. (Supplement A / B §2.2.1.) - Flat-array
/Nameslayout and hierarchical/Names → /Kidslayouts are both acceptable. (Supplement A note p. 7.)
2.4 AFRelationship matrix
(Country-conditional rules from Supplement A §2.2.2 / Supplement B §2.2.2. The matrix is expressed as application notes, not a table.)
| Profile | France | Germany |
|---|---|---|
| MINIMUM | Data | Data |
| BASIC WL | Data | Data |
| BASIC | Source (if PDF derived from XML) / Data | Alternative |
| EN 16931 (COMFORT) | Source / Data | Alternative |
| EXTENDED | Source / Data | Alternative |
(XRECHNUNG row not present — that profile is added in 2.2.)
Semantics of values (Supplement A / B §2.2.2):
Data— XML carries data behind the PDF rendering. Used for MINIMUM / BASIC WL where the XML is only a booking aid.Source— PDF was generated from the XML; XML is the full source.Alternative— PDF and XML are equivalent representations. Mandatory in Germany for BASIC, EN 16931 and EXTENDED.Supplement/Unspecifiedare defined by PDF/A-3 but not used for the invoice XML itself.
The data relationship value is informational at the PDF layer (Supplement A note p. 7: "Specifying the data relationship serves a purely informative purpose; it has no technical ramifications within the PDF file"). Validators may, however, check it depending on country context.
3. PDF/A XMP extension schema
Two parallel schemas are defined; an invoice uses one of them.
3.1 Primary: Factur-X 1.0 (Supplement A §2.3)
| Property | Value |
|---|---|
| Extension schema name | ZUGFeRD PDFA Extension Schema (per Table 1; the worked example sets the embedded <pdfaSchema:schema> literal to Factur-x PDFA Extension Schema — both forms appear in the doc) |
| URI (namespace) | urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# |
| Schema prefix | fx |
Fields:
| Field | Description | Example |
|---|---|---|
fx:DocumentType | Always INVOICE. | INVOICE |
fx:DocumentFileName | Embedded XML file name; SHALL match /F in the file spec dictionary. Fixed to factur-x.xml. | factur-x.xml |
fx:Version | "Major and minor version of the underlying invoice data specification." Doc table example is 1p0; worked example uses 1.0. Revision numbers are not taken into account. | 1.0 / 1p0 |
fx:ConformanceLevel | Profile of the structured XML: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED (note: EN16931 is also tolerated). | EN 16931 |
Worked example:
<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>EN 16931</fx:ConformanceLevel>
</rdf:Description>
3.2 Legacy: ZUGFeRD 2.0 (Supplement B §2.3)
Retained for backward compatibility; new implementations should use 3.1.
| Property | Value |
|---|---|
| Extension schema name | ZUGFeRD PDFA Extension Schema |
| URI | urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0# (note: 2p0, not 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 |
3.3 General
- The extension schema definition SHALL be embedded in the XMP packet (not externally referenced).
- The URN SHALL terminate with
#. - "EN 16931" includes a space; the abbreviated form "EN16931" is also permitted.
fx:ConformanceLevel/zf:ConformanceLevelSHALL be picked from the XML elementGuidelineSpecifiedDocumentContextParameter/ BT-24 of the embedded XML.
4. Additional attachments (Supplement A / B §2.4.2)
ZUGFeRD 2.1 references EN 16931 for the allowed list of attachment formats. The constraint is profile-dependent:
| Profile | Allowed attachment formats |
|---|---|
| MINIMUM, BASIC WL, BASIC, EN 16931 | PDF (application/pdf), PNG (image/png), JPEG (image/jpeg), Text/CSV (text/csv), Microsoft Excel (XLSX), OpenOffice Calc (ODS) |
| EXTENDED | Any file format with a valid MIME type |
(2.2 simplifies this to a flat extension list — PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON — and drops the profile-dependence.)
- Factur-X / ZUGFeRD does not require additional XMP metadata for non-invoice attachments; existing XMP schemata from ISO 16684 may be reused if desired.
- EN 16931 also allows referencing attachments via URL
(
AdditionalReferencedDocument); ZUGFeRD prefers embedding.
5. Visual representation and securing
- Spec §4.1: PDF and XML are "substantially identical multi-units" of the same invoice. The issuer ensures both are consistent for VAT-relevant data; the recipient must verify on receipt.
- §6 (Differences vs 1.0): the embedded file is named
factur-x.xml, the metadata extension schema has changed tofx:/ Factur-X version1p0, supporting documents are referenced via relative URL from the XML. - Section 5.3.4 / Supplement B §2.5 — archiving constraints (long-term preservation properties of PDF/A-3).
(2.1 does not contain the §5.2 "good-practice presentation" prose nor the §6.5 profile logos that appear from 2.2 onward.)
6. Versioning (spec §5.3.3)
Specification IDs used in BT-24 (carried over from BT-24 into
fx:ConformanceLevel / zf:ConformanceLevel):
| Profile | Factur-X / ZUGFeRD 2.1 | ZUGFeRD 2.0 legacy |
|---|---|---|
| EXTENDED | urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended | urn:cen.eu:en16931:2017#conformant#urn:zugferd.de:2p0:extended |
| EN 16931 (COMFORT) | urn:cen.eu:en16931:2017 | urn:cen.eu:en16931:2017 |
| BASIC | urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic | urn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p0:basic |
| BASIC WL | urn:factur-x.eu:1p0:basicwl | urn:zugferd.de:2p0:basicwl |
| MINIMUM | urn:factur-x.eu:1p0:minimum | urn:zugferd.de:2p0:minimum |
Versioning convention: MpN (M = main, N = sub, p separates because
. is reserved in URNs). All releases within a major version are
downward compatible; new elements are optional.
XSD set: factur-x_1p0_*.xsd (primary) or zugferd_2p0_*.xsd
(legacy). Schematron files published per profile.