ZUGFeRD 2.3.3 / Factur-X 1.07.3

August 9, 2026 · View on GitHub

Source: docs/2.3.3/ZF233_EN_01/Documentation/1. FACTUR-X 1.07.3 EN.pdf (Factur-X Specification 1.07.3, dated 2025-05-15; ZUGFeRD 2.3.3 == Factur-X 1.07.3).

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

Diff vs 2.4: the PDF-carrier sections of 2.3.3 and 2.4 are textually identical apart from version numbering and the appendix code-list date. The change history between 1.07.3 and 1.08 records only XML / code-list updates, no PDF carrier changes.

1. Carrier format

The 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 also allowed as an option. (§3 Principle 1 footnote.)
The 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.)
There is 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 font 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/animations).
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

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.

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 /Params dictionary with at least a /ModDate entry. (§6.2.)
The embedded document SHALL be reachable via the Names tree (/Names → /EmbeddedFiles). One or two /Kids levels between /EmbeddedFiles and the leaf entries are permitted. (§6.2, §6.2.2 note.)
The XML SHALL be registered as an Associated File at document level: the /AF array on the document catalogue references its 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 (§6.2.2):

Data — XML carries data backing the PDF rendering; used when the PDF contains more invoicing data than the XML (MINIMUM, BASIC WL).
Source — PDF rendered from the XML.
Alternative — both representations are equivalent. Required for German use with BASIC / EN 16931 / EXTENDED / XRECHNUNG profiles.
Supplement / Unspecified exist in PDF/A-3 but are not used for the invoice XML itself.

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):

The trailing # is required.
The 1p0 in the URI is the extension schema version, not the spec version. It stays 1p0, independent of the spec version (here 1.07.3).
The extension schema definition SHALL be embedded in the XMP packet.

XMP fields under the `fx:` namespace

Field	Description	Example
`fx:DocumentType`	Document type; always `INVOICE`.	`INVOICE`
`fx:DocumentFileName`	File name of the embedded invoice XML; SHALL match the `/F` key of its file specification dictionary. Fixed to `factur-x.xml` (or `xrechnung.xml` for XRECHNUNG).	`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: one of `MINIMUM`, `BASIC WL`, `BASIC`, `EN 16931`, `EXTENDED`, `XRECHNUNG`.	`EXTENDED`

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.

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 attachment formats: PDF, TXT, GIF, TIFF, JPG, CSV, XML, JSON, XLSX, ODS.
PDF/A-3 embedding rules apply (MIME type, file specification dictionary, Names tree, AF entry).
Factur-X does not require any extra XMP metadata structures for non-invoice attachments.
Reserved names for alternative representations of the same invoice:
- EDIFACT representation → factur-xedifact.edi (TXT file)
- UBL representation → factur-xubl.xml

5. Visual representation

§3 Principle 2: human-readable PDF SHALL contain all invoice information; XML may carry a subset. In DE the XML must additionally carry all mandatory invoice information.
§3 Principle 4: issuer ensures consistency between visual and XML representations.
§5.2 good-practice presentation models (single-page / multi-page) — recommendations only, not technical requirements.
§6.5 profile logos may be added to the visual representation (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). Optional.

6. Securing the PDF envelope (§4)

Two acceptable modes (issuer's choice):

Qualified electronic signature / qualified electronic seal applied to the PDF envelope.
Documented reliable audit trail linking invoice and delivery / service.

EDI mode 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.

7. Hybrid Business Rules (HYBRID)

The BR-HYBRID-* rule block was introduced in spec version 1.07.2 (change history entry for 2024-11-15: "Addition of management rules and code lists dedicated to HYBRID documents"). The rules continue to be listed in 1.07.3 as the closing appendix "3.d Business Rules for HYBRID Documents".

In the 1.07.3 PDF this table is rendered as an image and is therefore not extractable as selectable text. The wording matches the 1.08 table (see docs/2.4.md, section 7) — the 1.07.3 → 1.08 change history records no changes to BR-HYBRID rules. Summary:

BR-HYBRID-01 (Info) — definition of a hybrid document.
BR-HYBRID-02 (Fatal) — PDF/A-3, optionally PDF/A-4f.
BR-HYBRID-03..09 (Fatal) — XMP extension schema structure, URI, prefix fx, mandatory fields.
BR-HYBRID-10 (Warning) — fx:Version SHOULD be 1.0.
BR-HYBRID-11 (Warning) — /AFRelationship SHOULD follow the matrix.
BR-HYBRID-12 (Fatal) — embedding must allow easy XML extraction.
BR-HYBRID-13 (Fatal) — embedded file name from HybridDocumentFilename code list.
BR-HYBRID-14 (Warning) — embedded file name SHOULD match fx:DocumentFileName.
BR-HYBRID-15 (Warning) — fx:ConformanceLevel SHOULD match XML profile.
BR-HYBRID-DE-01/-02 (Fatal) — DE↔DE: MINIMUM and BASIC WL profiles forbidden.
BR-HYBRID-FR-01 (Fatal) — FR↔FR: XRECHNUNG profile forbidden.

8. Versioning and validation artefacts (§6.6)

fx:Version stays 1.0 even though the Factur-X spec version is 1.07.3.
Spec version is reflected in:
- XML BT-24 specification identifier (e.g. BASIC: urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic)
- Versioned validation artefacts (XSD, Schematron).
Factur-X invoices issued under earlier 1.zz versions remain valid in the latest 1.zz revision (upward compatibility).