ZUGFeRD: the hybrid PDF/A-3 e-invoice format explained

ZUGFeRD is a hybrid e-invoice: a PDF/A-3 file that a person can read, with an XML invoice in UN/CEFACT Cross Industry Invoice (CII) syntax embedded inside it for machines. It is maintained by FeRD, the Forum elektronische Rechnung Deutschland, and is technically identical to the French Factur-X. From version 2.0.1 the profiles BASIC, EN 16931, EXTENDED and XRECHNUNG are e-invoices under § 14 UStG; MINIMUM and BASIC WL are not. The current release is ZUGFeRD 2.5.2 of 4 August 2026.

How does a ZUGFeRD invoice work?

A ZUGFeRD file is one PDF that carries two representations of the same invoice. The visible pages are the invoice as the issuer designed it. Attached to the PDF, as an embedded file under the PDF/A-3 rules (ISO 19005-3), is an XML document — factur-x.xml in current versions, zugferd-invoice.xml in older ones — that contains the invoice data structured according to EN 16931 in CII syntax. PDF metadata (XMP) declares the ZUGFeRD version and profile so that a receiving system can find and read the XML without opening the pages.

The legal invoice is the XML. Since 1 January 2025 the German tax administration treats the structured part as the decisive one: if the PDF pages show data that deviate from the XML, the PDF may be treated as a second invoice with the consequences of § 14c UStG, and input VAT can only be deducted from the structured part (UStAE 14c.1 Abs. 4a). Minor technical differences such as rounding or a shortened description in the PDF are tolerated. Under the GoBD as amended on 14 July 2025, archiving the XML part is sufficient; the PDF part must be kept in addition only if it contains extra tax-relevant information, for example booking notes. The general German rules are on the Germany hub.

What are the ZUGFeRD profiles?

A profile defines how much of the EN 16931 data model the XML must contain. Six exist:

The BMF letter of 15 October 2025 writes into UStAE 14.1 Abs. 14 that ZUGFeRD from version 2.0.1, excluding MINIMUM and BASIC WL, is based on EN 16931 and therefore a permitted e-invoice format. FeRD's own FAQ says the same in its terms: BASIC, EN 16931 and EXTENDED are recognised as complete invoices, while MINIMUM and BASIC WL do not produce UStG-conformant invoices. The profile is declared in the XML's ram:GuidelineSpecifiedDocumentContextParameter (BT-24), for example urn:cen.eu:en16931:2017 for the EN 16931 profile.

Which versions exist, and which is current?

ZUGFeRD 2.5.2 is current. FeRD's version archive and news pages give the following history:

FeRD announces a further release for autumn 2026 with support for gross-price invoices and more functions from the revised EN 16931. Older versions remain valid invoices as long as they are EN 16931-conformant; the law refers to the norm, not to a ZUGFeRD version number, so a 2.3.3 file issued today is still an e-invoice. Which version your counterpart's software can read is a separate, practical question.

Is ZUGFeRD the same as Factur-X?

Yes. Since 24 March 2020 (ZUGFeRD 2.1 and Factur-X 1.0), FeRD and its French counterpart FNFE-MPE publish one specification under two names; the XML, the profiles and the embedded file name factur-x.xml are shared, and each release is issued jointly (ZUGFeRD 2.4 with Factur-X 1.08, ZUGFeRD 2.5.2 with Factur-X 1.09.2). A ZUGFeRD file produced in Germany is a Factur-X file for a French recipient and vice versa. The French side is described at Factur-X; note that France additionally requires transmission through approved platforms from September 2026, which the format alone does not cover.

Is ZUGFeRD accepted by public authorities?

Partly. Directive 2014/55/EU obliges public buyers to accept EN 16931 invoices in the listed syntaxes, and CII is one of them. The federal receipt platform states that it accepts XRechnung and other EN 16931-conformant formats, naming ZUGFeRD 2.2.0 as an example. Many federal and state receivers nevertheless require the XRechnung CIUS specifically — the mandatory buyer reference with the Leitweg-ID, the XRechnung specification identifier and the German rules. The XRECHNUNG profile of ZUGFeRD exists for exactly this: its XML passes the XRechnung validator while the PDF remains for people. Whether a given authority accepts a hybrid file or wants the bare XML is the authority's decision; the safe route to public buyers is described on the XRechnung page, and the comparison at XRechnung vs ZUGFeRD.

How do I validate a ZUGFeRD file?

Two checks are needed, because two things can be wrong:

1. The container. The PDF must be a valid PDF/A-3 with the XML attached with the correct relationship and the XMP metadata declaring version and profile. Tools such as veraPDF check PDF/A conformance.
2. The XML. Extract the embedded file and validate it against the CII schema and the EN 16931 Schematron rules for the declared profile; FeRD ships XSD and Schematron for every profile since 2.4. For the XRECHNUNG profile, run the KoSIT validator as well.

The free e-invoice checker does both steps for an uploaded ZUGFeRD or Factur-X file without storing it. Keep the validation report: the BMF recommends it as evidence that you exercised ordinary commercial care.

How KRONENWERK handles this

SUPPORTED KRONENWERK generates ZUGFeRD invoices for German companies as PDF/A-3 with embedded CII XML in an EN 16931-conformant profile, and validates each file at issuance against the EN 16931 rules, cross-checked with the Mustang library; a file that fails is not issued. The same generator produces Factur-X for French companies. Incoming ZUGFeRD and Factur-X files are read into bills and the XML original is kept unchanged for retention. The tax verdict per invoice is derived from the transaction's facts and the buyer's VAT ID is checked against VIES at issuance. Delivery is by e-mail or download, which is all German B2B law requires; see the e-invoicing product page. KRONENWERK does not give tax advice: whether a particular counterparty may still receive a non-conformant profile during the transition period requires professional confirmation.