Auf dieser Seite
- Was „E‑Rechnung“ in der EU praktisch bedeutet
- Standards, die immer wieder auftauchen
- Zustellmodelle: PEPPOL vs Portale vs Clearance (CTC)
- Identifikatoren und Stammdaten: wo Projekte scheitern
- Validierung: Schema vs Geschäftsregeln (und warum beides zählt)
- Implementierungs‑Checkliste (für Fachbereich und Entwicklung)
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.
- „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.
- 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.
- 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.
- 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.
- 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.
- 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