Validate XRechnung: KoSIT Validator, Schematron errors and what they mean

The KoSIT Validator is the reference software with which you can check whether an XRechnung is actually compliant with standards before it reaches the recipient or is rejected by a public procurement body. It combines validation against the XML Schema with Schematron rules from the XRechnung specification and reports both structural errors and substantive violations against invoice logic. Anyone generating XRechnungen from their own invoicing or from an automation workflow should plan this validation firmly before sending, not only when an invoice comes back. As of: August 2026.

What does the KoSIT Validator actually check?

The KoSIT Validator performs several steps according to its own documentation: It recognizes the XML format present, validates the file against XML Schema and Schematron rules, generates an individual report from it and calculates an acceptance status. The actual validation rules are not provided by the Validator itself, but by a separate configuration, the so-called scenario file. For XRechnung, this is taken over by the XRechnung Validator configuration, which bundles Schematron rules from EN16931 and the German CIUS extension XRechnung as well as the appropriate XML schemas for UBL and UN/CEFACT invoices. Without this configuration, the Validator checks nothing at all; it is deliberately built as a generic tool.

How do you start a validation via the command line?

You call the Validator as a Java program and pass it the scenario configuration as well as the file to be validated. In practice, this means:

• Call: java -jar validator-Version-standalone.jar -s Szenario-Konfigurationsdatei -r Repository-Pfad Dateiname, optionally with additional parameters.
• Help: The parameter --help shows all available options directly in the terminal.
• Alternatives: The Validator can also be embedded as a Java library in your own software or operated in daemon mode with HTTP interface, via the parameter -D.

For an automation workflow, daemon mode is particularly interesting because the validation can then be integrated into a pipeline via HTTP call, instead of starting a new process each time.

What distinguishes Schema errors from Schematron errors?

A Schema error means that the XML file does not conform to the prescribed structure, for example a mandatory field is completely missing or an element is in the wrong place. These are usually hard technical errors that must be fixed before any substantive validation. A Schematron error, on the other hand, means that the file is structurally valid but violates a business rule in the XRechnung specification, such as a sum that does not add up or a tax rate that does not match the chosen category. Both error types end up in the same XML report and flow together into the final acceptance status that the Validator outputs at the end.

How can validation before sending be automated?

The most reliable is validation that runs automatically before an invoice ever leaves the office. In an n8n workflow, this can be implemented so that the generated XRechnung XML is sent via HTTP request to a running Validator instance in daemon mode and the returned report is evaluated before the sending step even starts. If validation fails, the workflow aborts and reports the error to accounting instead of sending an invalid invoice. Exactly such upstream validation and approval steps are among the automations that we at NordFlux set up for clients with their own invoicing.

Frequently asked questions about validating XRechnung

Is validation with the KoSIT Validator sufficient as the only control before sending?

For technical and substantive conformity according to EN16931 and XRechnung CIUS, yes, because that is exactly what the Validator is built for. However, it does not check whether the business data contained, such as bank details or service description, is substantively correct; that remains your responsibility.

Do I need a separate configuration for each invoice type?

Yes, the scenario configuration is tied to the respective format. For XRechnung, you use the XRechnung Validator configuration; for other EN16931 variants like ZUGFeRD, there are correspondingly different configuration files with their own Schematron rules.

Can I use the Validator without Java knowledge?

Basic knowledge of the command line is sufficient for simple calls against individual files; you do not need a Java development environment for this. For integration into an automated workflow, such as via daemon mode, technical understanding of HTTP calls is helpful.

What happens if the Schematron rules change?

XRechnung Schematron rules follow semantic versioning: major versions introduce incompatible rule changes, minor versions extend valid content such as new code lists, and patch versions fix backward-compatible errors. It is worthwhile to keep track of the configuration version used and to test existing validation workflows again when major versions change.