Why e-invoice validators give different results
Most of the time the validators apply different validation rules: different severities, different versions or a different selection of rules. This page shows five causes, each backed by the published rule files.
Last updated
| KoSIT validation rules for XRechnung | XRechnung 3.0.2, as of Aug 31, 2026: CEN rules 1.3.16, XRechnung rules 2.6.0 |
|---|---|
| Validation rules for ZUGFeRD and Factur-X | ZUGFeRD 2.5.2 / Factur-X 1.09.2, valid from Sep 1, 2026 |
| Peppol BIS Billing | Version 3.0.21, mandatory since Aug 17, 2026 |
Exactly one scenario, or the file is rejected
XRechnung invoices are checked by the KoSIT validator, the validation program of the Coordination Office for IT Standards (KoSIT). Its configuration assigns each invoice type to a scenario, a fixed group of validation rules such as “XRechnung in CII”. The current configuration has 8 scenarios for XRechnung 3.0 and 3 for plain EN 16931. The XRechnung scenarios cover Standard, Extension and CVD (data on clean road vehicles), each in UBL and CII.
The KoSIT validator selects the scenario by the invoice's specification identifier (BT-24), which must match exactly. If exactly one scenario matches, it is applied. If none or several match, the validator rejects the file (source code).
That is why it rejects an invoice with the older identifier
urn:xeinkauf.de:kosit:xrechnung_2.3, even if every field is correct. A
validator that picks its rules only by the word “xrechnung” in the identifier
reports “valid” for the same file.
KoSIT changes the severity of EN 16931 rules
CEN publishes the EN 16931 rules as Schematron, a language for validation
rules in XML. There, each rule has a fixed severity, error or warning. KoSIT
adopts these rules, but its configuration sets a different severity for
individual rules per scenario (the customLevel entry). Only messages with the
severity error lead to rejection.
The current configuration contains 56 such entries, all in the XRechnung scenarios:
| Rule | What it covers | CEN | KoSIT | Applies to |
|---|---|---|---|---|
| BR-CL-23 | Unit of measure per UN/ECE Rec. 20/21 (BT-130, BT-150) | error | warning | all |
| BR-CL-21 | Scheme of the item identifier (BT-157) | error | warning, info in Extension | all |
| BR-CL-13 | Scheme of the item classification (BT-158) | error | info | CVD |
| BR-CL-10, -11, -24, -25, -26 | Code lists for identifier schemes and MIME types | error | info | Extension |
| BR-CO-16 | Amount due, opened up for third-party payments | error | info | Extension (UBL) |
| UBL-CR-646 | Sub-invoice lines (SubInvoiceLine) | warning | error, info in Extension | UBL invoice, UBL CVD, Extension (UBL) |
| UBL-CR-470 | Prepayment (PrepaidPayment) | warning | info | Extension (UBL) |
| CII-SR-452, -453 | only one block or one description of the payment terms | warning | error | CII |
| CII-SR-454 | only one tax entry per line | warning | error | CII |
| CII-SR-465, -466 | only one seller contact (BT-41) or buyer contact (BT-56) | warning | error | CII |
| CII-SR-475, -476 | faulty context at CEN, replaced by BR-TMP-4 and -5 | warning | info | CII |
Two examples. The unit of measure “Stk” is in neither of the two code lists: under CEN that is an error, the KoSIT validator reports a warning (BR-CL-23). Conversely, a CII seller contact with a person's name and a department name carries two contact entries: a warning under CEN, an error at KoSIT (CII-SR-465). A validator without this table reaches the opposite result in both cases.
Rule versions change
KoSIT publishes new configurations under the same XRechnung version. The one from Aug 31, 2026, for example, raised CII-SR-465 and -466 from warning to error. Two validators that both state “XRechnung 3.0.2” can therefore apply different rule versions.
For Peppol, the change is tied to a date: Peppol BIS Billing 3.0.21 has applied since Aug 17, 2026. The test bench shows which versions invowerk applies and since when.
One rule, two syntaxes, two tolerances
CEN publishes its rules as a separate file per syntax, and they do not calculate the same way everywhere (CEN rules 1.3.16):
| Rule | UBL | CII |
|---|---|---|
| BR-S-08: taxable amount per tax rate = sum of the lines, allowances and charges | deviation below 1.00 allowed | exactly equal to the sum rounded to two decimals |
| BR-CO-17: tax amount = taxable amount × tax rate | deviation below 1.00 allowed | deviation up to and including 1.00 allowed |
An invoice can therefore be valid as UBL and fail after conversion to CII, although no amount has changed (BR-S-08). The validator then correctly applies the rule of the respective syntax.
ZUGFeRD: rules for invoices between German parties
Some rules of ZUGFeRD 2.5.2 depend on where the invoice issuer and the invoice recipient are based (BT-40, BT-55). A validator that does not read the countries reaches a different result for domestic invoices.
- If the PDF is not a valid PDF/A, that is an error in principle (BR-HYBRID-02). If both parties are based in Germany and the embedded invoice data is valid, it is only a warning (BR-FX-DE-03). Errors in the embedding itself remain errors.
- Between two German parties, the MINIMUM and BASIC WL profiles are an error (BR-HYBRID-DE-01, BR-HYBRID-DE-02). This matches the German Federal Ministry of Finance (BMF): these profiles are not among the permitted e-invoice formats (UStAE 14.1 para. 14 sentence 4). Without the country check, a validator reports “valid” for the same file.
How invowerk handles this
invowerk applies these rules. For XRechnung, the result of the KoSIT validator applies as soon as it has answered. invowerk's own check uses the same scenarios and severity changes and explains the messages. If it differs, or if the KoSIT validator cannot be reached, the result says so. invowerk checks ZUGFeRD and Factur-X against FeRD's validation rules for the respective profile, including the country rules.
For four of the five causes, test files with their expected results are available. Use them to compare any validator, invowerk included: open the test bench.
FAQ
- Which e-invoice validator is the strictest?
- More messages do not mean more accuracy. A validator that reports more errors often applies the CEN severities without the KoSIT changes. A better measure is whether a tool applies the current rule version in full and proves it with test files.