Choosing a profile
ZUGFeRD Extended or XRechnung: what the public sector accepts
Many invoicing products offer a dropdown with Basic, Comfort, Extended and XRechnung — and some recommend Extended. For invoices to public authorities that is the wrong choice, and the reason is checkable.
The finding
On 12 September 2026 we ran a file from a German accounting vendor’s public generator through our validator. It came back as Factur-X 1.0 EXTENDED, CII, PDF/A-3B. The result: businessRulesEvaluated: false, no matched scenario, no findings.
“No findings” does not mean “clean” here. It means nothing was checked. The official KoSIT XRechnung configuration has no scenario for the EXTENDED guideline, so the document passes through unevaluated. A sender who reads that as confirmation has switched their own control off without noticing.
That was true of any validator using the official configuration unchanged — and it was true of ours. Since 17 September 2026 it is not: NormAPI adds scenarios for Factur-X/ZUGFeRD BASIC and EXTENDED and evaluates both against the EN 16931 core. An EXTENDED file gets real findings here rather than silence. None of which changes the advice below. A public authority still will not accept an EXTENDED file, and other validators still say nothing about it.
Re-checked on 18 September 2026: the downloaded KoSIT configuration still ships no scenario for BASIC or EXTENDED — ours are added at build time. Anyone using the configuration unchanged therefore still does not check these profiles.
Why EXTENDED sits outside the rule set
It is in the document itself. Every e-invoice carries an identifier saying which rule set it was built against, and EXTENDED’s ends in #conformant#, not #compliant#. That is not an accident: EXTENDED deliberately sits outside the EN 16931 core so that it can carry fields the norm does not provide for.
In B2B that is permitted; the German mandate accepts EXTENDED between businesses. But the file is then not an XRechnung — and a public-sector invoice portal expecting one will refuse it.
The profiles, in order
ZUGFeRD and Factur-X are one format with five levels. Only three of them are invoices in the sense of EN 16931 at all — and that decides whether a validator has anything to say.
| Profile | An EN 16931 invoice? | What the validator says |
|---|---|---|
| MINIMUM | No | No scenario, no rule runs. The result is “not checked”, not “clean”. |
| BASIC WL | No | The same — a header-only invoice without lines is not an invoice under the norm. |
| BASIC | Yes | Checked against the EN 16931 core. The official KoSIT configuration ships no scenario for it; NormAPI added one. |
| EN 16931 (Comfort) | Yes | The core of the norm itself. Evaluated in full everywhere. |
| EXTENDED | An extension (#conformant#) | Checked here against the EN 16931 core. With an unmodified configuration elsewhere: silence. |
What to choose
| Recipient | Choose | Why |
|---|---|---|
| Public authority (B2G) | XRechnung | The only thing a public-sector portal reliably accepts, and the only one the German validator evaluates in full. |
| Business (B2B) | ZUGFeRD EN 16931 (Comfort) | Matches the core of the norm and is therefore checkable. The recipient can process it automatically without knowing your extra fields. |
| Large partner, by agreement | Extended | Only where the recipient explicitly asks for it and actually reads the extra fields. Expect no standard validator to tell you anything about it. |
How to see what you actually send
Not by the label in the dropdown — that is the vendor’s wording. Open the XML and read the specification identifier (BT-24): cbc:CustomizationID in UBL, ram:GuidelineSpecifiedDocumentContextParameter/ram:ID in CII.
<!-- XRechnung 3.0 -->
urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0
<!-- plain EN 16931 -->
urn:cen.eu:en16931:2017If it says #conformant# rather than #compliant#, you are sending an extension and not an XRechnung. If the identifier is missing entirely, the validator reports BR-01.
Common questions
Is ZUGFeRD or XRechnung better?
The question only has an answer once you name the recipient. To a public authority: XRechnung, because the portal reliably accepts nothing else. To a business: ZUGFeRD in the EN 16931 profile, because the same data set also carries a readable PDF. Neither is better — they are two wrappings of the same EN 16931 core, and the choice only decides who can read the file.
Which version of ZUGFeRD is current?
ZUGFeRD 2.5.2, published on 4 August 2026 by FeRD — Factur-X 1.09.2 is the same release under its French name. What decides validation is not the version number but the profile identifier inside the document: the #compliant# or #conformant# line described above. A file from an older 2.x generator does not fail because of its version, but because of its profile, if that is the wrong one.
Check an invoice your system produces today — the report names the format, the profile and the rule-set version it was checked against, and says explicitly when it could not be checked.