ZUGFeRD 2.0.1

June 10, 2026 · View on GitHub

Source: docs/2.0.1/ZUGFeRD201/Dokumentation/ZUGFeRD-2.0.1-Spezifikation.pdf (ZUGFeRD 2.0.1 Spezifikation, published 2019, German-language only).

Scope: requirements that apply to the PDF carrier file only.

Headline diffs vs 2.1:

Single namespace urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#. The primary urn:factur-x.eu:…:1p0 namespace is introduced in 2.1.
Embedded XML name is zugferd-invoice.xml (not factur-x.xml).
Schema prefix is fx but mapped to the ZUGFeRD URI. (2.1 Supplement A switches the prefix to fx against the Factur-X URI; 2.1 Supplement B keeps prefix zf with the ZUGFeRD URI. 2.0.1 sits in the middle: fx prefix + ZUGFeRD URI.)
No XRECHNUNG profile. Profiles are MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT), EXTENDED.
No PDF/A-4f option.
French dual semantics not specified — this is a ZUGFeRD-only document; the AFRelationship rules are written from the German tax perspective.
Attachments use MIME-type lists (per EN 16931), not extension lists.
2.0.1 explicitly defines the #ef=<filename> relative-URL fragment scheme for referencing attached files from the XML (AdditionalReferencedDocument/URIID). This convention is retained by EN 16931 and reused by later versions but is most clearly stated here.

1. Carrier format

PDF envelope SHALL conform to PDF/A-3 (ISO 19005-3, based on ISO 32000-1 = PDF 1.7). (§5.)
No PDF/A-4f option.
PDF/A-3 conformance level (3a / 3b / 3u) is irrelevant. (§5.)
The source PDF SHALL be PDF/A-3 compliant before embedded data. (§5.)
Exactly one invoice data document per PDF/A-3. (§5 point 2.)
The XML SHALL be embedded with relationship type Alternative at document level (§5 introductory bullets; profile-specific overrides in §5.2.2 below).
No PDF filename convention.

PDF/A-3 derived constraints (§5.1)

XMP extension schema with PDF/A property + conformance level.
All metadata SHALL be embedded as XMP.
All fonts SHALL be embedded (full or used-glyph subset).
No external (third-party) files except via the PDF/A-3 associated- file mechanism.
No active content (JavaScript actions, Flash, etc.).
No encryption, no authorization control.

(The explicit PDF/A-3 image-format whitelist that appears in 2.2 prose is absent here; ISO 19005-3 imposes it.)

2. Embedded structured invoice file

2.1 File name

zugferd-invoice.xml — fixed. (§5.2.)

2.3 File specification dictionary / stream

The XML SHALL be embedded via a PDF file specification dictionary.
The stream dictionary SHOULD have a /Params entry containing at least /ModDate. (§5.2.)
The embedded document SHALL be added to the /Names object tree. (§5.2.)
The XML SHALL be registered as an Associated File at document level: /AF array on the document catalogue references the file specification dictionary. (§5.2.1.)
Flat /Names array and hierarchical name-tree forms are both acceptable.

2.4 AFRelationship (§5.2.2)

Per §5.2.2 the data relationship has no technical effect inside the PDF but is informationally significant.

Profile	AFRelationship (German tax context)
MINIMUM	`Data`
BASIC WL	`Data`
BASIC	`Alternative`
EN 16931 (COMFORT)	`Alternative`
EXTENDED	`Alternative`

Additional rule: when the visual PDF representation was derived in full from the structured XML, Source may be used (indicating the XML is the authoritative source). No France-side rules are stated in 2.0.1.

Semantics of values (§5.2.2): Data, Source, Alternative, Supplement, Unspecified — same definitions as the later specifications.

3. PDF/A XMP extension schema ZUGFeRD (§5.3)

Property	Value
Extension schema name	`ZUGFeRD PDFA Extension Schema`
URI (namespace)	`urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#`
Schema prefix	`fx`

Notes:

The URN SHALL terminate with #.
The extension schema definition SHALL be embedded in every PDF/A document; an external reference is not sufficient.

XMP fields (under the `fx:` prefix mapped to the ZUGFeRD URI)

Field	Description	Example
`fx:DocumentType`	Always `INVOICE`.	`INVOICE`
`fx:DocumentFileName`	Embedded XML file name; SHALL match `/F` in the file specification dictionary. Fixed to `zugferd-invoice.xml`.	`zugferd-invoice.xml`
`fx:Version`	Version of the XML schema for the invoice data.	`2p0`
`fx:ConformanceLevel`	Profile of the XML invoice data: `MINIMUM`, `BASIC WL`, `BASIC`, `EN 16931`, `EXTENDED`. (Space inside `BASIC WL` and `EN 16931` is intended.) Picked from XML BT-24 `GuidelineSpecifiedDocumentContextParameter`.	`EN 16931`

Worked example (§5.3, Beispiel 1):

<rdf:Description rdf:about=""
    xmlns:fx="urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#">
  <fx:DocumentType>INVOICE</fx:DocumentType>
  <fx:DocumentFileName>zugferd-invoice.xml</fx:DocumentFileName>
  <fx:Version>2p0</fx:Version>
  <fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
</rdf:Description>

(Note: the namespace URI uses zugferd and version 2p0. The 2.1 Supplement B reproduces this exactly. From 2.2 onward, the ZUGFeRD URI is still tolerated but is repackaged as "legacy"; its version segment changes to 1p0 in 2.2's legacy section.)

4. Additional attachments (§5.4.2)

EN 16931 limits attachment formats to a profile-dependent set:

Profile	Allowed attachment MIME types
MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT)	`application/pdf`, `image/png`, `image/jpeg`, `text/csv`, `application/vnd.openxmlformatsofficedocument.spreadsheetml.sheet` (XLSX), `application/vnd.oasis.opendocument.spreadsheet` (ODS)
EXTENDED	not constrained by EN 16931 — any valid MIME type may be used

No extra XMP metadata is required for non-invoice attachments.
Attachments are referenced from the XML via AdditionalReferencedDocument/URIID containing a relative URL of the form #ef=<filename> (PDF fragment identifier per RFC 3986 / RFC 8118). Example: <ram:URIID>#ef=rapport.png</ram:URIID>. (§5.4.2.3.)
Direct binary embedding inside the XML (AttachmentBinaryObject) is permitted by EN 16931 but requires bilateral agreement; ZUGFeRD prefers the relative-URL form.

5. Securing, transfer and archiving

§5.4.1 transfer: no specific protocol mandated. Email, DE-Mail, OpenPeppol, AS2, FTP, etc. are all acceptable; choose protection appropriate to the sensitivity of the data.
§5.5 archiving: requirements vary by country; national rules apply.
No "good-practice presentation" prose and no profile logos are defined in 2.0.1 (those appear from 2.2 onward).
No BR-HYBRID-* business rule block (introduced in 2.3.2).

6. Versioning (spec §4.3.3 not extracted here)

The XML BT-24 GuidelineSpecifiedDocumentContextParameter carries the specification identifier, e.g. for BASIC: urn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p0:basic. The fx:Version value in XMP (2p0) matches the URN's version segment. fx:ConformanceLevel SHALL be derived from BT-24.