E-Rechnung 2028 Teil 4: Woher ich weiß, dass es wirklich konform ist
Teil 3 endete mit einer Behauptung: Ich hätte die Engine von Grund auf konform gebaut. Das ist leicht gesagt. Bei einer gesetzlichen Pflicht zählt aber keine Behauptung, sondern der Beweis. Dieser letzte Teil handelt nur davon. Woher weiß ich, dass es wirklich stimmt?
Jeder kann „konform“ behaupten
Das Vertrauensproblem bei E-Rechnungen ist simpel und unangenehm. Ein PDF, das konform aussieht, und ein PDF, das konform ist, sehen für das menschliche Auge gleich aus. Der Unterschied zeigt sich erst, wenn die Buchhaltung des Empfängers oder eine Betriebsprüfung die Datei maschinell durchleuchtet. Dann ist es zu spät, ihn noch zu reparieren.
Ehrlich lösen lässt sich das nur, indem man den Beweis nicht selbst führt. Wer seine eigene Arbeit prüft, findet erfahrungsgemäß wenig. Also prüfen drei fremde, etablierte Werkzeuge.
Drei Prüfer, die ich nicht kontrolliere
Das Entscheidende an diesen dreien: Ich habe sie nicht geschrieben, ich kann sie nicht beeinflussen, und sie haben keinen Grund, mir entgegenzukommen. Fällt mein PDF bei veraPDF durch, fällt es durch. Genau das macht ein grünes Ergebnis zu einem Beweis und nicht zu einer Behauptung.
Erst fragen, dann bauen
Für jedes neue Feld in einer Rechnung, jeden Rabatt, jede Zahlungsart, wurde nicht erst gebaut und dann gehofft. Es lief umgekehrt: zuerst schrieb ich ein winziges Beispiel von Hand im exakten Zielformat und schickte es durch die Prüfer. Erst wenn die grün meldeten, stand fest, wie das Feld auszusehen hat. Danach erst kam der Code, der es automatisch erzeugt, geschrieben von Claude Code.
Das klingt nach einem Umweg, ist aber das Gegenteil. Es bedeutet, dass nie etwas gebaut wurde, von dem nicht vorher feststand, dass der Prüfer es akzeptiert. Bei einer Norm mit hunderten Detailregeln ist das der Abstand zwischen „müsste passen“ und „geprüft, passt“.
Nicht nur die einfache Rechnung
Ein Konformitätsbeweis für eine Rechnung mit zwei Posten wäre wenig wert. Echte Rechnungen sind unordentlicher. Deshalb deckt die Engine inzwischen ab, was im Alltag wirklich vorkommt:
- mehrere Steuersätze und Steuerbefreiungen, auch Reverse-Charge
- Rabatte und Zuschläge, auf die ganze Rechnung wie auf einzelne Posten
- Brutto-Preise, wie der Kunde sie sieht, bei netto-korrektem Datenkern
- Anzahlungen und Rundungsbeträge
- SEPA-Überweisung und SEPA-Lastschrift mit Mandat
- die reine XRechnung in beiden zulässigen XML-Dialekten, mit der Leitweg-ID für Rechnungen an Behörden
Jedes dieser Felder ist einzeln gegen die drei Prüfer abgesichert. Der Stand heute: über hundert automatische Tests und dreißig von dreißig Konformitätsprüfungen grün. Nicht „sollte gehen“. Grün.
Gegen den eigenen Code antreten
Grün heißt noch nicht fertig. Mehrfach habe ich Claude Code den eigenen Code gezielt angreifen lassen, mit einer einzigen Frage: Wo bricht das, wenn jemand absichtlich seltsame, aber zulässige Eingaben schickt? Was dabei auffiel, haben wir gehärtet, bevor es draußen jemand findet. Diese feindselige Selbstprüfung ist genau der Schritt, den eine schnell zusammengeklebte Lösung überspringt.
Aus der Engine wird Rechenwerk
Aus dem „eigenen Paket“ von Teil 2 war eine fertige Sache geworden, und fertige Sachen brauchen einen Namen. Die Wahl fiel auf Rechenwerk, den rechnenden Teil einer Maschine, fast wörtlich das, was die Engine in diesem Stack tut. Der Name war kurz, und er passte.
Dazu eine Lizenz, und die ist eine bewusste Weichenstellung: AGPL. Sie hält die Software offen, jeder darf sie nutzen und verändern, lässt mir aber die Tür offen, sie kommerziell auch anders anzubieten. Das ist die unaufgeregte, ehrliche Variante von „quelloffen, aber ich habe auch Rechnungen zu zahlen“.
Was als Nebenfrage in einem Kundenprojekt anfing, ist damit eine vollständige Antwort geworden: die Pflicht verstanden, bewusst mit Claude Code gebaut statt zugekauft, von Grund auf konform konstruiert, und gegen drei unabhängige amtliche Prüfer bewiesen.
Rechenwerk ist das Werkzeug. Was ich anbiete, ist die Lösung dahinter: dass die Pflicht-Rechnung in einem Betrieb am Ende einfach funktioniert und nachweisbar konform ist. Mehr dazu auf der Referenz-Seite oder direkt an [email protected].
Teil 4 von 4 der E-Rechnung 2028 Serie.
← E-Rechnung 2028 Teil 3: Konformität baut man ein, nicht drauf