Compare

KoSIT Validator and Attestwire

Looking for a way to check XRechnung without running Java? Start here. This page 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. It is the official XRechnung validator, it is a Java program shipped as a standalone JAR, and it is the tool we run our own output through.

Attestwire is an EN 16931 rule engine in TypeScript. Zero runtime dependencies, no JVM, installed with npm, and it runs wherever your JavaScript already runs.

Both can be true at once. Plenty of teams want 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 is the part you came for.

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. It makes no network call and needs no key. 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 sets 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 in BT-24, 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.

The versions our checks pin are validator 1.6.2 and the XRechnung 3.0.2 configuration.

What Attestwire is

An EN 16931 engine you can call from your own code: 270 rules an invoice you send can break, across the core rule set, the XRechnung CIUS and the Peppol BIS base rules. 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

11 committed release fixtures — 5 UBL and 6 CII — were acceptable to KoSIT 1.6.2 with the XRechnung 3.0.2 configuration on 13 August 2026, with zero findings.

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 upload are not run through KoSIT at request time.

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-01, 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

There are several.

• 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.

One gives a developer a rule id and a fix in under a second. The other gives you the answer your receiver cares about. 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. Our own conformance script pins validator 1.6.2 and the XRechnung 3.0.2 configuration.

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 CIUS and the Peppol BIS base rules, 270 rules an invoice you send can break. 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 13 August 2026, all 11 committed fixtures came back ACCEPTABLE with zero findings at any severity.

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. The two answer different questions, and the second one is the one your receiver cares about.