KoSIT Validator and Attestwire

the reference, and the thing you run before it.

If you need to check an XRechnung (the e-invoice format German public bodies require) and would rather not run Java, this page is for you. It says what each tool is, what we have verified against the official validator, and when that validator is still the one you want.

The short answer

The KoSIT Validator is the reference. KoSIT is the German office that publishes the official XRechnung checker. Its validator is a Java program shipped as a standalone JAR, and it is the tool we run our own output through.

Attestwire is a rule engine for EN 16931, the European e-invoice standard, written in TypeScript. It has zero runtime dependencies, needs no Java runtime (JVM), installs with npm, and runs wherever your JavaScript already runs.

Many teams use both: a fast answer while they are writing code and the official answer before they ship. That setup is described further down.

Ohne Java: checking XRechnung without a JVM

If you searched for "KoSIT Validator Alternative ohne Java" or "XRechnung Validator ohne Java", this section answers that search.

npm install @attestwire/en16931

import { validateInput, minimalXRechnung } from "@attestwire/en16931";

const result = validateInput(minimalXRechnung);

The package uses no platform API beyond the JavaScript standard library, so the same build runs in Node, Deno, Bun, Cloudflare Workers and the browser, with no network call. The playground is this package compiled for the browser: paste a document and it is checked in your tab.

If your backend is not JavaScript, the hosted API takes JSON over HTTP and answers with the same findings.

What the KoSIT Validator is

KoSIT publishes the reference validator for XRechnung. It arrives as a standalone JAR from the validator releases, together with an XRechnung configuration that carries the schemas and the Schematron rule files (the official rule files receivers run against the XML) for the version it targets.

To run it you need a JDK. Our own check script asks for Java 11 or later, hands the JAR a scenarios file and a directory of XML, and reads one report per document out of the output directory.

The configuration picks the scenario per document, from the root element and the specification identifier (field BT-24, which says which version of the standard the invoice follows), then runs that scenario's XML Schema step and its Schematron steps. A UBL credit note is judged against the credit-note schema, and a CII document against the CII rules. The validator routes them there; nobody on our side picks the scenario.

What Attestwire is

An EN 16931 engine you can call from your own code: 321 rules an invoice you send can break, across the core rule set, the German add-on (the XRechnung CIUS) and the base rules of Peppol BIS, the rule set of the Peppol network many European buyers receive invoices through. Every finding names the rule id, the business term, why the regulation asks for it, and what to change.

• The library, MIT-licensed on npm, TypeScript, zero runtime dependencies.
• The hosted API at api.attestwire.com, for backends that are not JavaScript.
• An MCP server, so an agent can check a document without you wiring anything: the tools are listed here.
• A GitHub Action that runs offline in the runner and writes SARIF or JUnit XML: the CI story.

This site makes one comparative claim, and it lives on a dated page with its method and its sources attached: what else is out there

We check our output against KoSIT

KoSIT, the German government’s validator, accepts all eleven sample invoices this library generates. One of them draws a warning from a European rule that KoSIT itself has marked as broken and replaced; it passes the replacement. None draws an error. Validator 1.6.3, XRechnung configuration 3.0.2 (build of 31 August 2026), CEN CII schematron 1.3.16, XRechnung CII schematron 2.6.0; recorded 24 September 2026 against engine 0.10.0.

The warning is CII-SR-475 on the extended CII fixture, a rule that miscounts attachments when an invoice has more than one (CEN issue 508). KoSIT’s configuration lowers it to information and checks BR-TMP-4 instead, which passes.

That is evidence about those 11 generated fixtures. It is not a parity suite, and it is not a guarantee that any particular receiver will accept your document. Documents you check are not run through KoSIT at request time. The fixtures are the sample invoices kept in the repository for testing; the record states its limits in full.

The whole run is published, commands and artefact checksums included: the KoSIT record. You can reproduce it with scripts/kosit-check.sh, which downloads everything into a scratch directory and installs nothing system-wide.

Where our check stops

Two boundaries matter if you are weighing this against the reference validator, and both are quoted from the same list the limits page publishes in full.

