E-Rechnung 2028 Teil 2: Fertige Lösung einbauen, oder selbst bauen?
In Teil 1 stand die Entscheidung: Das Rechnungsportal soll jetzt schon E-Rechnungen können, nicht erst kurz vor der Frist. Damit kam die nächste Frage: Nehme ich etwas Fertiges vom Markt, oder baue ich es selbst?
Die Antwort war nicht sofort klar. Sie brauchte einen Umweg. Und auf dem Umweg hat mich die KI erst in eine Richtung geschubst und dann selbst wieder zurückgeholt.
Was es schon gibt
Bevor man selbst baut, schaut man nach, ob jemand das Problem schon gelöst hat. Für die Technik, auf der mein Portal läuft, gibt es ein paar ernstzunehmende Pakete. Pakete sind fertige Bausteine, die man in die eigene Software einsetzen kann, wie ein vorgefertigtes Regal aus dem Baumarkt, das man in die eigene Küche schraubt.
Es gibt drei im engeren Kreis. Eines ist das bekannteste und am häufigsten heruntergeladen. Eines deckt die meisten Formate ab. Eines ist am stärksten spezialisiert auf einen bestimmten Teilschritt.
Auf den ersten Blick: Problem gelöst. Man nimmt eines davon, hängt es ans Portal, fertig.
Die Schwachstelle, die alle teilen
Beim genaueren Hinsehen haben alle drei dieselbe wunde Stelle.
Den Rechnungs-Datensatz zu erzeugen und ihn in ein PDF zu stecken, ist der leichtere Teil. Der schwere Teil ist, sicherzustellen, dass das PDF am Ende einer bestimmten Archiv-Norm entspricht. Diese Norm heißt PDF/A-3. Amtliche Prüfwerkzeuge lassen eine E-Rechnung durchfallen, 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-liband 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.”
Das ist bemerkenswert ehrlich. Und es ist genau der Punkt: Der heikelste Teil der ganzen Sache ist gleichzeitig der am wenigsten abgesicherte.
Stell es dir so vor: Du willst ein Haus bauen. Es gibt fertige Bausätze für die Wände, das Dach, die Fenster. Aber bei der Statik, dem Teil, bei dem es wirklich darauf ankommt, steht in der Anleitung: Nicht praxiserprobt. Kann einstürzen. Da wird man hellhörig.
Der erste Rat der KI
Aus dieser Lage hatte Claude einen pragmatischen Vorschlag: Nimm eines der fertigen Pakete, bau es ins Portal ein, teste einmal gegen die amtlichen Prüfer, fertig. Schnell, wenig Arbeit. Der klassische Reflex: Für ein gelöstes Problem nimmt man etwas Fertiges.
Mich hat das trotzdem nicht überzeugt. Ich fragte zurück: Warum überhaupt fremde Bausteine für die eigentliche Rechnungslogik? 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?
Die KI übertrieb, und gab es zu
Die erste Antwort war eine Verteidigung. Claude zählte auf, wie schwer das angeblich sei: ein PDF von Grund auf bauen, Schriftarten einbetten, Datenströme komprimieren. Klang nach einem halben Jahr Arbeit.
Ich hakte nach. 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.”
Ein Strohmann ist, wenn jemand eine Gegenposition absichtlich übertrieben darstellt, damit sie leichter zu widerlegen ist. Hier hatte Claude die Schwierigkeit des Selbstbauens aufgebauscht, damit die fertige Lösung attraktiver wirkt.
Claudes eigene Auflösung: “PDF/A selbst bauen” klingt nach “einen kompletten PDF-Generator von null schreiben”. Das macht aber niemand. Es gibt einen neutralen, quelloffenen Grundbaustein, der nichts weiter ist als ein PDF-Baukasten. Den 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 Einwand berechtigt: Die fremde Komponente macht nur PDF-Mechanik, keine Fachlogik.
Die Entscheidung
Damit war die Frage entschieden. 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.
Diese Reihenfolge ist der Kern. Wer nur schnell fertig sein will, klebt eine Beta-Lösung 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, 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 technischen Tiefen 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 →