The ZUGFeRD and Factur-X profiles explained, from MINIMUM to EXTENDED

A ZUGFeRD or Factur-X file is a PDF/A-3 with an embedded XML invoice. The profile says how much of the invoice the XML carries. It is the first thing a recipient's software looks at, and the first thing a validator checks, because the rules that apply depend on it.

One specification, two names

ZUGFeRD is published by FeRD in Germany, Factur-X by FNFE-MPE in France. Since ZUGFeRD 2.0 they have been the same technical specification, released together: the same profiles, the same XML schema (UN/CEFACT CII), the same rules. A file that is valid Factur-X is valid ZUGFeRD and the other way round. The profile identifier inside the file uses the urn:factur-x.eu:1p0: namespace for both; older ZUGFeRD 2.0 files used urn:zugferd.de:2p0: identifiers, which validators still recognise.

The profile is declared twice: in the PDF's XMP metadata (the fx:ConformanceLevel field) and in the XML itself (the specification identifier, business term BT-24). The two must agree. A mismatch is one of the container findings the ZUGFeRD validator reports before it even validates the XML.

The six profiles

Profile	What the XML contains	E-invoice under EN 16931?
MINIMUM	Buyer, seller, totals, VAT total, invoice number and date. No lines.	No: it is a booking aid, not a full invoice.
BASIC WL	Header data with VAT breakdown and payment terms, still no invoice lines ("without lines").	No: an invoice without lines is not a core invoice.
BASIC	Lines with the essential data, a subset of the EN 16931 core.	Yes: a compliant subset of the core invoice.
EN 16931 (formerly COMFORT)	The complete core invoice of the European norm.	Yes: the reference profile.
EXTENDED	The core plus extensions (several deliveries, complex allowances, packaging, industry data).	Yes, as an extension of the norm; recipients must support the extra data.
XRECHNUNG	A hybrid PDF whose XML follows the German XRechnung rules.	Yes: it is an XRechnung in a PDF envelope.

MINIMUM and BASIC WL exist for legacy uses: a scanning line that wants a few structured fields, or a country where the PDF stays the legal invoice and the XML is a convenience. In Germany, the Federal Ministry of Finance (BMF letter of 15 October 2024) states that these two profiles do not fulfil the requirements of an e-invoice under § 14 UStG, because they do not carry the full invoice data. From BASIC upwards, a ZUGFeRD invoice is an e-invoice in the legal sense.

What a validator checks per profile

Each profile has its own XML schema (which elements may appear) and its own Schematron rules (what the values must satisfy). The rules of the EN 16931 profile are the CEN rules of the norm plus a few Factur-X structural checks; BASIC uses a subset; EXTENDED allows more elements; XRECHNUNG applies the KoSIT rules. A validator therefore does three things: it reads the profile, applies the matching schema, then the matching rules. An invoice that declares the EN 16931 profile but omits the seller's VAT identifier fails the norm's rule BR-CO-09 or BR-DE-16, depending on the rule set. The Factur-X validator reports those rule ids, each with its explanation on this site.

The PDF container has rules too: the file must be PDF/A-3 (ISO 19005-3), the XML must be embedded under its prescribed name (factur-x.xml, zugferd-invoice.xml for the old naming, xrechnung.xml for the XRECHNUNG profile), with an AFRelationship that says what it is, and the XMP metadata must name the profile. A perfectly valid XML in a non-conforming PDF is still a rejected invoice at many recipients.

Which profile to choose

• Default: EN 16931. It is what every recipient's software expects, what public bodies accept when they accept ZUGFeRD, and what the norm's business rules are written for.
• When your customer needs data beyond the core (industry, several deliveries per invoice, detailed packaging): EXTENDED, after checking that the customer's software reads it.
• When the customer is a German public body: XRECHNUNG, with the Leitweg-ID, or a plain XRechnung XML.
• BASIC only when your software cannot produce more; MINIMUM and BASIC WL only when the recipient explicitly asks for them and accepts that the PDF is the invoice.

Before sending, open the file in the Factur-X viewer to see what the XML really says, then validate it. Many "the PDF looks right" invoices carry an XML from an older template.

Sources

• FeRD, ZUGFeRD specification and profiles: ferd-net.de
• FNFE-MPE, Factur-X specification: fnfe-mpe.org/factur-x
• BMF letter of 15 October 2024 on the e-invoice, section on admissible formats, and the BMF FAQ: bundesfinanzministerium.de
• ISO 19005-3 (PDF/A-3): iso.org
• CEN, EN 16931 core invoice model: cen.eu