Validating the XML itself. The library reads a UBL or CII file into the input model, then checks the model. That is a pre-flight over the parsed input, not a schematron over the document. Rules that constrain the XML rather than the input — BR-DE-13 and BR-DE-21 on BT-24 — still do not run. A document we accept can still be rejected by the reference validator.

Peppol rules inside the XRechnung schematron. KoSIT’s XRechnung schematron runs a few PEPPOL-EN16931 rules for both syntaxes, PEPPOL-EN16931-R040 among them. This build runs its Peppol rules only when the profile is peppol-bis-3. So R040 does not run here for an XRechnung invoice, even though KoSIT runs it. This is not new; the 2026-08-11 KoSIT run is what named it.

When the KoSIT Validator is the right choice

Several situations call for it.

• You need the official verdict. A KoSIT report is the artefact the reference validator produces, and nothing here produces one.
• Your acceptance chain names it. Some German public-sector processes and plenty of internal gates ask for that report by name. If yours does, run it, and treat anything else as a pre-flight.
• You want the document itself judged. Our check reads your XML into an input model and checks the model, so the rules quoted above do not run. A Schematron over the document does run them.
• You are already on the JVM. If Java is in the pipeline and the run is not costing you anything, there is no reason to move it.

Using both

This is the setup we would suggest if the reference verdict is part of your process. Run Attestwire where the feedback has to be fast: in the editor, in the pull request, in the browser, on every push. Keep the official validator in the release job, where it stays the external authority.

Attestwire gives a developer a rule id and a fix in under a second; the official validator gives the verdict your receiver relies on. The CI page shows what the first half looks like as a workflow.

Questions people ask

What is the KoSIT Validator?

It is the reference validator for XRechnung, published by KoSIT as a standalone Java program you run from the command line. You point it at a scenario configuration and at your XML, and it writes one report per document with an acceptance recommendation in it. The XRechnung configuration carries the schemas and the Schematron rule sets for the version it targets.

Do I have to use the KoSIT Validator for XRechnung?

That is decided by the process you are sending into, not by us. It is the reference implementation of the XRechnung rules, and some German acceptance chains ask for its report as the artefact they file. If you are not sure, ask the receiver what they check with. Attestwire checks technical conformance against the rules it implements, and receiver acceptance can depend on rules outside that scope.

Can I validate XRechnung without Java ("XRechnung Validator ohne Java")?

Yes. @attestwire/en16931 is TypeScript with zero runtime dependencies, so "npm install @attestwire/en16931" is the whole setup and the same build runs in Node, Deno, Bun, Cloudflare Workers and the browser. If your backend is in another language there is a hosted API that speaks JSON over HTTP. What you get is a semantic pre-flight over the parsed invoice, which is a different artefact from the reference validator's report on the document.

How do I validate EN 16931 invoices in CI?

Add the GitHub Action to a workflow and point it at the XML your build writes. It runs offline in the runner with a pinned engine version, annotates the pull request, and can export SARIF for code scanning or JUnit XML for everything else. Fatal findings fail the job; informational findings never do.

Can I check an invoice in the browser?

Yes. The playground is the same engine compiled for the browser, so the document you paste is validated in the tab and is not uploaded. It takes no account and no key. That is also the quickest way to see what a finding looks like before you install anything.

Is Attestwire's rule set the same as KoSIT's?

No. It is an independent implementation of EN 16931, the XRechnung add-on and the Peppol BIS base rules. It checks a parsed input model, not the XML document as a Schematron does. Some rules therefore do not run here, and the ones we know about are named on this page and listed in full on the limits page. A document this engine accepts can still be rejected by the reference validator.

What does ACCEPTABLE mean in a KoSIT report?

It is the verdict the validator writes for a document that came through the steps of its matched scenario, and it is a recommendation to accept that one document. It is not a statement about your system or your other invoices. In our recorded run on 24 September 2026, all 11 committed fixtures came back ACCEPTABLE.

One of them draws a warning from a European rule that KoSIT itself has marked as broken and replaced; it passes the replacement. None draws an error.

Can I use both?

That is the setup we would suggest if your process needs the reference verdict. Run the fast check while you are writing the code and in the pull request, and keep the official validator in the release job as the external authority.