← Back to Blog
e-rechnungzugferdarchitekturJuly 10, 2026 · 5 min read
StandardSimply explained

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

MODEL · XML · PDF/A-3 · MERGE → VALIDATOR: GREEN · NO GREEN WITHOUT PROOF
Editorial illustration: four labelled building blocks 'MODEL', 'XML', 'PDF/A-3' and 'MERGE' flow into a single invoice document that passes through a 'VALIDATOR: GREEN' gate; on the left a crossed-out 'LATE STAMP', on the right a criteria list ending in 'NO GREEN WITHOUT PROOF'.Editorial illustration: four labelled building blocks 'MODEL', 'XML', 'PDF/A-3' and 'MERGE' flow into a single invoice document that passes through a 'VALIDATOR: GREEN' gate; on the left a crossed-out 'LATE STAMP', on the right a criteria list ending in 'NO GREEN WITHOUT PROOF'.

Part 2 ended with a decision and an open question. The decision: build the package myself, in a general way, instead of gluing on someone else’s beta library. The question: is that even feasible? Can you produce compliance yourself without disappearing into PDF internals for half a year?

The short answer is yes. But only if you start from the right side.

Compliance Is Not a Stamp

The most common mistake with e-invoices is to picture compliance as an inspection stamp you press onto a finished document at the very end. That is not how it works. Compliance is a property of the whole document, not a step you run last.

A PDF only counts as archive-grade under the PDF/A-3 standard if everything lines up: every font fully embedded, every color defined in a device-independent way, none of the many forbidden constructions present. A single non-embedded letter, and the official validator says no. A messy PDF cannot be stamped clean after the fact. You have to produce it clean from the first line.

That is the whole approach, compliant by construction: don’t repair afterward, build it right from the ground up. It is also the reason the off-the-shelf libraries from Part 2 start to flounder right here. They often take in an arbitrary PDF and try to bend it into compliance after the fact. That is the hard, unreliable direction.

Four Building Blocks

When you produce the PDF yourself and compliant from the start, the big, intimidating problem falls apart into four manageable building blocks, each with one clear job:

  • The model. A single, cleanly defined data set that describes an invoice: number, date, line items, amounts, tax. Everything else is just a transformation of it.
  • The XML. From the model comes the machine-readable data set in the prescribed format. This is the part the recipient’s accounting software reads.
  • The PDF. From the same model comes the visible document, built according to the PDF/A rules from the first line. It is drawn with a neutral base component, the zipper from Part 2; all the compliance logic on top of it is my own code.
  • The merge. XML and PDF are joined into one file, with the built-in guarantee that both say the same thing. If they disagree, then as mentioned in Part 1, the XML counts.

Below that lies a fifth layer, the actual validation. That is the subject of Part 4.

This setup needs no heavy Java runtime and no Ghostscript. That is not an end in itself: it means the engine also runs in a lean cloud environment, the same place the portal lives. Exactly the property the off-the-shelf libraries could not guarantee for the delicate part.

The Green Core First

Four building blocks, two XML formats, several ZUGFeRD profiles, plus plain XRechnung on top: that is a lot at once. The mistake would be to start everything at the same time and end up with nothing finished.

The order that prevents this came from Claude: first a single, narrow, watertight compliant core. One real invoice, one format, one profile, fully green through the official validators. Only once that core stands does the breadth get added, layer by layer, each one secured against the same validators.

The difference behind it is the one between “demonstrably works for a real case” and “should work for everything in principle.” With a legal obligation, you want the first.

The Most Honest Commit

One moment from the build stuck with me. The compliant core was done, the validation mechanism wired up, but the actual validation run technically wasn’t running yet; a stubborn component on the development machine refused to start.

At that point it would have been easy to write “done, green” into the version history. Claude did not. The commit stated it plainly: validation wired up, run pending, no green promise. Only hours later, when the validator actually ran through and actually reported green, did that turn into a green.

With software meant to fulfill a legal obligation, the difference between “looks green” and “the official validator says green” is the whole point. Passing one off as the other builds a time bomb.

Who Built What Here

I did not type this engine line by line myself. Claude built it, under my direction and against my review. From me came the direction and the standard: compliant from the ground up, against the official validators, no green without proof. Claude came with the architecture and the order.

The competence in this way of working no longer sits only in the typing, but in setting the right path and reviewing the result hard enough. “I built this” no longer covers it.

That answers the question from Part 2: yes, you can produce compliance yourself without sinking into the PDF swamp. Not by reinventing everything, but by producing the document right from the start and controlling the delicate logic yourself, instead of handing it off to someone else’s library.

That leaves the last and most important point. “Built compliant from the ground up” is a nice claim. How do I know it’s true? That is what Part 4 is about.

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

← E-Rechnung 2028 Part 2: Plug In a Library, or Build It Right? | E-Rechnung 2028 Part 4: How I Know It’s Actually Compliant →

The engine from this series is a project: Rechenwerk.