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

At the end of Part 1 stood the decision to make the invoicing portal e-invoice-ready now, not just before the deadline. That brought up the next question, and the whole second part hangs on it: do I take a ready-made solution off the market, or build it myself?

The answer came by way of a detour: Claude first advised the obvious solution, then walked it back itself.

What the Market Offers

Before you build it yourself, you look at what already exists. I had the JavaScript and Node landscape for e-invoicing researched, because my portal runs on that stack. There are genuinely serious packages out there, three in the shortlist (as of June 2026):

  • node-zugferd. The best known, freely licensed, clean TypeScript, the most downloads. It produces the invoice data set and embeds it into a PDF. But it has been sitting on a beta version for nearly a year, and it can only do one of the two permitted XML formats.
  • @e-invoice-eu/core. The broadest stack, the most actively maintained, covers the most formats.
  • @stackforge-eu/factur-x. The most focused, specialized in embedding the data set into the PDF.

At first glance, that settles it. You take one of them, hang it onto the portal, done.

Where It Still Snags

On closer inspection, all three share the same breaking point. Producing the data set and stuffing it into a PDF is the easier part. The hard part is guaranteeing that the PDF really conforms to the archival standard PDF/A-3. That is the standard the official validators use to fail an e-invoice if even one small thing is off.

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

“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.”

For production use, that same author recommends letting external heavyweights like Ghostscript or LibreOffice handle the conversion instead. That is remarkably candid, and it is exactly the point: the trickiest part of the whole thing is the least secured one in the JavaScript world. The truly battle-tested validation and generation tools live elsewhere, in the Java and PHP world.

The First Recommendation, and My Objection

Out of that situation, Claude had a pragmatic suggestion: take one of the packages, ideally the focused one, build it into the portal, test it once against the official validators, done. Fast, little code, runs serverless too. A reasonable recommendation, and the reflexive default: for a solved problem, you reach for a library.

It still did not convince me. I asked back, in effect: why use third-party libraries at all? Is an e-invoice so complicated that you cannot build it yourself? And if you can build it yourself, couldn’t we even publish something that others could use too?

The Straw Man the AI Admitted To

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

I pressed once more on the PDF/A format. Surely it, too, is just something you can solve with code. 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.”

Claude’s own dissection of the error in thinking: “build PDF/A yourself” sounds like “write a complete PDF generator from scratch.” But nobody does that. There is a neutral, open-source base library for it that is nothing more than a PDF construction kit. Using it is like buying the zipper ready-made 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. With that, my real objection — a third-party library for the invoice logic — fell away. The third-party component only does PDF mechanics, no domain logic.

The Decision

That settled 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 then 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 the decision. Whoever just wants the portal finished quickly glues a beta library 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 foreign 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 — Claude contributed. The direction, to build it myself and build it generally at all, 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 PDF internals? 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 →

The engine from this series is a project: Rechenwerk.