← 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'.

At the end of Part 2, the decision was made: build it myself, not bolt on someone else’s beta library. The open question: is that even doable? Can you produce compliance yourself without disappearing into technical depths for half a year?

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

You cannot stamp a crooked house straight

The most common mistake with e-invoices is thinking of compliance as an inspection stamp you press onto the finished document at the end. That is not how it works.

An e-invoice contains a PDF. That PDF has to meet a specific archival standard called PDF/A-3. Every font must be fully embedded, every color defined the right way, and a long list of constructions is simply forbidden. If even one letter is missing proper embedding, the official validator says no.

Imagine a house that was built crooked from the start. No inspector in the world will come along afterward and stamp it straight. You have to build it right from the ground up.

That is the whole approach: compliant by construction. Do not repair afterward, produce it cleanly from the first line. It is also the reason the ready-made packages from Part 2 start to struggle 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, four clear jobs

When you produce the PDF yourself, cleanly from the start, the big intimidating problem falls apart into four manageable pieces. Each one has a single job:

The model. A cleanly defined dataset that describes an invoice: number, date, line items, amounts, tax. Everything else is just a transformation of it.

The machine-readable XML. From the model comes a dataset in the prescribed format. XML is a text language that computers can read well. This is the part the recipient’s accounting software actually processes.

The visible PDF. From the same model comes the document a human can read. It is built according to the PDF/A rules from the first line, not bent into shape afterward.

The merge. XML and PDF are joined into one single file. Both say the same thing. If they ever disagree, the XML counts, as explained in Part 1.

Below those four sits a fifth layer: the actual validation. That is the subject of Part 4.

This setup needs no heavy runtime and no extra conversion tool on the side. That is not a point of pride for its own sake. It means the engine can also run in a lean cloud environment, the same place the portal lives. Exactly the property the off-the-shelf packages could not guarantee for the delicate part.

Not everything at once

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-checked 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 checked against the same validators.

The difference: “demonstrably works for a real case” versus “should work for everything in principle.” With a legal obligation, you want the first.

The most honest moment

One moment from the build stuck with me.

The compliant core was done, the validation mechanism wired up. But the actual validation run was not technically 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 everything. 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 bar: compliant from the ground up, against the official validators, no green without proof. Claude came with the architecture and the ordering.

The competence in this way of working no longer sits only in the typing. It sits in setting the right path and checking 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 technical 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 code.

That leaves the last and most important point. “Built compliant from the ground up” is a nice claim. How do I know it is 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 →