ZUGFeRD 2.3.2 / Factur-X 1.07.2

June 10, 2026 · View on GitHub

Source: docs/2.3.2/Documentation/1. FACTUR-X 1.07.2 EN.pdf (Factur-X Specification 1.07.2, dated 2024-11-15; ZUGFeRD 2.3.2 == Factur-X 1.07.2).

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

Headline diff vs 2.3.3 / 2.4: this is the spec version that introduced the BR-HYBRID-* business-rule block (change history entry for 2024-11-15: "Addition of management rules and code lists dedicated to HYBRID documents"). The PDF-carrier prose (§§6.1–6.6) is unchanged from 1.07.3 and 1.08, and the BR-HYBRID rule text is identical to the 1.08 rendering — confirmed by direct comparison of the textual tables in 1.07.2 and 1.08.


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). (§6.2.)
  • xrechnung.xml when the XRECHNUNG reference profile is used.
  • BR-HYBRID-13 (Fatal): embedded file name SHALL be a value from HybridDocumentFilename.
  • BR-HYBRID-14 (Warning): embedded file name SHOULD match fx:DocumentFileName.

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. (§6.2.)
  • 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 are permitted.
  • The XML SHALL be registered as an Associated File at document level: /AF array on the document catalogue. (§6.2.1.)
  • BR-HYBRID-12 (Fatal): embedding method SHALL conform to the specification (extractability).

2.4 AFRelationship matrix (§6.2.2)

ProfileFranceGermany
MINIMUMDataData
BASIC WLDataData
BASICAlternative, Source, DataAlternative
EN 16931Alternative, Source, DataAlternative
EXTENDEDAlternative, Source, DataAlternative
XRECHNUNGn/aAlternative

Semantics — same as 2.4: Data (PDF richer than XML), Source (XML generated the PDF), Alternative (equivalent representations). BR-HYBRID-11 (Warning) — /AFRelationship SHOULD follow this table.


3. PDF/A XMP extension schema (Factur-X 1.0)

PropertyValue
Extension schema nameFactur-X PDFA Extension Schema
URI (namespace)urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#
Schema prefixfx

Notes (§6.3.1):

  • Trailing # is required.
  • 1p0 in the URI is the extension-schema version, not the spec version (which is 1.07.2 here).
  • The extension schema definition SHALL be embedded in the XMP packet.

Inconsistency: BR-HYBRID-04 (Fatal) lists the URI as urn:factur-x:pdfa:CrossIndustryDocument:1p0# (no :invoice), while §6.3.1 and the worked examples use …:invoice:1p0#. §6.3.1 is authoritative for instances; the rule text appears to be a transcription error carried unchanged into 1.07.3 and 1.08.

XMP fields under the fx: namespace

FieldDescriptionExample
fx:DocumentTypeAlways INVOICE (HybridDocumentType list, BR-HYBRID-06 Fatal).INVOICE
fx:DocumentFileNameFile name of embedded invoice XML, fixed to factur-x.xml / xrechnung.xml (HybridDocumentFilename list, BR-HYBRID-08 Fatal). SHALL match the /F key of the file specification dictionary; SHOULD match the embedded file name (BR-HYBRID-14).factur-x.xml
fx:VersionVersion of the XMP extension schema (HybridDocumentVersion list, BR-HYBRID-09 Fatal). BR-HYBRID-10 (Warning) — SHOULD be 1.0.1.0
fx:ConformanceLevelProfile of the structured XML: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG (HybridConformanceType list, BR-HYBRID-07 Fatal). BR-HYBRID-15 (Warning) — SHOULD match XML profile.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>

Legacy: ZUGFeRD 2.0 extension schema (§6.3.2)

Still tolerated ("marked as deprecated, … may change in future"):

PropertyValue
Extension schema nameZUGFeRD PDF/A Extension Schema
URIurn:zugferd:pdfa:CrossIndustryDocument:invoice:1p0#
Schema prefixzf
zf:DocumentTypeINVOICE
zf:DocumentFileNameFixed zugferd-invoice.xml
zf:Version2p0
zf:ConformanceLevelOne 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 extra XMP metadata for non-invoice attachments.
  • Reserved names for alternative representations:
    • EDIFACT → factur-xedifact.edi (TXT file)
    • UBL → factur-xubl.xml

5. Visual representation and securing

  • §3 principles 2 and 4: PDF carries all info; XML may be a subset except in DE; issuer ensures consistency.
  • §5.2 single-page / multi-page good-practice layouts — recommendations only.
  • §6.5 profile logos may be added (optional).
  • §4 security: qualified electronic signature/seal or documented reliable audit trail.

6. Hybrid Business Rules — full table (§3.d, page 84)

Identical wording to the 1.08 table; reproduced here as a check that the rule block already existed in this spec.

IDLevelRuleCountry
BR-HYBRID-01InfoHybrid = machine-readable XML + human-readable PDF envelope.FR + DE
BR-HYBRID-02FatalPDF envelope SHALL use PDF/A-3. Optionally a PDF/A-4f file is allowed.FR + DE
BR-HYBRID-03FatalPDF/A extension schema (XMP) following the prescribed structure SHALL be used.FR + DE
BR-HYBRID-04FatalExtension schema URI SHALL be urn:factur-x:pdfa:CrossIndustryDocument:1p0# (see note in §3 — §6.3.1 uses the longer …:invoice:1p0#).FR + DE
BR-HYBRID-05FatalSchema namespace prefix SHALL be fx.FR + DE
BR-HYBRID-06Fatalfx:DocumentType value SHALL be from HybridDocumentType.FR + DE
BR-HYBRID-07Fatalfx:ConformanceLevel value SHALL be from HybridConformanceType.FR + DE
BR-HYBRID-08Fatalfx:DocumentFileName value SHALL be from HybridDocumentFilename.FR + DE
BR-HYBRID-09Fatalfx:Version value SHALL be from HybridDocumentVersion.FR + DE
BR-HYBRID-10Warningfx:Version SHOULD be 1.0.FR + DE
BR-HYBRID-11Warning/AFRelationship SHOULD follow the profile × country matrix.FR + DE
BR-HYBRID-12FatalXML embedding method SHALL conform to this specification (extractability).FR + DE
BR-HYBRID-13FatalEmbedded file name SHALL be from HybridDocumentFilename.FR + DE
BR-HYBRID-14WarningEmbedded file name SHOULD match fx:DocumentFileName.FR + DE
BR-HYBRID-15Warningfx:ConformanceLevel SHOULD match the embedded XML profile.FR + DE
BR-HYBRID-DE-01FatalDE↔DE: MINIMUM profile SHALL NOT be used.DE
BR-HYBRID-DE-02FatalDE↔DE: BASIC WL profile SHALL NOT be used.DE
BR-HYBRID-FR-01FatalFR↔FR: XRECHNUNG profile SHALL NOT be used.FR
BR-FX-DE-01FatalDE: supporting docs for place/time/kind SHALL be in BG-24; PDF text / attached file / external doc is not sufficient. (No technical check possible.)DE
BR-FX-DE-02FatalDE: main services SHALL be detailed in the XML; only ancillary services may be in supporting docs. (No technical check possible.)DE
BR-FX-DE-03WarningDE↔DE: from 2025-01-01 the XML is the invoice. If XML is valid and extractable, PDF/A technical errors downgrade from Fatal to Warning.DE

7. Versioning and validation artefacts (§6.6)

  • fx:Version stays 1.0 despite the spec being 1.07.2.
  • Spec version in XML BT-24 and in versioned validation artefacts.
  • Upward compatibility: invoices issued under earlier 1.zz versions remain valid in 1.07.2.