← Back to Blog
e-rechnungzugferdbuild-vs-buyJuly 3, 2026 · 5 min read
StandardSimply explained

E-Rechnung 2028 Part 2: Plug In a Library, or Build It Right?

LIBRARY (BETA) · PDF/A-3 · OWN LOGIC → CONFORMITY CORE → VERIFIED
Editorial illustration: on the left three stacked 'LIBRARY (BETA)' blocks feeding via dashed paths into a central 'PDF/A-3' gate; below, a separate 'OWN LOGIC' path runs through a 'CONFORMITY CORE' to a green 'VERIFIED'. A third-party beta library set against a self-built, verified core.Editorial illustration: on the left three stacked 'LIBRARY (BETA)' blocks feeding via dashed paths into a central 'PDF/A-3' gate; below, a separate 'OWN LOGIC' path runs through a 'CONFORMITY CORE' to a green 'VERIFIED'. A third-party beta library set against a self-built, verified core.

Part 1 ended with a decision: make the invoicing portal e-invoice-ready now, not right before the deadline. That raised the obvious next question. Take something off the shelf, or build it myself?

The answer was not straightforward. It needed a detour. And on that detour, the AI first nudged me in one direction and then pulled me back out of it.

What already exists

Before you build anything yourself, you check whether someone else has already solved the problem. For the technology my portal runs on, there are a few serious packages out there. Packages are ready-made building blocks you can plug into your own software, like a pre-built shelf from a hardware store that you bolt into your own kitchen.

Three made the shortlist. One is the best known and most downloaded. One covers the most formats. One is the most specialized in a particular step of the process.

At first glance: problem solved. You pick one, hook it up to the portal, done.

The weak spot they all share

On closer inspection, all three have the same sore spot.

Generating the invoice dataset and stuffing it into a PDF is the easier part. The hard part is making sure the PDF actually meets a specific archival standard called PDF/A-3. Official validation tools will reject an e-invoice if even one small detail is off.

How touchy this is, the vendor with the broadest feature set writes into his own documentation. Word for word:

“This library creates PDFs solely with pdf-lib and does some pretty complicated transformations on the PDF to achieve PDF/A compliance. This is not battle tested and may fail.”

That is remarkably honest. And it is exactly the point: the trickiest part of the whole thing is the least secured one.

Think of it like building a house. There are ready-made kits for the walls, the roof, the windows. But for the structural engineering, the part where it really matters, the manual says: Not battle tested. May collapse. That makes you pay attention.

The AI’s first advice

Given this situation, Claude had a pragmatic suggestion: take one of the ready-made packages, build it into the portal, test it once against the official validators, done. Fast, little work. The classic reflex: for a solved problem, you grab something off the shelf.

It still did not convince me. I asked back: why use third-party building blocks for the actual invoice logic at all? Is an e-invoice so complicated that you cannot build it yourself? And if you can, could we even publish something that others could use too?

The AI overstated it, then admitted it

The first answer was a defense. Claude listed how hard it supposedly is: building a PDF from the ground up, embedding fonts, compressing data streams. It sounded like half a year of work.

I pushed back once more. At that, Claude rowed back, and that was the most honest moment of the whole investigation:

“You’re right, and I built up the difficulty as a bit of a straw man earlier.”

A straw man is when someone exaggerates a position on purpose so it is easier to dismiss. Here, Claude had inflated the difficulty of building it yourself, making the ready-made option look more attractive.

Claude’s own resolution: “build PDF/A yourself” sounds like “write a complete PDF generator from scratch.” But nobody does that. There is a neutral, open-source base component that is nothing more than a PDF construction kit. Using it is like buying the zipper instead of reinventing it before you sew a jacket. The actual e-invoice logic, the touchy, standard-relevant part, you write yourself on top of it.

That settled my objection. The third-party component only handles PDF mechanics, no domain logic.

The decision

That answered the question, and in the more uncomfortable direction. I build it myself. Not as a throwaway just for the portal, but as a standalone, publishable package. The portal becomes the first real user and at the same time the proof that it works, not the other way around.

This order is the heart of it. Whoever just wants the portal finished quickly glues a beta solution onto it and hopes it holds. Whoever solves the problem in general builds one clean thing they understand, control, and can reuse. And they are not standing under a legal obligation on top of someone else’s code that its own author calls “not battle tested.”

Claude was involved in the decision, but in the right place. The build plan, in what order to proceed, first a small, watertight-compliant core, then the breadth, that was Claude’s contribution. The direction, to build it myself and build it in general, came from me.

That leaves the question that had been hanging in the room ever since the straw man was seen through: is it even doable? Can you build compliance yourself without sinking half a year into technical depths? That is what Part 3 is about.

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

← E-Rechnung 2028 Part 1: Who Has to Comply, and When? | E-Rechnung 2028 Part 3: Compliance Is Built In, Not Bolted On →