E-Rechnung 2028 Teil 3: Konformität baut man ein, nicht drauf
Teil 2 endete mit einer Entscheidung und einer offenen Frage. Die Entscheidung: das Paket selbst bauen, allgemein, statt eine fremde Beta-Bibliothek anzukleben. Die Frage: Geht das überhaupt? Kann man Konformität selbst herstellen, ohne ein halbes Jahr in PDF-Interna zu versinken?
Die kurze Antwort ist ja. Aber nur, wenn man von der richtigen Seite anfängt.
Konformität ist kein Stempel
Der häufigste Denkfehler bei E-Rechnungen ist, sich Konformität wie einen Prüfstempel vorzustellen, den man zum Schluss auf ein fertiges Dokument drückt. So funktioniert es nicht. Konformität ist eine Eigenschaft des ganzen Dokuments, nicht ein Schritt, den man zuletzt ausführt.
Ein PDF gilt nur dann als archivtauglich nach der Norm PDF/A-3, wenn alles zusammenpasst: jede Schriftart vollständig eingebettet, jede Farbe geräteunabhängig definiert, keine der vielen verbotenen Konstruktionen enthalten. Ein einziger nicht eingebetteter Buchstabe, und der amtliche Prüfer sagt nein. Ein unsauberes PDF lässt sich nicht nachträglich sauber stempeln. Man muss es von der ersten Zeile an sauber erzeugen.
Das ist der ganze Ansatz, auf Englisch compliant by construction: nicht hinterher reparieren, sondern von Grund auf richtig bauen. Es ist auch der Grund, warum die fertigen Bibliotheken aus Teil 2 genau hier ins Schwimmen kommen. Sie nehmen oft ein beliebiges PDF entgegen und versuchen, es nachträglich konform zu biegen. Das ist die schwere, unzuverlässige Richtung.
Vier Bausteine
Wenn man das PDF selbst und von Anfang an konform erzeugt, zerfällt das große, einschüchternde Problem in vier überschaubare Bausteine, jeder mit einer klaren Aufgabe:
- Das Modell. Ein einziger, sauber definierter Datensatz, der eine Rechnung beschreibt: Nummer, Datum, Posten, Beträge, Steuer. Alles Weitere ist nur eine Umformung davon.
- Das XML. Aus dem Modell entsteht der maschinenlesbare Datensatz im vorgeschriebenen Format. Das ist der Teil, den die Buchhaltungssoftware des Empfängers liest.
- Das PDF. Aus demselben Modell entsteht das sichtbare Dokument, von der ersten Zeile an nach den PDF/A-Regeln gebaut. Gezeichnet wird es mit einem neutralen Grundbaustein, dem Reißverschluss aus Teil 2; die ganze Konformitäts-Logik darüber ist eigener Code.
- Die Verschmelzung. XML und PDF werden zu einer Datei verbunden, mit der eingebauten Garantie, dass beide dasselbe sagen. Bei Abweichung zählt, wie in Teil 1 erwähnt, das XML.
Darunter liegt noch eine fünfte Schicht, die eigentliche Prüfung. Die ist das Thema von Teil 4.
Dieser Aufbau kommt ohne schwere Java-Laufzeit und ohne Ghostscript aus. Das ist kein Selbstzweck: Es bedeutet, dass die Engine auch in einer schlanken Cloud-Umgebung läuft, dort, wo auch das Portal lebt. Genau die Eigenschaft, die die fertigen Bibliotheken für den heiklen Teil nicht zusichern konnten.
Erst der grüne Kern
Vier Bausteine, zwei XML-Formate, mehrere ZUGFeRD-Profile, dazu die reine XRechnung: Das ist viel auf einmal. Der Fehler wäre, alles gleichzeitig anzufangen und am Ende nichts Fertiges zu haben.
Die Reihenfolge, die das verhindert, kam von Claude: zuerst ein einziger, schmaler, wasserdicht konformer Kern. Eine echte Rechnung, ein Format, ein Profil, vollständig grün durch die amtlichen Prüfer. Erst wenn dieser Kern steht, kommt die Breite dazu, Schicht für Schicht, jede gegen dieselben Prüfer abgesichert.
Der Unterschied dahinter ist der zwischen „funktioniert nachweislich für einen echten Fall“ und „sollte eigentlich für alles funktionieren“. Bei einer Gesetzespflicht will man das Erste.
Der ehrlichste Commit
Ein Moment aus dem Bau ist mir geblieben. Der konforme Kern war fertig, der Prüf-Mechanismus verdrahtet, aber der eigentliche Prüflauf lief technisch noch nicht; eine störrische Komponente auf dem Entwicklungsrechner wollte nicht starten.
An dieser Stelle hätte man bequem „fertig, grün“ in die Versionsgeschichte schreiben können. Claude tat das nicht. Der Commit hielt ausdrücklich fest: Prüfung verdrahtet, Lauf steht aus, kein Grün-Versprechen. Erst Stunden später, als der Prüfer wirklich durchlief und wirklich grün meldete, wurde daraus ein Grün.
Bei Software, die eine gesetzliche Pflicht erfüllen soll, ist der Unterschied zwischen „sieht grün aus“ und „der amtliche Prüfer sagt grün“ der ganze Punkt. Wer das eine fürs andere ausgibt, baut eine Zeitbombe.
Wer hier was gebaut hat
Ich habe diese Engine nicht Zeile für Zeile selbst getippt. Gebaut hat sie Claude, unter meiner Vorgabe und gegen meine Prüfung. Von mir kam die Richtung und der Maßstab: von Grund auf konform, gegen die amtlichen Prüfer, kein Grün ohne Beweis. Claude kam mit der Architektur und der Reihenfolge.
Die Kompetenz steckt bei dieser Art zu arbeiten nicht mehr nur im Tippen, sondern darin, den richtigen Weg vorzugeben und das Ergebnis hart genug zu prüfen. „Ich habe das gebaut“ trifft es nicht mehr.
Damit ist die Frage aus Teil 2 beantwortet: Ja, man kann Konformität selbst herstellen, ohne im PDF-Sumpf zu versinken. Nicht, indem man alles neu erfindet, sondern indem man das Dokument von Anfang an richtig erzeugt und die heikle Logik selbst kontrolliert, statt sie an eine fremde Bibliothek abzugeben.
Bleibt der letzte und wichtigste Punkt. „Von Grund auf konform gebaut“ ist eine schöne Behauptung. Woher weiß ich, dass sie stimmt? Darum geht es in Teil 4.
Teil 3 von 4 der E-Rechnung 2028 Serie.
← E-Rechnung 2028 Teil 2: Fertige Lösung einbauen, oder selbst bauen? | E-Rechnung 2028 Teil 4: Woher ich weiß, dass es wirklich konform ist →
Die Engine aus dieser Serie gibt es als Projekt: Rechenwerk.