Pass the e-invoice mandate.
In TypeScript.
Open-source validation, repair and generation for XRechnung / EN 16931. Built to match the official KoSIT validator, with cryptic rule violations turned into plain-language fixes — and nothing ever leaving your machine.
$ npx stampbench validate rechnung.xml
rechnung.xml syntax: UBL | profile: xrechnung
ERROR BR-CO-17 VAT breakdown S @ 7%: tax amount
should be 22.04 (314.86 × 7%) but is 99.99. (line 78)
ERROR BR-DE-15 Missing buyer reference (BT-10)… (~line 2)
INVALID — 2 errors, 0 warnings (56 rules run)The official validator says [BR-DE-15]. Now what?
Millions of European businesses are being forced onto structured e-invoices, and the tooling assumes you enjoy reading Schematron. The reference stack is Java, the error messages cite clauses instead of fields, and one wrong VAT rounding rejects the whole document. Stampbench is the layer that makes it just work.
Validation that explains itself
EN 16931 core rules, the full VAT category families (BR-S/E/AE/Z/G/O), and the German XRechnung profile (BR-DE). Every violation carries the rule id, the business term, and a message written for developers.
It fixes what it can work out
Totals and VAT amounts that disagree with the figures they are computed from have exactly one right answer, so Stampbench corrects them in your file — and refuses to invent a VAT number it cannot derive.
The exact failing line
Every violation carries a line and column, so a broken invoice annotates your pull request where the problem is instead of dumping a log. Approximate positions say so, rather than guessing confidently.
Totals computed by construction
Send lines with quantities, prices and VAT categories. Stampbench derives BT-106 through BT-115 and the VAT breakdown so the BR-CO arithmetic rules pass every time — the part hand-rolled generators always get wrong.
Know what breaks before it breaks
Rule sets change on a published schedule — and the artefacts land before they become binding. Point Stampbench at your invoices, diff them against the next rule set, and get a ranked list of what to fix.
Reads what Germany actually sends
Both syntaxes, auto-detected: UBL and CII — the ZUGFeRD / Factur-X XML that most German e-invoices arrive as. No Java, no server round-trip, no account.
Two commands, full compliance
No SDK lock-in, no XML expertise required. Runs locally — your invoices never leave your machine.
$ npx stampbench validate rechnung.xml
rechnung.xml syntax: UBL | profile: xrechnung
ERROR BR-CO-17 VAT breakdown S @ 7%: tax amount
should be 22.04 (314.86 × 7%) but is 99.99. (line 78)
ERROR BR-DE-15 Missing buyer reference (BT-10)… (~line 2)
INVALID — 2 errors, 0 warnings (56 rules run)$ npx stampbench fix rechnung.xml --write
rechnung.xml
fix line 78 BR-CO-17, BR-S-09 99.99 → 22.04
keep BR-DE-15 no derivable correct value —
this needs a human decision
1 fix applied, 1 error needing a personDon't take our word for it
A compliance tool is only worth using if it is right. Here is what we actually test — with the numbers, and the divergences we currently flag, published openly.
Be compliant before your competitors are.
Unlimited local validation with the open-source library, forever. No account, no limits.
Get it on npm