Seit dem 1. Januar 2025 muessen alle inlaendischen Unternehmen E-Rechnungen empfangen koennen. Versenden ist gestaffelt: ab 01.01.2027 fuer Umsaetze ueber 800.000 EUR, ab 01.01.2028 fuer alle B2B. PDF allein reicht nicht mehr — gefordert ist strukturiertes XML. Trotzdem laufen 2026 noch viele Buchhaltungen weiter wie gewohnt: PDF generieren, per E-Mail senden, fertig. Das wird teuer. Dieser Artikel erklaert, was eine echte E-Rechnung ist und wie man sie technisch sauber generiert und archiviert.
Was ist eine E-Rechnung im Sinne des Gesetzes?
Eine E-Rechnung im Sinne des Wachstumschancengesetzes (Art. 23) ist eine Rechnung in einem strukturierten elektronischen Format, das eine maschinelle Verarbeitung ermoeglicht. PDF-Dateien sind keine E-Rechnungen — auch nicht, wenn sie elektronisch verschickt werden. In Deutschland gelten zwei Formate:
- XRechnung: reines XML, Standard im B2G-Bereich (Behoerden), funktioniert auch B2B.
- ZUGFeRD ab Profil EN 16931: Hybrid-Format — eine PDF mit eingebetteter XML-Datei. Menschen sehen das PDF, Software liest die XML.
Beide muessen die EN-16931-Pflichtfelder erfuellen und gegen den KoSIT-Validator pruefbar sein. Ohne korrekte E-Rechnung kein Vorsteuerabzug — das wird in den Pruefungen 2027 ein scharfes Schwert.
XRechnung oder ZUGFeRD?
Die Frage kommt in jedem Compliance-Audit. Meine Antwort: ZUGFeRD ab Profil EN 16931, ausser es gibt einen guten Grund dagegen.
Warum: ZUGFeRD ist ein PDF mit eingebettetem XML. Das hat zwei Vorteile:
- Lesbar fuer Menschen: Wenn der Empfaenger noch keine vollautomatische Verarbeitung hat, kann er die Rechnung als PDF einfach oeffnen.
- Lesbar fuer Maschinen: Eine moderne Buchhaltung (DATEV, lexware, sevDesk) extrahiert die XML automatisch.
XRechnung ist puristisch besser — kein Mensch sieht das XML, alles wird automatisch verarbeitet. Aber das setzt voraus, dass der Empfaenger eine Software hat, die XRechnung versteht. In B2B-Praxis ist das 2026 noch nicht ueberall der Fall. ZUGFeRD ueberbrueckt die Uebergangsphase.
Pflichtfelder und Validierung
Die EN 16931 schreibt eine Reihe Pflichtfelder vor. Auszug:
- Rechnungsnummer (eindeutig, fortlaufend)
- Rechnungsdatum
- Leistungs-/Lieferdatum
- USt-ID des Verkaeufers (DE12345...)
- Steuersaetze pro Position (0 %, 7 %, 19 %)
- Bestellnummer/Auftragsbezug (Pflicht im B2G, dringend empfohlen B2B)
- Bankverbindung des Verkaeufers (IBAN, BIC)
- Skontoangaben in strukturierten Feldern (NICHT als Freitext!)
Validierung passiert mit dem KoSIT-Validator — das offizielle Tool des Bundes. Ich integriere die Schematron-Pruefung in den Versand-Pfad: keine Rechnung verlaesst das System, ohne validiert zu sein.
from kosit_validator import validate_xrechnung
def send_invoice(xml: bytes, recipient_email: str):
result = validate_xrechnung(xml, profile="EN16931")
if not result.is_valid:
raise ValueError(f"E-Rechnung ungueltig: {result.errors}")
# Erst nach erfolgreicher Validierung versenden
send_email_with_attachment(recipient_email, xml, "rechnung.xml")
archive_invoice(xml, hash=hashlib.sha256(xml).hexdigest())
GoBD-konformes Archiv
E-Rechnungen muessen 8 Jahre unveraendert aufbewahrt werden — nach den GoBD-Grundsaetzen (Grundsaetze ordnungsgemaesser DV-gestuetzter Buchfuehrungssysteme). Original ist die XML-Datei, nicht ein PDF-Druck. Wer die XML wegwirft und nur die PDF behaelt, hat das Original verloren.
Mein Standard-Setup: Supabase Storage Bucket mit Schreibschutz nach dem ersten Upload, plus ein Hash-Lock in einer separaten Tabelle:
CREATE TABLE invoice_archive (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
invoice_no TEXT UNIQUE NOT NULL,
storage_path TEXT NOT NULL, -- Supabase Storage URL
sha256 TEXT NOT NULL, -- Hash der Original-XML
format TEXT NOT NULL CHECK (format IN ('xrechnung', 'zugferd')),
archived_at TIMESTAMPTZ DEFAULT NOW(),
retention_until DATE NOT NULL -- archived_at + 8 years
);
Bei einer Aenderung muss eine Storno-Rechnung erstellt werden, gefolgt von einer neuen Rechnung — kein Editieren des Originals. Der Hash beweist, dass die archivierte Version nicht veraendert wurde.
Empfangs-Workflow
Eingehende E-Rechnungen laufen in eine dedizierte E-Mail-Inbox (z.B. `rechnungen@deinedomain.de`). Ein Cron-Job zieht die Anhaenge regelmaessig ab, validiert sie und legt sie im Archiv ab. Bei Fehlern (XML ungueltig, Pflichtfelder fehlen) bekommt der Buchhalter eine Benachrichtigung mit dem konkreten Mangel.
Was ich konkret mache
Bei einem E-Rechnungs-Setup fuer dein Projekt liefere ich: einen E-Rechnungs-Generator (XRechnung 3.0.x oder ZUGFeRD 2.3+), Validierung gegen KoSIT vor jedem Versand, GoBD-konformes Archiv mit Hash-Lock in Supabase Storage, einen Empfangsweg per E-Mail-Inbox plus XML-Parsing, Integration mit DATEV-Export oder vorhandenem ERP, und ein Status-Dashboard fuer empfangene/versendete/abgelehnte Rechnungen.
Mehr unter /compliance/e-rechnung.
