einvoice / Comparison
Why not KoSIT or Mustangproject?
Fair question — it is the first one every German ERP developer should ask. The official KoSIT validator and Mustangproject are both free, mature, and in wide production use; for several jobs they are the better choice, and this page says exactly which jobs those are. einvoice earns its place on one axis only: it is a zero-dependency, pure-Python, CI-native conformance gate — no Java, no Saxon, no Schematron toolchain — whose correctness is differentially proven against the official KoSIT artifact.
What each tool is
KoSIT validator — the official validation tool from the Koordinierungsstelle für IT-Standards (KoSIT), the body that publishes the XRechnung standard itself. It is the reference implementation: a Java tool that runs the official XSD schema validation and the official Schematron business rules via an XSLT pipeline. Free and open source. When the KoSIT validator and anything else disagree, the KoSIT validator is right by definition.
Mustangproject — a free, open-source Java library and CLI centred on ZUGFeRD / Factur-X: hybrid e-invoices that embed the structured XML inside a PDF/A-3. Its standout capability is that it writes invoices, not just validates them — it can create a ZUGFeRD PDF from your data or embed XML into an existing PDF, and it validates what it reads. If you need to produce hybrid PDF invoices from Java, it is the obvious tool.
einvoice (this project) — a validation-only conformance gate in pure Python 3 standard library (zero runtime dependencies, fully offline). It asserts 297 EN 16931 / XRechnung business rules, each differentially proven at 0 divergences against the official KoSIT XRechnung Schematron artifact — see the honest dependency note below. It emits json, junit, sarif, gitlab, github, azure, html, badge, text reports, ships a uses:-pinnable GitHub Action and a pre-commit hook, and documents every rule on a per-rule reference page in English and German.
Our correctness claim derives from KoSIT’s artifact
Being explicit about the relationship: einvoice is not an independent reading of the EN 16931 specification. Its correctness claim derives from the official KoSIT/CEN Schematron artifacts — a differential harness runs this engine and the official Schematron side by side over generated and official test invoices and requires 0 divergences on every proven rule, in both the UBL and CII syntax bindings. The official artifact is the ground truth; this engine is a re-implementation proven equivalent against it, rule by rule. Without KoSIT’s published artifact that proof would be impossible, which is one more reason this page has no interest in talking the official toolchain down.
Side by side
einvoice | KoSIT validator | Mustangproject | |
|---|---|---|---|
| Runtime | Pure Python 3 standard library — zero dependencies, no toolchain | Java (JRE) + Saxon XSLT pipeline | Java (JRE), library or CLI |
| Official status | Independent; proven against the official artifact | The official reference implementation | Community open source, widely used |
| Price | Free (Apache-2.0); optional $29 / $290 support license | Free, open source | Free, open source |
| XSD schema validation | No — business rules only | Yes | Yes (ZUGFeRD / Factur-X focus) |
| EN 16931 / XRechnung business rules | 297 rules, differential-proven at 0 divergences | Yes — runs the official Schematron itself | Yes, for the profiles it targets |
| Input syntaxes accepted | Both XRechnung syntaxes, directly: UBL 2.1 Invoice / CreditNote and UN/CEFACT CII rsm:CrossIndustryInvoice — dispatched on the root element, no syntax flag, no wrapper needed for a raw .xml. Also a Factur-X / ZUGFeRD PDF/A-3 container: einvoice validate invoice.pdf extracts the embedded XML and grades it with the same rules and the same exit codes | The same two syntaxes — the official Schematron artifact carries both a UBL and a CII binding (the two legs our differential proof runs against, above) | The same two syntaxes, and the ZUGFeRD / Factur-X hybrid PDFs that are its documented focus — of the three it is the only one that also writes them, two rows below |
| Peppol BIS Billing 3.0 | No — only the 21 PEPPOL-EN16931-R* rules KoSIT vendors inside the XRechnung artifact | Validates whatever scenario/artifact you configure; the official ecosystem covers more here | Broader e-invoicing ecosystem support |
| Writes / creates invoices | No — validation only | No — validation only | Yes — creates ZUGFeRD PDFs and embeds XML into PDF/A-3 |
| CI reports | json, junit, sarif, gitlab, github, azure, html, badge, text | XML / HTML validation report | Java API and CLI output |
| Regression gate against a stored report | Yes — einvoice validate --baseline <prev-report.json> --profile <p> <invoice.xml> fails only on findings that are new since a captured report, so an archive that already fails can be gated today. Two limits below, both load-bearing | Not verified. It produces a verdict per run; we have not checked whether it ships a diff-against-a-stored-report mode, and this page does not guess one either way | Not verified — same, for the same reason |
| Report language | English by default. --lang de swaps the human-facing text: the terminal summary and the text report carry the German message, and --lang de --format html produces a German document — <html lang="de">, German headings, and on every finding a German rule title plus a German Behebung fix hint, which the catalog carries for all 297 rules. The official KoSIT German assert text is quoted verbatim on the 50 rules that publish one (de_source == "kosit"); the other 247 keep their authoritative English assert sentence rather than a machine translation, marked [en] in the HTML report with a note explaining the marker. The seven machine report bodies are byte-identical with and without the flag. This is parity with KoSIT, not an advantage over it. | German, natively — it is the German standards body’s own tool, and the official German assert text quoted in our 50-rule column is theirs, taken from the artifact they publish | Not verified. We have not checked which report languages Mustangproject offers, so this page states nothing about it |
A caution about the table: the einvoice column is machine-derived from this engine’s own registries; the other two columns state only what those tools are publicly known for, and where we were not confident of a detail we described the ecosystem rather than guessing a feature. Check their documentation for anything load-bearing.
Where einvoice earns its keep
- No Java/Saxon toolchain in CI. The whole engine is Python 3 standard library —
dependencies = []— so the gate runs in any CI image that haspython3, offline, with nothing to install or license. - CI-native outputs. One flag switches the report between
json,junit,sarif,gitlab,github,azure,html,badge,text— SARIF gives inline PR annotations, the GitLab and JUnit forms surface findings as native CI results. - A stable exit-code contract.
0= no implemented fatal rule fired,1= at least one fatal violation,2= usage error,3= not well-formed XML. That is the entire integration surface a CI gate needs. - A gate you can switch on over an archive that already fails.
einvoice validate --baseline <prev-report.json> --profile <p> <invoice.xml>validates the invoice now, diffs the findings against a report captured earlier withpython3 -m einvoice.report --profile <p> --format json(the same--profilein both — a mismatch is refused with exit 2 rather than graded as a regression), and returns a non-zero exit code only for a violation that is new since that report. Two limits come with it and neither is a footnote. It tolerates pre-existing fatals by design — that is the point — so a green--baselinerun means “nothing got worse”, never “this invoice conforms”: it is a migration instrument, not a conformance verdict, and the verdict is the same command without the flag. And it diffs one invoice against one stored report —validate-batch --baselineis refused with exit 2 — so a legacy corpus is gated file-by-file in a CI loop, one stored report per invoice. - Pinnable automation. A
uses:-pinnable GitHub Action, a copy-paste CI recipe (POSIX sh + GitHub Actions / GitLab CI) and a pre-commit hook ship in the repository. - Per-rule reference pages. Every asserted rule has its own page — requirement, BT/BG terms, XML location, one-line fix, severity, verbatim official assert — in English and German: the rule index.
- A person to email. An optional commercial license ($29 single developer / $290 vendor team) adds maintainer support and rule-corpus update notices — see licensing. It is never required to use or embed the engine.
Two other kinds of alternative you will find
The rest of this page compares two Java projects, because those are the things an EN 16931 engine is usually measured against. A search in German or English mostly returns two different categories, and you should know where they fit before you decide anything:
- Free hosted validators you use online. Web forms that check an invoice with nothing to install — along with the self-hosted and containerised validation services in the same family. We have measured none of them, so this page makes no claim whatsoever about what any of them checks or how well. The only thing we can state is our own side: the
einvoiceCLI opens no network connection at runtime, and the in-browser validator runs the engine inside your own tab, so the invoice is never uploaded. When you have one invoice to check by hand, with no CI to wire up, nothing to install and no repository to touch, you are genuinely better served by a hosted form than by adding a dependency — go and use one. - Desktop, graphical and command-line front-ends around the official KoSIT validator. These put a window, a drop area or a single shell command in front of the official reference implementation. Read that as a trade running both ways: such a front-end inherits the official validator’s correctness authority — the verdict it prints is the official one, which is exactly what this page tells you to get before an invoice goes to a portal — and it equally inherits the Java runtime that validator needs on the machine.
einvoicesits on the other side of the same trade: no JVM to install, but a differentially-proven pre-flight rather than the official verdict. Neither side of that trade is a win; it is a choice about which cost you would rather pay. If you are not a developer and what you want is a window and a button, a GUI is the right choice and nothing on this page is meant to argue you out of it.
When to prefer them
Honestly, in several situations you should not use einvoice at all, or should use it only alongside the official tool:
- You need the official verdict. The KoSIT validator is the official reference implementation from the body that publishes XRechnung. Before an invoice actually goes to a government portal, run the official validator (or your receiver’s): its answer is the one that counts.
einvoiceis the fast pre-flight in CI, not the final word. - You need XSD schema validation. We do not perform structural XSD validation — only the business rules. The KoSIT validator runs the official XSD schemas as part of its pipeline; if schema-level structure is in question, use it.
- You need full Peppol BIS Billing 3.0. We assert only the KoSIT-vendored
PEPPOL-EN16931-R*subset (21 rules). The KoSIT and Mustangproject ecosystems do more here; for real Peppol network validation use tooling built for it. - You need to create ZUGFeRD / Factur-X PDFs. Mustangproject writes them — builds the PDF/A-3, embeds the XML.
einvoiceis validation-only and will never produce an invoice.
The honest summary: use the official KoSIT validator as your authority, Mustangproject when Java or PDF-writing is in play, and einvoice when you want the same business-rule verdict as a zero-dependency Python gate inside every CI run and pre-commit — cheap enough to run on every push, proven against the artifact the official tool runs.
Want to try that verdict before wiring anything into CI? The in-browser validator runs the same 297-rule engine in your browser via WebAssembly (Pyodide) — drop an XRechnung XML or a ZUGFeRD/Factur-X PDF and read the findings; the invoice never leaves your machine.