Von der Geschäftslogik bis zur fertigen Datei — in drei Schritten.
Bevor überhaupt eine Datei entsteht, muss die Rechnung auf ein gemeinsames Begriffsgerüst gebracht werden. Die europäische Norm EN 16931 definiert dafür ein Semantic Data Model: einen Katalog von rund 150 sogenannten Business Terms (BT) — standardisierte Felder wie Rechnungsnummer, Steuerbetrag oder Lieferantenadresse — sowie Business Rules (BR), die festlegen, wie diese Felder zusammenhängen und was zwingend enthalten sein muss.
Jedes Land kann auf Basis der EN 16931 eine eigene Einschränkung definieren, eine sogenannte CIUS (Core Invoice Usage Specification). In Deutschland ist das die XRechnung — mit zusätzlichen Pflichtfeldern wie der Leitweg-ID, die im B2G-Verkehr zwingend ist. Im rein nationalen B2B-Verkehr reicht die Konformität mit der EN 16931 selbst aus.
Dieser Schritt ist der häufigste Fehlerursprung: Wer hier Business Terms falsch belegt oder Pflichtfelder übersieht, bekommt beim Validator entsprechende Fehlermeldungen — noch bevor das Format überhaupt eine Rolle spielt.
Aus dem normierten Datenmodell wird nun eine konkrete XML-Datei erzeugt. Die EN 16931 erlaubt dafür zwei Syntaxen.
UN/CEFACT CII (Cross Industry Invoice) — ein internationaler Standard aus dem Handelsbereich. ZUGFeRD und Factur-X basieren ausschließlich auf CII.
OASIS UBL (Universal Business Language) — der im öffentlichen Auftragswesen verbreitete Standard. Peppol BIS Billing nutzt UBL, ebenso eine der zwei offiziellen XRechnung-Syntaxen.
Beide Syntaxen sind normativ gleichwertig — jedes Business Term lässt sich in beiden abbilden. Die Wahl hängt vom Empfänger, der verwendeten Software oder dem Übertragungsweg ab. Ein Validator prüft immer syntaxspezifisch: Eine CII-Datei wird gegen CII-Schematron-Regeln geprüft, eine UBL-Datei gegen UBL-Regeln.
Das fertige XML kann als eigenständige Datei versendet oder in ein PDF/A-3-Dokument eingebettet werden. Genau das ist ZUGFeRD: kein eigenes Datenmodell, sondern ein Verfahren zur Kapselung einer normkonformen CII-XML-Datei in einem nach ISO 19005-3 archivierten PDF-Container.
Das PDF dient dabei ausschließlich der menschenlesbaren Darstellung und der Archivierung. Die rechtlich relevante Rechnung ist das eingebettete XML — das PDF ist Hülle, nicht Inhalt. Deshalb wird beim Validieren einer ZUGFeRD-Datei auch nur das extrahierte XML geprüft, nicht das visuelle Layout des PDFs.
xml-rechnung.eu nimmt E-Rechnungen entgegen, prüft sie gegen den KoSIT-Validator, macht sie lesbar und legt sie acht Jahre unveränderbar ab. Die ersten 10 Dokumente sind geschenkt — ohne Verpflichtungen und ohne Kreditkarte.
Haftungsausschluss: Wir übernehmen keine Gewähr für die Ergebnisse der Validierung und des XML/PDF-Renderers. Die auf dieser Website veröffentlichten Informationen wurden teilweise mit Unterstützung von KI recherchiert und aufbereitet. Trotz sorgfältiger Kontrolle und regelmäßiger Überprüfung können wir keine Haftung für die Richtigkeit, Vollständigkeit oder Aktualität der bereitgestellten Inhalte übernehmen. Wenn Sie Fehler finden oder Verbesserungsvorschläge haben, freuen wir uns über einen Hinweis.
Compliance: Wir validieren gegen den offiziellen KoSIT Validator 1.6.3 mit den Konfigurationen XRechnung 3.0.2 und Peppol BIS 3.0.21. Die Images sind auf Docker Hub veröffentlicht, die Dockerfiles sind auf GitHub einsehbar.
Keine Steuer- oder Buchhaltungsberatung: Wir bieten keine Beratung in Steuer- oder Buchhaltungsfragen an. Bitte wenden Sie sich für solche Fragen an einen Steuerberater oder ein Steuerbüro.
Angebot für Unternehmer: Unser Angebot richtet sich ausschließlich an Unternehmer im Sinne des § 14 BGB — an Gewerbetreibende, Freiberufler und juristische Personen. Ein Vertragsschluss mit Verbrauchern ist nicht vorgesehen. Alle genannten Preise sind Nettopreise und verstehen sich zuzüglich der gesetzlichen Umsatzsteuer.