E-Rechnung XML Datei erstellen: Technischer Leitfaden für XRechnung

Kurz & knapp: Eine XRechnung ist eine XML-Datei nach der europäischen Norm EN 16931, die entweder in UBL- oder in CII-Syntax vorliegen kann. Für die Erstellung braucht es korrekte Namensräume, alle Pflichtfelder gemäß Schema sowie eine Validierung, üblicherweise mit dem Validator der KoSIT. Für Unternehmen mit Entwicklungsressourcen bietet sich die programmatische Generierung über Bibliotheken oder APIs an, statt jede Datei manuell zu pflegen.

Zielgruppe und Abgrenzung dieses Leitfadens

Dieser Artikel richtet sich an Entwickler, IT-Verantwortliche und technisch versierte Unternehmer, die verstehen möchten, wie eine XRechnung als XML-Datei tatsächlich aufgebaut ist und wie sich die Erstellung programmatisch automatisieren lässt. Für Nutzer, die einfach nur schnell und ohne technisches Vorwissen eine Rechnung erstellen wollen, sind fertige Werkzeuge wie Online-Generatoren oder Buchhaltungssoftware die bessere Wahl – diese werden im Artikel E-Rechnung kostenlos erstellen behandelt. Hier geht es dagegen um die Datenstruktur selbst, um Schema-Validierung und um die Frage, wie sich die Erzeugung in eigene Systeme integrieren lässt.

Rechtlicher und normativer Rahmen

Mit dem Wachstumschancengesetz definiert §14 UStG die E-Rechnung als strukturierte elektronische Rechnung im Format der EN 16931 oder einem dazu kompatiblen Format. Seit dem 1.1.2025 besteht die nationale Empfangspflicht, ab dem 1.1.2027 die Ausstellungspflicht für Unternehmen mit einem Vorjahresumsatz über 800.000 Euro, ab dem 1.1.2028 dann universell. Die deutsche XRechnung ist ein von der KoSIT (Koordinierungsstelle für IT-Standards) definiertes, national verbindliches Anwendungsprofil („Core Invoice Usage Specification“, CIUS) der EN 16931, das die europäische Norm um deutsche Detailanforderungen konkretisiert, etwa bezüglich Leitweg-ID bei öffentlichen Auftraggebern.

UBL versus CII: Die zwei zulässigen Syntaxen

Die EN 16931 legt kein einzelnes XML-Vokabular fest, sondern erlaubt zwei alternative Syntaxen, die beide als gültig gelten. UBL (Universal Business Language) ist ein von OASIS entwickelter, breit genutzter Standard für Geschäftsdokumente und in der Praxis die häufiger anzutreffende Syntax für XRechnungen. CII (Cross Industry Invoice) stammt aus dem UN/CEFACT-Umfeld und wird unter anderem von ZUGFeRD als zugrunde liegendes XML-Vokabular verwendet. Beide Syntaxen bilden dieselben inhaltlichen Anforderungen der EN 16931 ab, unterscheiden sich aber in Elementnamen, Verschachtelung und Namensräumen erheblich. Für die Praxis bedeutet das: Eine Software oder Bibliothek, die UBL erzeugt, kann nicht ohne Weiteres CII-Dateien lesen oder umgekehrt, ohne eine explizite Transformation vorzunehmen.

Grundstruktur einer UBL-XRechnung

Eine UBL-basierte XRechnung beginnt mit dem Wurzelelement Invoice innerhalb des Namensraums urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, ergänzt um die Customization-ID, die auf das XRechnung-Profil verweist. Darauf folgen Pflichtblöcke wie AccountingSupplierParty und AccountingCustomerParty für Verkäufer und Käufer inklusive Steuernummer, InvoiceLine-Elemente für jede Rechnungsposition mit Menge, Einzelpreis und Artikelbeschreibung, sowie TaxTotal- und LegalMonetaryTotal-Blöcke für Umsatzsteuer und Gesamtsummen. Jedes dieser Elemente folgt einer festen Reihenfolge und einem festen Datentyp, etwa müssen Beträge als Dezimalzahl mit definierter Nachkommastellenzahl und zugehörigem Währungscode-Attribut angegeben werden.

