← Back to Blog
e-rechnungzugferdkonformitaetJuly 17, 2026 · 4 min read
StandardSimply explained

E-Rechnung 2028 Part 4: How I Know It's Actually Compliant

veraPDF · KoSIT · Mustang → PASS · PDF/A-3 · EN 16931 · ZUGFeRD
Editorial illustration: a central PDF/A-3 document with an embedded XML chip is checked by three independent validators, 'veraPDF', 'KoSIT' and 'Mustang', each showing a green 'PASS'; footer 'PDF/A-3 · EN 16931 · ZUGFeRD'.Editorial illustration: a central PDF/A-3 document with an embedded XML chip is checked by three independent validators, 'veraPDF', 'KoSIT' and 'Mustang', each showing a green 'PASS'; footer 'PDF/A-3 · EN 16931 · ZUGFeRD'.

Part 3 ended with a claim: that I had built the engine compliant from the ground up. That is easy to say. With a legal mandate, though, no claim counts, only proof. This final part is about nothing else. How do I know it is actually true?

Anyone Can Claim Compliance

The trust problem with e-invoices is simple and uncomfortable. A PDF that looks compliant and a PDF that is compliant look identical to the human eye. The difference only shows up when the recipient’s accounting software or a tax audit runs the file through a machine. By then it is too late to fix.

The honest way to solve this is to not make the case yourself. Anyone who checks their own work tends to find little. So three external, established tools do the checking.

Three Validators I Don’t Control

The decisive thing about these three: I did not write them, I cannot influence them, and they have no reason to go easy on me. If my PDF fails veraPDF, it fails. That is exactly what turns a green result into proof rather than a claim.

Ask First, Then Build

For every new field in an invoice, every discount, every payment method, nothing was built first and then hoped for. It ran the other way around: first I wrote a tiny example by hand in the exact target format and sent it through the validators. Only once they reported green was it settled what the field had to look like. The code that generates it automatically came after that, written by Claude Code.

This sounds like a detour, but it is the opposite. It means nothing was ever built without it being established beforehand that the validator would accept it. With a norm that has hundreds of detail rules, that is the distance between “should fit” and “checked, fits.”

Not Just the Simple Invoice

A compliance proof for an invoice with two line items would be worth little. Real invoices are messier. So the engine now covers what actually shows up in everyday use:

  • multiple tax rates and tax exemptions, including reverse-charge
  • discounts and surcharges, on the whole invoice as well as on individual line items
  • gross prices as the customer sees them, with a net-correct data core
  • down payments and rounding amounts
  • SEPA credit transfer and SEPA direct debit with mandate
  • pure XRechnung in both permitted XML dialects, with the Leitweg-ID for invoices to public authorities

Each of these fields is secured individually against the three validators. The state today: more than a hundred automated tests and thirty out of thirty conformance checks green. Not “should work.” Green.

Going Up Against My Own Code

Green does not yet mean done. I had Claude Code attack the code several times, with a single question: where does this break if someone deliberately sends strange but permitted input? Whatever turned up, we hardened before anyone out there could find it. This adversarial self-check is exactly the step a quickly glued-together solution skips.

The Engine Becomes Rechenwerk

The “own package” from Part 2 had turned into a finished thing, and finished things need a name. The choice was Rechenwerk, German for the calculating unit of a machine, almost literally what the engine in this stack does. The name was short, and it fit.

Plus a license, and that is a deliberate decision: AGPL. It keeps the software open, anyone may use and modify it, but it leaves me the door open to also offer it commercially in another form. That is the calm, honest version of “open source, but I have bills to pay too.”

What started as a side question in a client project has become a complete answer: the mandate understood, deliberately built with Claude Code rather than bought, constructed compliant from the ground up, and proven against three independent official validators.

Rechenwerk is the tool. What I offer is the solution behind it: that the mandatory invoice in a business simply works in the end and is provably compliant. More on the reference page or directly at [email protected].

Part 4 of 4 in the E-Rechnung 2028 series.

← E-Rechnung 2028 Part 3: Compliance Is Built In, Not Bolted On