eRechnung Studio

Hintergrund

Seit dem 1. Januar 2025 muss jedes Unternehmen in Deutschland strukturierte E-Rechnungen nach der europäischen Norm EN 16931 empfangen können. Das Ausstellen wird in den kommenden Jahren schrittweise Pflicht. Für kleine Unternehmen wirft das vier praktische Fragen auf: Wie erstelle ich eine gültige XRechnung? Was mache ich mit der XML-Datei, die mir ein Lieferant gerade geschickt hat? Ist sie überhaupt gültig? Und wie archiviere ich sie?

eRechnung Studio beantwortet alle vier in einer Web-App, aufgebaut als mandantenfähige SaaS-Anwendung für kleine und mittlere Unternehmen.

Rechnungen schreiben

Der Editor kennt Kunden, Produkte und die gängigen Steuerfälle: 19 % und 7 % USt., Reverse Charge (§13b UStG), innergemeinschaftliche Lieferung und Kleinunternehmerregelung (§19 UStG). Exportiert wird als XRechnung (UBL 2.1 oder UN/CEFACT CII) oder als ZUGFeRD, also als PDF/A-3 für Menschen mit eingebettetem XML für Software.

Rechnungsnummern wie RE-2026-00042 müssen lückenlos sein. Eine Nummer wird erst beim Finalisieren vergeben, in einer Transaktion mit Sperre auf dem Zähler des Mandanten. Entwürfe verbrauchen also keine Nummer. Ein Test schickt 100 parallele Finalisierungen und erwartet 100 eindeutige, fortlaufende Nummern. Beträge werden in Cent gespeichert und pro Position und Steuersatz nach den Rechenregeln der EN 16931 (BR-CO-*) gerundet.

Empfangen und prüfen

Eingehende Rechnungen lassen sich als XML oder ZUGFeRD-PDF hochladen oder an eine eigene Postfach-Adresse pro Mandant weiterleiten. Die App erkennt das Format und zeigt das rohe XML als lesbare Rechnung an.

Geprüft wird mit dem offiziellen KoSIT-Validator, statt Hunderte Schematron-Regeln nachzubauen. Seine Regel-IDs sind einem Fehlerkatalog auf Deutsch und Englisch zugeordnet, und das betroffene Feld wird hervorgehoben. Aus dieser Meldung:

BR-DE-15: Buyer reference (Leitweg-ID) is missing

wird „Der Kunde verlangt eine Käuferreferenz. Ergänzen Sie sie unter Kunde → Rechnungsstellung.“

In der Praxis geht es bei E-Rechnungen vor allem um Datenqualität. Das XML zu schreiben ist einfach. Schwierig ist, dass vor dem Export jedes Pflichtfeld stimmt.

Technik

1. React-AppEditor · Posteingang · Archiv
3. NestJS-APIREST · API-Schlüssel
5. BullMQ-Workererzeugen · prüfen · auslesen
7. KoSIT-ValidatorXSD + Schematron
9. PostgreSQL + S3RLS pro Mandant

Alle Formate werden in ein internes Rechnungsmodell übersetzt und zurück, das auf dem semantischen Modell der EN 16931 aufbaut (Business Terms BT-*, Gruppen BG-*). Ein neues Ausgabeformat bedeutet einen neuen Mapper, ohne die Geschäftslogik anzufassen. Round-Trip-Tests gegen die offizielle XRechnung-Testsuite finden Mapping-Fehler, die Unit-Tests übersehen.

Das Archiv orientiert sich an den GoBD. Finalisierte Rechnungen lassen sich auf Datenbankebene nicht ändern, Korrekturen sind neue Datensätze mit Verweis auf das Original. Jedes Dokument bekommt einen SHA-256-Hash, der mit dem vorherigen verkettet ist, und ein Audit-Log hält fest, wer wann was getan hat. Die Mandanten sind per PostgreSQL Row-Level Security getrennt, sodass eine vergessene WHERE-Bedingung keine Rechnungen eines anderen Unternehmens preisgeben kann.

Über eine REST-API und Webhooks können Onlineshops, ERP-Systeme und n8n-Workflows E-Rechnungen automatisch erstellen und empfangen.

Ein Portfolio-Projekt auf Basis veröffentlichter technischer Standards. Keine Steuer- oder Rechtsberatung.