EN 16931 accepts two XML syntaxes, and CII is the one at the heart of German e-invoicing. Cross-Industry Invoice (CII) is the UN/CEFACT syntax at the core of ZUGFeRD and XRechnung. When you issue a ZUGFeRD invoice, it is the embedded CII XML, not the PDF page, that a public authority, your B2B partner, or a system such as DATEV actually reads. Validating that XML before you send it is the surest way to avoid a rejected X-invoice or a silently dropped ZUGFeRD file.
What this CII validator checks
A CII invoice has to clear two separate layers. This validator runs both and reports them separately, so you can see precisely where an XRechnung or ZUGFeRD payload falls short.
The CII D16B XSD schema - checks the XML against the UN/CEFACT Cross-Industry Invoice D16B schema. Structural problems surface here first: missing mandatory elements, wrong data types on monetary or quantity amounts, dates that are not valid YYYYMMDD strings, and broken namespace declarations. Nothing that fails the schema can reach the business-rule stage, so this layer always runs first.
EN 16931 Schematron: the business rules - this is where most rejected invoices originate. The rules verify VAT arithmetic (BR-CO-14: the invoice total VAT must equal the sum of the VAT category amounts), VAT category logic (BR-S-08: a standard-rate line needs a rate above zero), mandatory content (BR-01: specification identifier, BR-06: seller name), and payment data (BR-61: an IBAN is required for payment means 30 or 58). Your specification identifier declares the profile, from MINIMUM to EXTENDED, and that profile decides which rules are mandatory. The XRechnung CIUS layers further German rules on top.
CII errors we see most often
These violations come up again and again on German CII XML. If your file fails, start here.
BR-01 - Missing specification identifier
The GuidelineSpecifiedDocumentContextParameter/ID element is empty or absent. Every CII invoice must name its EN 16931 profile (for example urn:cen.eu:en16931:2017, or a ZUGFeRD URN such as urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended). Without it the validator cannot pick a rule set and rejects the file at once.
BR-CO-14 - VAT total does not match the breakdown
The invoice total VAT does not equal the sum of the VAT category breakdown amounts. It usually fires when rounding between line level and header level drifts by a cent. Derive the header VAT from the breakdown rather than calculating it on its own.
BR-S-08 - Standard-rate line carries a zero rate
A line is marked VAT category S (standard rate) but shows 0%. If you really mean zero, use category Z (zero-rated) or E (exempt) instead.
BR-AE-05 - Reverse-charge line has a non-zero rate
With VAT category AE (reverse charge / Steuerschuldnerschaft des Leistungsempfangers), the rate must be exactly zero: the recipient accounts for the tax.
XSD - Wrong date format
A date carries a format other than 102, or a value that is not a valid YYYYMMDD string. CII writes dates as a DateTimeString with format 102, which is stricter than the ISO style UBL uses.
XSD - Elements in the wrong order
CII is order-sensitive: child elements must appear in exactly the sequence the schema defines. An element placed before a sibling it should follow fails the XSD even when every value is correct. This trips up almost everyone hand-writing CII.
CII, ZUGFeRD and XRechnung: how they fit together
ZUGFeRD (Germany) and Factur-X (France) are not different XML formats: each wraps the same CII XML inside a PDF/A-3 container, and XRechnung can be sent as CII too. A CII file that validates here is exactly what you embed to build a compliant ZUGFeRD PDF, or send as a standalone X-invoice. Have a standalone XML? Validate it, then embed it. Already have a ZUGFeRD PDF? Drop it here and we validate the embedded CII for you.
CII is also one of the two syntaxes Peppol BIS Billing 3.0 carries, alongside UBL, and the route many German senders use on Peppol. Validating the CII first gives you a clean source before any conversion.
The XRechnung rules on top of EN 16931
XRechnung is pure XML: there is no PDF layer, so PDF/A-3b conformance does not apply. Instead, the German CIUS (Core Invoice Usage Specification) adds national rules on top of EN 16931, and the validator enforces them whenever a file declares the XRechnung specification:
- DE-R-001 - BT-10 (Buyer reference / Leitweg-ID) is mandatory for all XRechnung invoices
- DE-R-002 - The Leitweg-ID must follow the pattern {authority-id}-{optional-suffix}-{check-digit}
- DE-R-009 - Payment means code must be one of the permitted values (30, 58, or 59)
If you are submitting to a federal or state portal (ZRE, OZG-RE), the Leitweg-ID must be obtained from the contracting authority before you issue the invoice, the validator will flag a missing or malformed ID immediately.