KoSIT Validator: What It Checks and How to Run It

The KoSIT validator is the open-source validation tool of Germany's Coordination Office for IT Standards (Koordinierungsstelle für IT-Standards, KoSIT). With the XRechnung configuration, it checks an XML invoice against the XSD schema, the EN 16931 rules and the XRechnung rules and recommends accepting or rejecting it. It runs as a Java command-line tool or as an HTTP service.

This guide is for developers, integrators and accounts payable teams who want to reproduce a validation result or run the validator themselves. All facts are as of 29 September 2026: validator 1.6.3 and configuration 2026-08-31.

What is the KoSIT validator?

The KoSIT validator is a configurable Java program that validates XML documents against XSD schemas and Schematron rules and writes a report with an acceptance recommendation. KoSIT describes it on xeinkauf.de (opens in a new tab) as a "configurable XML validation tool" that becomes an XRechnung validator through an XRechnung-specific configuration.

Two parts belong together:

Without a configuration the validator checks nothing, because all rules live in the configuration. When someone asks which KoSIT validator version you use, the more useful answer is the configuration date.

How does a validation run work?

1. Pick a scenario: the validator compares the root element and the specification identifier (BT-24) with the match expressions in scenarios.xml.
2. XSD check: the file must conform to the UBL 2.1 or CII schema.
3. EN 16931 Schematron: mandatory fields (BR-…), calculations (BR-CO-…), code lists (BR-CL-…).
4. XRechnung Schematron: German national rules (BR-DE-…), only in the XRechnung scenarios.
5. Report: the report template collects the results. The configuration can change severities here; version 2026-08-31, for example, downgrades BR-CL-23 from "fatal" to "warning".
6. Verdict: if the report contains a rep:accept element, the file counts as acceptable.

This is the start of the first scenario in the current configuration:

<match>exists(/invoice:Invoice/cbc:CustomizationID[ . = 'urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0']) </match>
<validateWithXmlSchema>
  <resource>
    <name>XML Schema for UBL 2.1 Invoice</name>
    <location>resources/ubl/2.1/xsd/maindoc/UBL-Invoice-2.1.xsd</location>
  </resource>
</validateWithXmlSchema>

Configuration 2026-08-31 contains eleven scenarios:

The last row explains a common surprise: an invoice with an outdated identifier such as xrechnung_2.3 is rejected before a single business rule runs. Namespaces and BT-24 are covered in XRechnung XML structure.

Where does the validator fit legally?

The BMF letter of 15 October 2025 (BMF: German Federal Ministry of Finance) does not name a specific tool. It refers to a "suitable validation application" that can detect format errors (para. 6a). Under para. 35a, a business exercising the care of a prudent merchant may rely on the technical result of such a validation for format and business rules, and keeping the validation report is recommended as evidence.

Validation does not replace checking the content. A wrong VAT rate breaks no rule but is still a content error. How format, business-rule and content errors relate is explained in our guide to fixing XRechnung validation errors.

Example: run the validator locally

You need Java 11 or later. The commands follow the usage guide of the XRechnung configuration, with folder names adapted.

# Download the validator and the XRechnung configuration
curl -L -o validator-1.6.3-standalone.jar \
  https://repo1.maven.org/maven2/org/kosit/validator/1.6.3/validator-1.6.3-standalone.jar
curl -L -o configuration.zip \
  https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip
unzip configuration.zip -d configuration

# Validate an invoice, write the XML and HTML report to "reports"
mkdir -p reports
java -jar validator-1.6.3-standalone.jar \
  -s configuration/scenarios.xml -r configuration \
  -o reports -h invoice.xml
echo $?

-s points to scenarios.xml, -r to the folder with the rule files, -o sets the output folder, -h also saves an HTML version of the report, and -p would print the result to the terminal. Afterwards reports contains invoice-report.xml and invoice-report.html.

echo $? shows the exit code:

Common pitfalls