Grundstruktur einer CII-XRechnung

Die CII-Syntax organisiert dieselben Inhalte anders: Das Wurzelelement CrossIndustryInvoice enthält die drei Hauptblöcke ExchangedDocumentContext, ExchangedDocument und SupplyChainTradeTransaction. Innerhalb von SupplyChainTradeTransaction finden sich wiederum die Handelsparteien, die einzelnen Rechnungspositionen als IncludedSupplyChainTradeLineItem sowie die steuerlichen und monetären Summenblöcke. Wer von UBL kommt, muss sich an eine deutlich andere Verschachtelungslogik gewöhnen, auch wenn inhaltlich dieselben Pflichtangaben – Steuernummern, Steuersätze, Nettobeträge, Zahlungsbedingungen – gefordert sind.

Pflichtfelder nach EN 16931 im Überblick

Validierung mit dem KoSIT-Validator

Nach der Erstellung einer XML-Datei ist die Validierung gegen das offizielle Schema unerlässlich. Die KoSIT stellt dafür ein Validator-Werkzeug samt Regelwerk bereit, das sowohl UBL- als auch CII-Dateien gegen die XRechnung-Spezifikation prüft. Der Validator kombiniert eine XSD-Schemaprüfung (formale Struktur, Datentypen, Pflichtfelder) mit Schematron-Regeln (fachliche Geschäftsregeln, etwa dass sich Summen korrekt aus den Einzelpositionen ergeben müssen). Für die Integration in eigene Build- oder Deployment-Pipelines lässt sich der Validator häufig als Kommandozeilenwerkzeug oder über eine Java-Bibliothek einbinden, sodass jede erzeugte Rechnung automatisiert vor dem Versand geprüft wird.

Programmatische Erstellung: Bibliotheken und APIs

Für Unternehmen mit eigenem Rechnungsvolumen lohnt sich selten das manuelle Schreiben einzelner XML-Dateien. Stattdessen bieten sich mehrere technische Ansätze an: Erstens Open-Source-Bibliotheken in Sprachen wie Java, PHP oder .NET, die ein Objektmodell für Rechnungsdaten bereitstellen und daraus automatisch valides UBL- oder CII-XML serialisieren. Zweitens kommerzielle APIs, bei denen Rechnungsdaten per HTTP-Aufruf als JSON übermittelt und als fertige, validierte XRechnung oder ZUGFeRD-Datei zurückgegeben werden – praktisch für die Integration in bestehende ERP- oder Warenwirtschaftssysteme. Drittens XSLT-Transformationen, mit denen sich aus einem bereits vorhandenen internen Datenformat automatisiert eine EN-16931-konforme Zieldatei erzeugen lässt.

Praxisbeispiel: Automatisierte Rechnungserzeugung in einem ERP-System

Ein mittelständisches Unternehmen mit angebundenem ERP-System integriert eine XRechnung-Bibliothek direkt in seinen Fakturierungsprozess. Bei Rechnungsstellung übergibt das ERP-System die relevanten Felder – Kundendaten, Positionen, Steuersätze, Zahlungsziel – an die Bibliothek, die daraus automatisch eine UBL-konforme XRechnung generiert. Vor dem Versand durchläuft die Datei automatisiert den KoSIT-Validator als Teil der Verarbeitungspipeline; nur bei erfolgreicher Validierung wird die Rechnung tatsächlich verschickt und revisionssicher archiviert. Fehlerhafte Datensätze werden stattdessen an eine Fehlerwarteschlange zur manuellen Prüfung weitergeleitet, statt fehlerhafte Rechnungen automatisch zu versenden.

Checkliste für die technische Implementierung

