Leitfaden
Markdown-ExportE‑Rechnung in der EU 2026: was Sie umsetzen sollten (und warum)
In der EU verschiebt sich die Rechnungsstellung von „PDF als Rechnung“ hin zu strukturierten, maschinenlesbaren Daten. Die Details unterscheiden sich je Land, aber die Bausteine sind ähnlich: ein konformes Datenmodell (oft EN 16931), eine Syntax (UBL oder CII), korrekte Identifikatoren und saubere Validierung.
Was „E‑Rechnung“ in der EU praktisch bedeutet
In den meisten EU‑Kontexten ist eine E‑Rechnung nicht nur ein PDF. Es sind strukturierte Rechnungsdaten, die Software verarbeiten und validieren kann (oft XML), manchmal ergänzt durch ein visuelles PDF.
Das ist wichtig für Automatisierung (AP/AR‑Workflows), Compliance (verbindliche Geschäftsregeln) und einen zuverlässigen Austausch zwischen Systemen.
Praxis-Checkliste: Was „E‑Rechnung“ in der EU praktisch bedeutet
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- „Strukturierte Rechnung“ = maschinenlesbare Felder (Käufer, Verkäufer, Summen, USt, Positionen)
- „Syntax“ = wie die Daten kodiert werden (UBL oder CII‑XML)
- „Validierung“ = technische + fachliche Regeln (Schema + Schematron, CIUS‑Regeln)
Standards, die immer wieder auftauchen
EN 16931 ist das zentrale semantische Modell hinter vielen EU‑E‑Rechnungsumsetzungen. Es definiert die Bedeutung der Rechnungsdaten (Business Terms) – nicht nur die technische Kodierung.
Zwei verbreitete XML‑Syntaxen sind UBL (OASIS) und CII (UN/CEFACT). Länder und Netzwerke definieren häufig zusätzlich eine CIUS, die Regeln und Codelisten verschärft.
Praxis-Checkliste: Standards, die immer wieder auftauchen
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- EN 16931 (semantisches Modell)
- UBL (Syntax)
- CII (Syntax)
- CIUS (Länder-/Netzwerkregeln)
- ZUGFeRD/Factur‑X (PDF + eingebettetes XML)
Zustellmodelle: PEPPOL vs Portale vs Clearance (CTC)
Einige Länder setzen auf Netzwerkaustausch (4‑Corner via PEPPOL), andere auf nationale Portale, und wieder andere auf Clearance/CTC‑Modelle, bei denen Rechnungen vor Zustellung über eine Plattform gemeldet oder freigegeben werden müssen.
Aus Implementierungssicht sollten Sie „Datenkorrektheit“ von „Kanal‑Integration“ trennen. Ein EN‑16931‑Mapping lässt sich oft über mehrere Kanäle wiederverwenden.
Praxis-Checkliste: Zustellmodelle: PEPPOL vs Portale vs Clearance (CTC)
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- PEPPOL (4‑Corner): Adressierung über Participant IDs; Access Points routen Rechnungen
- Portale: Upload/API zu einer Behörden‑ oder Branchenplattform
- Clearance/CTC: Plattform‑Bestätigung kann Teil der rechtlichen Rechnungsausstellung sein
Identifikatoren und Stammdaten: wo Projekte scheitern
Die meisten Validierungsfehler sind keine „XML‑Probleme“, sondern Stammdaten‑Probleme: fehlende Adressen, inkonsistente USt‑Angaben, falsche Käuferreferenzen oder ungültige Codelistenwerte.
Behandeln Sie Codelisten (Währung, Einheiten, USt‑Kategorien, Zahlungsarten) als Teil Ihres Produkts – nicht nur als Doku.
Praxis-Checkliste: Identifikatoren und Stammdaten: wo Projekte scheitern
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- Verkäufer-/Käufer‑IDs und Adressvollständigkeit sauber normalisieren
- Codelisten bereits bei Eingabe prüfen (nicht erst beim XML‑Export)
- Rundung und USt‑Aufteilung konsistent umsetzen
Validierung: Schema vs Geschäftsregeln (und warum beides zählt)
Eine Datei kann wohlgeformtes XML sein und trotzdem abgelehnt werden. Validatoren prüfen meist mehrere Ebenen: XML‑Schema (Struktur), Schematron (Regeln) und ggf. Netzwerk-/Länderprofile.
Planen Sie schnelle Feedback‑Loops: früh validieren, Fehler in der UI sichtbar machen und das validierte XML als reproduzierbares Artefakt speichern.
Praxis-Checkliste: Validierung: Schema vs Geschäftsregeln (und warum beides zählt)
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- Schemafehler = fehlende/ungültige Elemente
- Schematronfehler = fachliche Regeln (z. B. USt‑Aufteilung)
- Profilfehler = CIUS-/Netzwerkvorgaben
Implementierungs‑Checkliste (für Fachbereich und Entwicklung)
Ein erfolgreicher Rollout hängt weniger vom XML‑Erzeugen ab als von konsistenten, validierten Rechnungsdaten.
Nutzen Sie diese Checkliste als Reihenfolge‑Leitfaden – die meisten Teams durchlaufen sie mehrfach iterativ.
Praxis-Checkliste: Implementierungs‑Checkliste (für Fachbereich und Entwicklung)
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- Zielländer/-kanäle definieren (PEPPOL, Portal, Clearance) und Rechnungsarten festlegen
- Datenmodell auf EN 16931 (oder CIUS) mappen und UBL vs CII entscheiden
- Identifikatoren (Käuferreferenzen, Routing‑IDs) und Codelisten (Währung, Einheit, USt‑Kategorie, Zahlungsart) festlegen
- XML erzeugen und lokal validieren, bevor irgendwohin gesendet wird
- End‑to‑End mit realistischen Rechnungen testen (Rabatte, USt‑Sätze, Mischpositionen, Rundung)
- Betrieb: Fehlerhandling, Retries, Audit‑Trails, Speicherung und Abruf gesendeter Rechnungen