← 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: the invoice engine was built compliant from the ground up. Easy to say. With a legal mandate, though, no one cares about “trust me.” They want proof. This final part is about where that proof comes from.

The problem: looking compliant is easy

A finished invoice PDF that is compliant and one that merely looks compliant are identical to the human eye. The difference only shows up when a machine checks the file. At the recipient’s end, in the accounting software, during a tax audit. By then it is too late to fix anything.

Anyone who checks their own work tends to find very little. So you must not be the one who certifies it.

Three checkers I cannot influence

Three independent, official checker programs judge every file the engine produces:

veraPDF checks whether the PDF truly meets the archival standard called PDF/A-3. Think of it as the rule that makes sure a PDF is still readable decades from now, not just today.

KoSIT is the German public administration’s checker for the European invoice standard. Whatever passes green here counts as compliant in the official sense.

Mustang is the established reference for the ZUGFeRD profiles, the most common e-invoice format in Germany.

I did not write any of these programs. I cannot influence any of them. And none of them has a reason to go easy on me.

Think of them as inspectors you cannot talk into a pass. 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 went the other way.

First I wrote a tiny example by hand in the exact target format and sent it through the three checkers. Only once they reported green was it settled what the field had to look like. After that, we built the code that generates it automatically with Claude Code.

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

Not just the simple invoice

Proving compliance for one invoice with two line items would be worth little. Real invoices are messier. The engine now covers what actually shows up in everyday use: multiple tax rates, discounts, prepayments, gross prices, direct debit with a mandate reference, and the pure XRechnung format with its routing ID for invoices to public authorities.

Each of these fields is secured individually against the three checkers. 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 sends strange but permitted input on purpose?

Whatever turned up, we hardened before anyone out there could find it. This hostile self-check is exactly the step a quickly thrown-together solution skips. Better to find the cracks yourself than to wait for a customer to find them.

A name and a license

The “own package” from the earlier parts had turned into a finished thing. Finished things need a name.

The choice was Rechenwerk, German for the calculating unit of a machine. Almost literally what the engine here does. Short and fitting.

Plus a license, and that is a deliberate decision: AGPL (Affero General Public License). 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 version of “open source, but I have bills to pay too.”

What stands at the end

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

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