• Für welche Syntax entscheiden Sie sich, UBL oder CII, und passt das zu den Anforderungen Ihrer Hauptkunden?
• Nutzen Sie eine gepflegte Bibliothek oder API, statt XML-Erzeugung komplett selbst zu programmieren?
• Ist der KoSIT-Validator fest in Ihre Erzeugungs- oder Versandpipeline integriert?
• Werden alle Pflichtfelder nach EN 16931 korrekt und vollständig befüllt, inklusive Steuernummern und Leitweg-ID bei Bedarf?
• Ist die Zeichenkodierung der Datei korrekt auf UTF-8 gesetzt, um Sonderzeichen fehlerfrei darzustellen?
• Werden Schema-Updates der KoSIT beobachtet und zeitnah in die eigene Implementierung übernommen?

Häufige technische Fehler

Ein häufiger Fehler ist das Mischen von UBL- und CII-Elementen innerhalb einer Datei, meist durch kopierten Beispielcode aus unterschiedlichen Quellen. Ein zweiter häufiger Fehler betrifft falsche Nachkommastellen oder fehlende Währungscode-Attribute bei Beträgen, was zu Schematron-Fehlern führt, obwohl die grundlegende XSD-Struktur formal korrekt ist. Ein dritter, subtilerer Fehler ist eine falsche oder fehlende Verknüpfung zwischen Rechnungspositionen und dem berechneten Steuertotal, die zwar strukturell valide erscheinen kann, aber gegen die fachlichen Geschäftsregeln der Schematron-Prüfung verstößt und deshalb zurückgewiesen wird.

Edge Cases: Gutschriften, Stornos und Sammelrechnungen

Neben der klassischen Rechnung sieht die EN 16931 auch strukturierte Formen für Gutschriften (CreditNote) und Rechnungskorrekturen vor, die eigene, wenn auch strukturell ähnliche Elementtypen verwenden. Bei Sammel- oder Teilrechnungen mit mehreren Referenzen auf vorangegangene Bestellungen oder Lieferscheine sind zusätzliche optionale Elemente wie Verweise auf Bestellnummern (BuyerReference) oder Lieferantennummern relevant, die je nach Kundenanforderung korrekt befüllt werden müssen. Wer solche Sonderfälle programmatisch abdecken will, sollte frühzeitig in der Implementierung testen, ob die verwendete Bibliothek diese erweiterten Elementtypen unterstützt.

Namensräume und Schemaversionen korrekt verwalten

Ein oft unterschätzter technischer Stolperstein ist die korrekte Deklaration der XML-Namensräume. Sowohl UBL als auch CII referenzieren mehrere verschachtelte Namensräume gleichzeitig, etwa für die Kernstruktur, für Zahlungsangaben (cbc, cac bei UBL) oder für erweiterte Geschäftsregeln. Wird ein Namensraum falsch oder mit abweichender Version referenziert, kann eine Datei zwar auf den ersten Blick wohlgeformt erscheinen, bei der Schema-Validierung aber dennoch fehlschlagen, weil der Parser die referenzierten Elemente nicht der erwarteten Definition zuordnen kann. Wer eine eigene Implementierung aufbaut, sollte die Customization-ID und Profile-ID im Wurzelelement exakt gemäß der aktuell gültigen KoSIT-Spezifikation setzen, da Empfängersysteme diese Kennungen häufig zur Weichenstellung ihrer eigenen Verarbeitungslogik auswerten. Auch kleinere Abweichungen bei der Versionsnummer der referenzierten CIUS-Spezifikation können dazu führen, dass eine an sich korrekt strukturierte Datei von strengeren Validatoren zurückgewiesen wird.

Testdaten und Regressionstests im Entwicklungsprozess

Für Teams, die eine eigene XRechnung-Erzeugung entwickeln, empfiehlt sich ein systematischer Testaufbau mit einer Sammlung bekannter Randfälle: Rechnungen mit mehreren Steuersätzen innerhalb einer Datei, Rechnungen mit Skonto-Angaben, Gutschriften sowie Rechnungen mit Sonderzeichen in Firmennamen oder Adressen. Jede Änderung an der Erzeugungslogik sollte automatisiert gegen diese Testfälle sowie gegen den KoSIT-Validator laufen, bevor sie produktiv ausgerollt wird. Dieser Regressionstest-Ansatz verhindert, dass scheinbar unabhängige Anpassungen, etwa an der Rundungslogik für Beträge, unbemerkt zu ungültigen Dateien führen. Gerade bei international tätigen Unternehmen, die zusätzlich andere EN-16931-CIUS-Profile anderer europäischer Länder bedienen müssen, zahlt sich eine modulare Architektur aus, bei der die länderspezifischen Regeln getrennt von der Kernlogik gepflegt werden.

