Docs / Electronic invoicing in Germany (XRechnung)

Electronic invoicing in Germany (XRechnung)

Status as of 27/07/2026: UBL generation available (Story 13.2) and hybrid ZUGFeRD/XRechnung reading already functional (measured, not modified). No native XRechnung schematron rule pack to date — see the limits below.

What the regulation says

Germany is progressively mandating (2027-2028 mandate) structured electronic invoicing, with XRechnung as a specialization of EN 16931 — available in CII or UBL serialization, and often distributed in the hybrid PDF+XML form inherited from ZUGFeRD (the German counterpart of Factur-X: the two standards share the same technical CII implementation since ZUGFeRD 2.x).

What Heartwood covers today

  • UBL 2.1 generation in the xrechnung variant (POST /v1/generate/ubl?variant=xrechnung) — same EN 16931 pivot model as the other UBL variants (fr-socle, peppol-bis). The cbc:CustomizationID emitted is the actual identifier published by KoSIT: urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0.
  • Extraction of a hybrid ZUGFeRD/XRechnung PDF (POST /v1/extract): already functional with no code change. Measured on 27/07/2026 by downloading an official test PDF (validXRechnung.pdf, the mustangproject/ZUGFeRD project, Apache License 2.0) and passing it as-is through pdf.ExtractCII then codec.DecodeCII: both succeeded on the first try. Reason: since the ZUGFeRD 2.x/Factur-X 1.0 harmonization, both standards embed their CII under the same attachment name (factur-x.xml), and Heartwood's CII decoding is generic — it never filters on the content of GuidelineSpecifiedDocumentContextParameter/ID (which distinguishes Factur-X from ZUGFeRD/XRechnung). A non-regression test locks in this capability (TestExtractHandlerFromZUGFeRDXRechnungHybridPDF).
  • Conversion CII↔UBL (POST /v1/convert) and standalone UBL extraction — same paths as for Factur-X/Peppol BIS.

Known limits

  • No native XRechnung schematron rule pack: POST /v1/validate can check an xrechnung document against the OASIS UBL 2.1 XSD schema and the generic EN 16931 schematron (ubl-en16931-1.4.0), but not against the rules additional and specific to XRechnung (structuring of German public-sector recipient identifiers "Leitweg-ID", KoSIT- specific code list restrictions). This is therefore not an XRechnung certification — the same gap already documented for Peppol BIS before Story 13.1.
  • ZUGFeRD is only verified on extraction, not on generation: Heartwood does not produce a hybrid PDF carrying its own ZUGFeRD/ XRechnung profile (POST /v1/generate/facturx remains a French Factur-X profile) — only the UBL xrechnung variant is generated. A need for a native German hybrid PDF would have to be modeled separately (core.Profile today only carries EN16931/EXTENDED-CTC-FR/ PEPPOL-BIS).
  • [ASSUMPTION]: the fr-socle, peppol-bis and xrechnung variants today share exactly the same core set of modeled fields (core.Invoice) — no rule specific to XRechnung is distinguished yet on the generation side.
  • The ZUGFeRD measurement above covers a single test file, not a complete KoSIT corpus — cf. rulepacks/README.md ("What is NOT yet covered") for the same observation applied to the French rule packs.