W System / Blog / Factur-X / ZUGFeRD EXTENDED validation: why EN 16931 validators flag CII-SR and CII-DT rules

Factur-X / ZUGFeRD EXTENDED validation: why EN 16931 validators flag CII-SR and CII-DT rules

By Zifeng Wei, W System · Published 9 November 2026 · All articles

In short: a correct Factur-X / ZUGFeRD EXTENDED invoice often fails a plain EN 16931 validator with errors like CII-DT-027 FormattedIssueDateTime should not be present. Those CII-SR-* and CII-DT-* rules belong to the EN 16931 CII syntax binding: they forbid elements the core standard does not use, and EXTENDED is allowed to use them. The fix is a profile-aware check: read the guideline ID (BT-24), treat syntax restrictions as warnings for EXTENDED, keep the EN 16931 business rules (BR-*) as errors, and run the EXTENDED schematron from the official release package if you need full conformance.

The five Factur-X / ZUGFeRD profiles

Profile	Guideline ID (BT-24)	Relation to EN 16931
MINIMUM	`urn:factur-x.eu:1p0:minimum`	Not an EN 16931 invoice; booking aid only.
BASIC WL	`urn:factur-x.eu:1p0:basicwl`	Not an EN 16931 invoice; no lines.
BASIC	`urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic`	Subset of EN 16931 (CIUS).
EN 16931 (COMFORT)	`urn:cen.eu:en16931:2017`	The core standard.
EXTENDED	`urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended`	EN 16931 plus extra fields (extension).

The identifiers are the same in Factur-X 1.07 and 1.08 / ZUGFeRD 2.3 and 2.4. ZUGFeRD 2.4 / Factur-X 1.08 applies from 15 January 2026, is based on UN/CEFACT CII D22B (backward compatible with D16B) and ships its own XSD and schematron for each profile; FeRD says new EXTENDED elements were added for the French B2B reform. In Germany and France, MINIMUM and BASIC WL are not valid B2B e-invoices on their own; EXTENDED is an EN 16931 invoice with extra data.

Where the false errors come from

The CEN validation artefacts for EN 16931 have two layers for CII files. The business rules (BR-01, BR-CO-10, BR-S-08 and so on) check the meaning of the invoice: totals, VAT breakdown, mandatory parties. The syntax binding rules (CII-SR-*, CII-DT-*) check that the XML only uses the part of CII that EN 16931 maps to business terms. Many CII-SR rules are warnings already; some CII-DT rules are errors.

EXTENDED uses more of CII on purpose, for example a delivery note date on a line (DeliveryNoteReferencedDocument/FormattedIssueDateTime), extra party roles or several deliveries. Run the EN 16931 schematron alone on such a file and the syntax binding reports those elements, often as errors. Validators that pick the profile's own artefacts (the open-source Mustang project is one) accept such files. That mismatch is what invoicing and ERP builders run into when they compare tools.

What a profile-aware check should do

Read BT-24 first. #conformant#urn:factur-x.eu:1p0:extended means EXTENDED; plain urn:cen.eu:en16931:2017 means COMFORT. A wrong declaration gives wrong results in every validator.
For EXTENDED, downgrade CII-SR-* and CII-DT-* to warnings and keep the message, so people can still see which elements go beyond EN 16931.
Keep the business rules as errors. An EXTENDED invoice with wrong totals or a missing VAT breakdown is still wrong.
Check the XML schema. Unknown elements or the wrong order are real errors for every profile.
For full EXTENDED conformance, run the EXTENDED schematron from the FeRD / FNFE-MPE package of the version you produce.
Remember the receiver. A buyer whose system only reads EN 16931 ignores the extra fields; put anything they must see in EN 16931 fields too.

Example on the live API

Disclosure: W System, which publishes this page, makes the API used below. POST /einvoice/validate accepts CII XML or a Factur-X / ZUGFeRD PDF and runs the XML schema plus the official EN 16931 rules (and KoSIT XRechnung rules for XRechnung). Since 9 November 2026 it is profile-aware for EXTENDED: CII-SR-* and CII-DT-* errors become warnings with a profile_note, and BR-* business rules stay errors. The change came from a German ERP builder who reported that our results disagreed with an EXTENDED-aware validator. It does not run the EXTENDED schematron.

curl -X POST https://api.wsystem.dev/einvoice/validate \
  -H 'Content-Type: application/xml' --data-binary @factur-x.xml

On 9 November 2026 we sent the same CII invoice with a delivery note date on a line twice. Declared as EXTENDED it came back "valid": true with two warnings, including this one (location shortened):

{
 "rule_id": "CII-DT-027",
 "severity": "warning",
 "ruleset": "EN16931",
 "message": "FormattedIssueDateTime should not be present",
 "profile_note": "Allowed in Factur-X/ZUGFeRD EXTENDED; an error only for EN 16931 (COMFORT) and stricter profiles."
}

Declared as plain EN 16931, the same file came back "valid": false with CII-DT-027 as an error, which is correct for that profile. You can also drop the PDF or XML into the free e-invoice validator in the browser, or turn incoming files into JSON with the parse endpoint. Free for 20 calls a day per IP without a key; a free API key gives 500 units a month, no card.

Questions and answers

Why does my Factur-X EXTENDED invoice fail an EN 16931 validator?

The CEN validation artefacts for EN 16931 include a CII syntax binding with rules named CII-SR-* and CII-DT-*. They say which CII elements must not appear in an EN 16931 invoice (messages like 'FormattedIssueDateTime should not be present'). EXTENDED deliberately allows many of those elements, so a validator that applies only the EN 16931 rules reports them as errors even though the file is correct for its profile.

Are CII-SR and CII-DT errors safe to ignore for EXTENDED?

Usually, when the element is one EXTENDED defines and you declared EXTENDED in the guideline ID (BT-24). They are not safe to ignore for EN 16931 (COMFORT), BASIC or XRechnung files, and the EN 16931 business rules (BR-*, BR-CO-*, BR-S-* and so on) still apply to EXTENDED. To be sure an EXTENDED-only element is used correctly, also run the EXTENDED schematron from the FeRD / FNFE-MPE release package.

What is the difference between #compliant# and #conformant# in the guideline ID?

#compliant# marks a restriction of EN 16931 (a CIUS, such as BASIC or XRechnung): no new fields. #conformant# marks an extension: everything in EN 16931 plus extra fields, which is how EXTENDED is declared. Validators use this value to decide which rules apply, so a wrong guideline ID gives wrong results.

Do I need EXTENDED at all?

Only when a recipient needs a field EN 16931 does not have, for example extra party roles, several deliveries or richer logistics and contract references. Multiple VAT rates, allowances and charges, credit notes and foreign currency all work in EN 16931 (COMFORT). Receivers that only process EN 16931 will ignore the extra fields.

How does the W System API treat EXTENDED files?

When the guideline ID declares EXTENDED, CII-SR-* and CII-DT-* errors from the EN 16931 rules come back as warnings with a profile_note, the response has a note explaining it, and BR-* business rules stay errors. The EXTENDED schematron itself is not run, so this is a check of the EN 16931 core of the file, not a full EXTENDED conformance test.

Sources

Checked against the FeRD ZUGFeRD 2.4 release notes and live API responses on 9 November 2026. Not affiliated with FeRD, FNFE-MPE, CEN or the Mustang project.

Facts checked 2026-11-09. W System is the maker of this product. Not affiliated with the European Commission. Not legal or tax advice.