Von XML zu ZUGFeRD: Der zusätzliche Schritt der PDF-Einbettung

Wer aus einer bereits vorhandenen XRechnung-Erzeugung auch ZUGFeRD-Dateien ableiten möchte, benötigt einen weiteren technischen Baustein: die Einbettung der CII-XML-Datei als Anhang in ein PDF/A-3-Dokument, ergänzt um die passenden Metadaten und eine für Menschen lesbare visuelle Darstellung derselben Rechnungsdaten. Bibliotheken für PDF/A-3-Erzeugung übernehmen diesen Schritt üblicherweise automatisiert, sofern ihnen sowohl die XML-Daten als auch eine Layoutvorlage für die visuelle Seite übergeben werden. Wichtig ist dabei, dass beide Ebenen – visuelle Darstellung und eingebettete XML-Daten – stets inhaltlich übereinstimmen, da Abweichungen zwischen sichtbarem Betrag und im XML hinterlegtem Betrag zu Beanstandungen führen können.

Fazit

Die Erstellung einer XRechnung als XML-Datei erfordert genaues Verständnis von UBL- oder CII-Syntax, den Pflichtfeldern der EN 16931 und einer konsequenten Validierung gegen das offizielle Schema der KoSIT. Für Unternehmen mit eigenem Entwicklungsteam ist die programmatische Erzeugung über Bibliotheken oder APIs, eingebettet in eine automatisierte Validierungspipeline, der zuverlässigste und skalierbarste Weg – deutlich robuster als manuell gepflegte Einzeldateien.

Häufig gestellte Fragen

Ist UBL oder CII die bessere Wahl für eine XRechnung?

Beide Syntaxen sind gleichermaßen zulässig nach EN 16931. UBL ist in der Praxis weiter verbreitet, während CII vor allem im ZUGFeRD-Umfeld eine Rolle spielt. Die Wahl hängt oft von vorhandenen Bibliotheken und Kundenanforderungen ab.

Wie prüfe ich, ob meine erzeugte XML-Datei valide ist?

Der von der KoSIT bereitgestellte Validator prüft sowohl die formale XSD-Struktur als auch die fachlichen Schematron-Geschäftsregeln und ist die maßgebliche Referenzimplementierung für die Prüfung.

Kann ich eine XRechnung mit einem einfachen Texteditor schreiben?

Technisch ja, praktisch ist das jedoch nur für einzelne Testdateien sinnvoll. Für den produktiven Einsatz sollten Bibliotheken oder APIs verwendet werden, um Fehler zu vermeiden.

Welche Programmiersprachen eignen sich für die XRechnung-Erzeugung?

Es existieren Bibliotheken unter anderem für Java, PHP, Python und .NET. Die Wahl richtet sich meist nach dem bestehenden Technologie-Stack des Unternehmens.

Was ist der Unterschied zwischen XSD- und Schematron-Validierung?

Die XSD-Prüfung kontrolliert die formale Struktur und Datentypen. Schematron-Regeln prüfen zusätzlich fachliche Zusammenhänge, etwa ob sich Summen korrekt aus den Einzelpositionen ergeben.

Muss ich UBL und CII gleichzeitig unterstützen?

Nicht zwingend, aber es kann sinnvoll sein, wenn Sie sowohl reine XRechnungen als auch ZUGFeRD-Dateien erzeugen möchten, da ZUGFeRD auf CII basiert.

Wie gehe ich mit Schema-Updates der KoSIT um?

Sie sollten den Veröffentlichungskanal der KoSIT beobachten und Ihre Implementierung sowie den verwendeten Validator regelmäßig aktualisieren, um weiterhin schemakonforme Dateien zu erzeugen.