• Since version 1.5.1 the file is called validator-…-standalone.jar. Older scripts and tutorials still call validationtool-….
• Since version 1.6.1 the standalone JAR is published separately from the ZIP package; release 1.6.0 shipped only the ZIP.
• -r must point to the folder that contains the configuration's resources folder. Otherwise the validator cannot find the rule files and exits with -2.
• You can pass -s and -r several times, for example to use the XRechnung configuration and the public Peppol BIS Billing configuration in one run.
• Instead of a file name, the validator also reads the invoice from standard input, for example < invoice.xml.

What does the verdict say?

The report template of configuration 2026-08-31 is German and uses five sentences. Translations are ours:

Warnings do not change the recommendation. Our list of XRechnung error codes explains individual messages, but the rule text in the report itself is authoritative.

The validator as an HTTP service

The -D option starts a server, by default on localhost, port 8080. Set another address with -H and another port with -P.

java -jar validator-1.6.3-standalone.jar -s configuration/scenarios.xml -r configuration -D

# in a second terminal: POST the invoice and save the report
curl -s -o report.xml -w "%{http_code}\n" \
  -H "Content-Type: application/xml" \
  --data-binary @invoice.xml http://localhost:8080/invoice.xml

The service returns 200 if the file is acceptable, 406 if it is not, and 422 for a processing error, which usually points to the configuration. It accepts one XML document per request (no multipart) and has no authentication, so put it behind a proxy or restrict access. A health endpoint is available at /server/health.

Which configuration matches which XRechnung version?

According to KoSIT, XRechnung 3.0 stays in force until at least 31 July 2027. The XRechnung 4.0 pre-release was published in September 2026, and the final version is expected in spring 2027 together with the technical components. Until then, validate with configuration 2026-08-31. If you still run validator 1.5.x, upgrade to 1.6.3: it fixes a security issue that allowed remote stylesheets to be included in STRICT_LOCAL mode.

KoSIT validator, online check and XML viewer compared

The online check follows the same steps as the reference tool. It picks the scenario by the identifier in BT-24, checks the XSD schema, and then runs only that scenario's Schematron rules. It also applies the severity changes in scenarios.xml, such as BR-CL-23 as a warning, and uses the same verdict rule: it accepts the file only if no message at level "error" is left. So ZUGFeRD XML in the EN 16931 profile is checked against the EN 16931 rules only. An unknown identifier is rejected before any rule runs, just as the KoSIT validator does it.

We compared the online check with KoSIT validator 1.6.3 and configuration 2026-08-31 on 33 of our own test files and the 86 files of the official XRechnung testsuite. The verdicts, rule codes and levels matched for every file. One difference remains: schema errors come from a different XML library, so their wording differs and they have no cvc-… codes. The schema check itself gives the same result. Only the KoSIT validator produces a report you can keep on file. For a complete ZUGFeRD check, see how to validate a ZUGFeRD PDF.

How to check an XRechnung with docutools.pro

1. Open the XRechnung validator and click "Select file", or try the flow with "Load sample invoice". It accepts UBL Invoice and CII files, not PDFs.
2. The file is sent to our server and checked the way the KoSIT validator does it: scenario, XSD schema and Schematron rules of configuration 2026-08-31. The free plan allows two uploads a day up to 500 KB.
3. You get the verdict "KoSIT-conformant / Valid XRechnung" or "Not KoSIT-conformant", a "Compliance score" and the list of errors and warnings with their rule codes.
4. Look up individual codes in the XRechnung validation errors reference, for example BR-DE-15 for the missing buyer reference (BT-10).
5. To inspect the file structure, open it in the XML viewer. It shows the tree in your browser, free up to 500 KB, but does not validate.
6. If you need a report to keep on file, for example as evidence in the sense of the BMF letter or when onboarding a customer, also run the KoSIT validator as shown above and keep its report.

More guides on validation rules and error messages are on the validation and errors topic page.

Sources

• KoSIT validator on GitHub, with CLI and daemon documentation (opens in a new tab)
• XRechnung validator configuration on GitHub, releases and usage guide (opens in a new tab)
• XRechnung versions and bundles on xeinkauf.de (German) (opens in a new tab)
• BMF letter of 15 October 2025 on e-invoicing (German) (opens in a new tab)

Last reviewed: September 2026

This article is general information, not tax or legal advice.