E-Rechnung 2028 Teil 2: Fertige Lösung einbauen, oder selbst bauen?

Am Ende von Teil 1 stand der Entschluss, das Rechnungsportal jetzt e-rechnungsfähig zu machen, nicht erst kurz vor der Frist. Damit war die nächste Frage dran, und an ihr hängt der ganze zweite Teil: Nehme ich eine fertige Lösung vom Markt, oder baue ich es selbst?

Die Antwort kam über einen Umweg: Claude riet mir erst zur naheliegenden Lösung und ruderte später selbst zurück.

Was der Markt hergibt

Bevor man selbst baut, schaut man, was es schon gibt. Ich ließ die JavaScript- und Node-Landschaft für E-Rechnung recherchieren, weil mein Portal auf dieser Technik läuft. Es gibt durchaus ernstzunehmende Pakete, drei im engeren Kreis (Stand Juni 2026):

node-zugferd. Das bekannteste, frei lizenziert, sauberes TypeScript, die meisten Downloads. Erzeugt den Rechnungs-Datensatz und bettet ihn in ein PDF ein. Steht allerdings seit fast einem Jahr auf einer Beta-Version und kann nur das eine von zwei zulässigen XML-Formaten.
@e-invoice-eu/core. Der breiteste Stack, der aktiv gepflegteste, deckt die meisten Formate ab.
@stackforge-eu/factur-x. Der fokussierteste, spezialisiert auf das Einbetten des Datensatzes ins PDF.

Auf den ersten Blick ist die Sache damit gelöst. Man nimmt eines davon, hängt es ans Portal, fertig.

Wo es trotzdem hakt

Bei genauerem Hinsehen haben alle drei dieselbe Sollbruchstelle. Den Datensatz zu erzeugen und ihn in ein PDF zu stecken, ist der leichtere Teil. Der schwere Teil ist, zu garantieren, dass das PDF am Ende wirklich der Archiv-Norm PDF/A-3 entspricht. Das ist die Norm, an der die amtlichen Prüfer eine E-Rechnung durchfallen lassen, wenn auch nur eine Kleinigkeit nicht stimmt.

Wie heikel das ist, schreibt der Anbieter mit dem breitesten Funktionsumfang in seine eigene Dokumentation. Wörtlich:

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

„Diese Bibliothek erzeugt PDFs allein mit pdf-lib und nimmt einige ziemlich komplizierte Umbauten am PDF vor, um PDF/A-Konformität zu erreichen. Das ist nicht praxiserprobt und kann fehlschlagen.“

Für den Produktivbetrieb empfiehlt derselbe Autor, lieber externe Schwergewichte wie Ghostscript oder LibreOffice die Konvertierung übernehmen zu lassen. Das ist bemerkenswert offen, und es ist genau der Punkt: Der heikelste Teil der ganzen Sache ist in der JavaScript-Welt der am wenigsten abgesicherte. Die wirklich erprobten Prüf- und Erzeugungswerkzeuge leben woanders, in der Java- und PHP-Welt.

Der erste Rat, und mein Einwand

Aus dieser Lage hatte Claude einen pragmatischen Vorschlag: eines der Pakete nehmen, am besten das fokussierte, ins Portal einbauen, einmal gegen die amtlichen Prüfer testen, fertig. Schnell, wenig Code, läuft auch serverlos. Ein vernünftiger Rat, und der reflexhafte Standard: Für ein gelöstes Problem nimmt man eine Bibliothek.

Mich hat er trotzdem nicht überzeugt. Ich fragte zurück, sinngemäß: Warum überhaupt fremde Bibliotheken? Ist eine E-Rechnung so kompliziert, dass man sie nicht selbst bauen kann? Und wenn man sie selbst bauen kann, könnten wir dann nicht sogar etwas veröffentlichen, das auch andere benutzen?

Der Strohmann, den die KI selbst zugab

Die erste Antwort darauf war eine Verteidigung. Claude zählte auf, wie schwer PDF/A angeblich sei: ein PDF von Grund auf bauen, Schriftarten einbetten, Datenströme komprimieren, all das. Klang nach einem halben Jahr Arbeit.

Ich hakte beim PDF/A-Format noch einmal nach. Es sei doch auch nur etwas, das man mit Code lösen kann. Daraufhin ruderte Claude zurück, und das war der ehrlichste Moment der ganzen Recherche:

„Du hast recht, und ich habe den Schwierigkeitsgrad vorhin etwas als Strohmann aufgebaut.“

Claudes eigene Auflösung des Denkfehlers: „PDF/A selbst bauen“ klingt nach „einen kompletten PDF-Generator von null schreiben“. Das macht aber niemand. Dafür gibt es eine neutrale, quelloffene Grundbibliothek, die nichts weiter ist als ein PDF-Baukasten. Sie zu benutzen ist, als kaufe man den Reißverschluss zu, statt ihn neu zu erfinden, bevor man eine Jacke näht. Die eigentliche E-Rechnungs-Logik, das Heikle und Normrelevante, schreibt man darüber selbst. Damit war mein eigentlicher Einwand, eine fremde Bibliothek für die Rechnungslogik, gegenstandslos. Die fremde Komponente macht nur PDF-Mechanik, keine Fachlogik.

Die Entscheidung

Damit war die Frage entschieden, und zwar in die unbequemere Richtung. Ich baue es selbst. Nicht als Wegwerf-Lösung nur fürs Portal, sondern als eigenes, veröffentlichbares Paket. Das Portal ist dann der erste echte Nutzer und zugleich der Beweis, dass es funktioniert, nicht umgekehrt.

Diese Reihenfolge ist der Kern der Entscheidung. Wer nur schnell sein Portal fertig haben will, klebt eine Beta-Bibliothek dran und hofft, dass sie hält. Wer das Problem allgemein löst, baut einmal etwas Sauberes, das er versteht, kontrolliert und wiederverwenden kann. Und er steht nicht unter einer Gesetzespflicht auf fremdem Code, den dessen eigener Autor als „nicht praxiserprobt“ bezeichnet.

Claude war an der Entscheidung beteiligt, aber an der richtigen Stelle. Den Bauplan, in welcher Reihenfolge man vorgeht, zuerst ein kleiner, wasserdicht konformer Kern, dann die Breite, hat Claude beigesteuert. Die Richtung, überhaupt selbst und allgemein zu bauen, kam von mir.

Bleibt die Frage, die im Raum stand, seit der Strohmann durchschaut war: Geht das überhaupt? Kann man Konformität selbst bauen, ohne ein halbes Jahr in PDF-Interna zu versinken? Darum geht es in Teil 3.

Teil 2 von 4 der E-Rechnung 2028 Serie.

← E-Rechnung 2028 Teil 1: Wer muss wann, und warum schon jetzt? | E-Rechnung 2028 Teil 3: Konformität baut man ein, nicht drauf →

Die Engine aus dieser Serie gibt es als Projekt: Rechenwerk.