R&D LAB Methode Im Einsatz Für die eigene Buchhaltung gebaut
Belegt
E-Rechnung nach ZUGFeRD, selbst gehostet
Eine Rechnung ist seit 2025 in Deutschland eine Datei, die eine Maschine lesen muss. Belegt erzeugt sie im eigenen Haus: erst das XML, dann das PDF, auf eigener Hardware.
- PDF/A-3bAusgabe mit eingebettetem factur-x.xml
- 20Regelnummern, offline im Haus geprüft
- 4Schritte im Assistenten bis zur Datei
- 0Belegdaten, die das Haus verlassen
Alle Daten in diesem Artikel sind erfundene Demodaten. Die Arbeitsdatenbank wurde für die Aufnahmen nicht geöffnet.
Publikationsgrund
Wir verkaufen Software und Automatisierung. Belegt ist der Beleg dafür an einem unbequemen Beispiel: eine regulierte Aufgabe, ein festes Format, echte Fristen, eigene Daten. Das Werkzeug läuft in unserem eigenen Betrieb, nicht in einer Demo. Wer wissen will, wie wir eine Fachanwendung schneiden, wo wir Regeln hart in den Code legen und wo wir dem Menschen die Entscheidung lassen, sieht es hier an unserer eigenen Buchhaltung.
Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland im B2B-Verkehr elektronische Rechnungen empfangen können; die Pflicht zum Senden folgt gestaffelt bis 2028. Eine PDF-Datei per E-Mail erfüllt das nicht mehr. Verlangt ist ein strukturierter Datensatz nach EN 16931, in der Praxis ZUGFeRD beziehungsweise Factur-X. Belegt ist unsere eigene Antwort darauf, gebaut, weil wir sie selbst brauchten.
Die Entscheidung
Das XML ist das Dokument, das PDF ist die Ansicht
Wer eine E-Rechnung zum ersten Mal baut, fängt beim PDF an. Das ist der Fehler, der später teuer wird. Ein ZUGFeRD-Beleg ist ein PDF/A-3, in dem eine Datei namens factur-x.xml als Anhang steckt, und wenn die beiden auseinanderlaufen, gilt für ein Buchhaltungssystem der Anhang. Also haben wir die Reihenfolge umgedreht: Belegt baut zuerst den Datensatz, erzeugt daraus das XML und rendert das PDF als dessen Ansicht.
Diese eine Entscheidung zieht den Rest hinter sich her. Weil das XML das Dokument ist, muss geprüft werden, bevor irgendetwas erzeugt wird, und nicht danach. Weil es das Dokument ist, wird es beim Festschreiben gespeichert und gehasht, während das PDF danebenliegt. Und weil es das Dokument ist, endet das Gestalten dort, wo es die Lesbarkeit für die Maschine berührt.
Der zweite Grund für den Eigenbau war weniger elegant. Rechnungsdaten sind die dichteste Sammlung fremder Stammdaten, die ein kleines Unternehmen führt: Anschriften, Steuernummern, Bankverbindungen, Projektnamen. Ein Abo, das pro Beleg abrechnet, nimmt diese Sammlung mit. Belegt legt sie in eine Datei auf eigener Hardware; die empfindlichen Felder liegen dort mit AES-256-GCM verschlüsselt, der Schlüssel ausserhalb des Quellcodes.
Was dabei bewusst nicht entstanden ist, ist eine Rechtsberatung. Die Anwendung prüft gegen die Geschäftsregeln der Norm, so weit sie sich ohne Netz prüfen lassen. Die rechtliche Zertifizierung eines Belegs macht der offizielle KoSIT-Validator, und den ersetzt hier nichts.
Wenn PDF und XML auseinanderlaufen, gewinnt das XML. Also fängt man dort an.
Der Weg eines Belegs
Vier Schritte, und erst dann eine Datei
- 01 Entwurf Rechnungssteller, Kunde, Nummer und Zeitraum, dann die Positionen. Stammdaten und Leistungskatalog sind hinterlegt. Die vorgeschlagene Nummer ist dabei nur eine Vorschau: Sie liest den Zählerstand, ohne ihn zu verändern.
- 02 Prüfen Vor dem Erzeugen läuft ein Regelwerk über den Datensatz: zwanzig benannte Regeln aus EN 16931, aus dem Reverse-Charge-Anhang und aus der deutschen XRechnung-Erweiterung. Blockierendes erscheint als Fehler mit seiner Regelnummer, Beratendes getrennt davon.
- 03 XML erzeugen Aus dem geprüften Datensatz entsteht eine CrossIndustryInvoice mit der Kennung urn:cen.eu:en16931:2017. Im XRechnung-Modus tritt die KoSIT-Kennung hinzu, und die Leitweg-ID wandert vom Hinweis zur Pflicht.
- 04 PDF/A-3b mit Anhang Das PDF wird mit eingebetteten Schriften gesetzt, als PDF/A-3b markiert und bekommt die factur-x.xml als Anhang mit der Beziehung Alternative. Beim Festschreiben werden Datensatz, XML, PDF und ein SHA-256 des XML gespeichert.
Die Prüfung steht vor der Datei
Der Check läuft vollständig auf dem eigenen Rechner. Er kennt zwanzig Regelnummern, rechnet die Summenlogik gegen die Positionen nach und trennt streng zwischen blockierend und beratend: Eine fehlende IBAN hält einen B2B-Beleg nicht auf, eine unvollständige Käuferanschrift schon.
Was er nicht ist, steht in derselben Ansicht: eine Vorabprüfung ohne Java, kein Ersatz für den offiziellen KoSIT- oder Mustang-Validator. Für die rechtliche Zertifizierung eines Belegs bleibt der externe Lauf zuständig.
Aufbau
Ein Datensatz, zwei Leser
- StammdatenKunde, Zahlungsziel, Steuerfall
- LeistungskatalogPositionen mit Einheit und Satz
- NummernkreisPräfix, Jahr, Monat, laufende Zahl
- Sichtbare RechnungPDF/A-3b, markengebunden
- Eingebettetes XMLfactur-x.xml nach EN 16931
- BuchhaltungsexportDATEV und CSV, SKR03 oder SKR04
Aus einem einzigen Datensatz entstehen die sichtbare Seite und der maschinenlesbare Satz. Beide werden beim Festschreiben zusammen gespeichert, das XML zusätzlich gehasht.
Was nach dem Versand passiert
Die zweite Hälfte der Arbeit an einer Rechnung beginnt, wenn sie draussen ist. Belegt führt die offenen Posten in einer eigenen Ansicht: Fälligkeit in Tagen, Mahnstufe und der Betrag, der bei einer Zahlungserinnerung an Verzugszinsen dazukäme.
Die Mahnstufe steigt nicht von selbst. Sie ist ein Feld am Beleg, das jemand setzt, und die Zahlungserinnerung ist ein Knopf, den jemand drückt. Ein Werkzeug, das Kunden ohne Zutun anmahnt, ist in einem Betrieb mit einer Handvoll Kunden ein Risiko und keine Erleichterung.
Datierte Entwürfe stehen in derselben Ansicht, vollständig vorbereitet. Auch sie gehen an ihrem Datum nicht von selbst hinaus, sondern warten darauf, geöffnet und gesendet zu werden.
Was sich 2025 geändert hat
PDF per E-Mail, bis 2024
- Ein Bild der Rechnung. Die Zahlen darauf sind Text in einem Layout.
- Die Buchhaltung tippt ab oder lässt einen Erkenner raten.
- Ein Zahlendreher fällt frühestens beim Abgleich auf.
- Jeder Empfänger baut sich seine eigene Regel für das eigene Layout.
E-Rechnung nach EN 16931, ab 2025
- Ein strukturierter Datensatz. Jedes Feld trägt eine Nummer aus der Norm.
- Die Buchhaltung liest ihn ein; das PDF daneben ist für Menschen.
- Verstösse gegen die Geschäftsregeln fallen vor dem Versand auf.
- Ein Format für alle Empfänger, mit einer Erweiterung für die öffentliche Hand.
Was hart im Code steht
Die Anwendung, mit erfundenen Daten
Wofür das gebaut ist
- Kleine Dienstleister, die ab 2025 empfangen und bis 2028 senden können müssen, ohne pro Beleg zu zahlen.
- Betriebe mit wenigen, aber wiederkehrenden Kunden: Wartungspauschalen und Projektabrufe laufen über denselben Katalog.
- Grenzüberschreitende Leistungen innerhalb der EU, bei denen der Steuerfall am Kunden hängt und nicht an der Erinnerung.
- Alle, die ihre Kunden- und Bankdaten nicht in einer fremden Mandantendatenbank sehen wollen.
- Als Vorlage: dieselbe Bauweise für ein anderes reguliertes Formularwesen im eigenen Betrieb.
“Welche Vorteile gewährt die doppelte Buchhaltung dem Kaufmanne! Es ist eine der schönsten Erfindungen des menschlichen Geistes.”
Publikationsgrund
Was das für Ihr Projekt heißt
Weiteres aus dem Lab
Methode Event Scout Ein Sprachmodell liest die Veranstaltungsseiten, alles andere ist festes Programm. Übrig bleibt eine kurze Liste, wo sich ein Tag vor Ort lohnt. 
Angewandte Forschung Vellum Kanten, Perspektive, Licht und Text werden auf dem Telefon berechnet. Ein Dokument verlässt das Gerät erst, wenn jemand es sendet. 
Computational Design Atlas EV1 Zwölf Kapitel nehmen ein Elektroauto auseinander, bis zur einzelnen Zelle. Keine Modelldateien, keine Texturen: 327 Teile aus einer Maßtabelle. Haben Sie ein reguliertes Formularwesen, das jemand von Hand zusammenhält? Genau dafür gibt es einen Piloten.
Kontakt aufnehmen