XRechnung: Format, Gültigkeit und Pflicht in der Verwaltung
XRechnung-Format: was der Standard festlegt
Gemeint ist eine Datei mit Rechnungsdaten, kein Portal und keine Software. Im elektronischen Rechnungsworkflow der bayerischen Staatsverwaltung lag ihr Anteil zwischen 2022 und 2024 jeweils unter 3 Prozent, bei geschätzt einer Million möglicher E-Rechnungen im Jahr.
XRechnung ist der nationale Standard für elektronische Rechnungen an öffentliche Auftraggeber in Deutschland. Er konkretisiert die europäische Norm EN 16931 für die deutsche Verwaltung und legt fest, welche Angaben eine Rechnung enthalten muss und in welcher XML-Struktur sie übermittelt wird. Zugelassen sind zwei Syntaxen, UBL 2.1 und UN/CEFACT CII. Gepflegt wird der Standard von der Koordinierungsstelle für IT-Standards im Auftrag des IT-Planungsrats.
Wer den Standard festlegt und pflegt
Hinter dem Standard steht kein Softwarehersteller, sondern ein Gremium der Verwaltung. Der IT-Planungsrat hat am 22. Juni 2017 beschlossen, dass das XRechnung-Format für die Umsetzung der EU-Richtlinie 2014/55/EU maßgeblich ist. Die Koordinierungsstelle für IT-Standards, kurz KoSIT, führt seither die Spezifikation und veröffentlicht sie samt Prüfregeln offen. Das unterscheidet den Standard von einem Herstellerformat, das ein Anbieter jederzeit ändern kann. Für Rechnungen zwischen Unternehmen gilt ein eigener Zeitplan, den die E-Rechnungs-ERP-Integration behandelt.
Was CIUS und Extension unterscheiden
Die europäische Norm EN 16931 beschreibt ein gemeinsames Datenmodell für alle Mitgliedstaaten. Eine CIUS schränkt dieses Modell ein und macht Angaben verbindlich, die europäisch nur optional sind. Eine Extension geht den anderen Weg und ergänzt zusätzliche Felder. Das XRechnung-Format nutzt beides, weshalb eine Rechnung europäisch korrekt und in Deutschland trotzdem unvollständig sein kann. Die zweite gebräuchliche CIUS heißt Peppol BIS Billing 3.0 und begegnet Rechnungsstellern beim Versand über Peppol.
UBL und CII: zwei zugelassene Syntaxen
Beide Syntaxen tragen dieselben Angaben, ordnen sie aber in unterschiedlichen XML-Bäumen an. Das XRechnung-Format schreibt keine davon vor, ein Rechnungssteller darf frei wählen und ein Empfänger muss beide lesen können. Genau diese Übersetzung zwischen Formaten, die dasselbe meinen, ist die klassische Aufgabe von Middleware.
Vier Punkte gehören dafür in die Anforderungsliste:
- UBL 2.1 für Rechnung und Gutschrift
- UN/CEFACT CII in der Fassung 16B
- Erkennung der Syntax am Wurzelelement der Datei
- gleiche Feldbedeutung in zwei verschiedenen Baumstrukturen
Ein System, das nur eine Syntax kennt, lehnt gültige Rechnungen ab. Auffallen kann das erst, wenn ein Lieferant seine Rechnungssoftware wechselt.
Woran erkennt eine Behörde eine gültige XRechnung?
An zwei Prüfungen, die beide maschinell laufen und ein Protokoll hinterlassen. Gültigkeit ist damit keine Ermessensfrage zwischen Lieferant und Amt, sondern ein reproduzierbares Ergebnis. Der Prüfbericht nennt jede verletzte Regel mit ihrer Kennung, und der Lieferant kann mit demselben Werkzeug nachvalidieren. In Software für öffentliche Einrichtungen gehört dieser Bericht deshalb an den Vorgang, nicht in ein Protokollverzeichnis, das niemand öffnet.
Schemaprüfung und Geschäftsregeln
Die erste Stufe prüft die Datei gegen das XML-Schema der XRechnung. Sie beantwortet, ob die Struktur stimmt und die Datentypen passen. Die zweite Stufe prüft Geschäftsregeln, die als Schematron-Regeln vorliegen und Bedingungen beschreiben, die kein Schema abbilden kann. Beide Bestandteile veröffentlicht die KoSIT gemeinsam, sodass Behörde und Lieferant mit demselben Validator validieren.
Fünf Fragen entscheiden über die Gültigkeit:
- entspricht die Datei einer der beiden zugelassenen Syntaxen
- sind die Pflichtfelder belegt, etwa die Käuferreferenz im Feld BT-10
- passen Positionsbeträge, Nettosumme und ausgewiesene Steuer zusammen
- sind die deutschen Zusatzregeln der Spezifikation eingehalten
- stammen alle Codes aus den vorgeschriebenen Schlüsselverzeichnissen
Warum die Ansicht nicht die Rechnung ist
Eine XML-Datei liest sich schlecht, deshalb liefert die KoSIT eine Visualisierung mit, die den Datensatz als HTML- oder PDF-Ansicht darstellt. Wer eine XRechnung visualisieren oder einen Viewer nutzen will, bekommt genau das. Diese Ansicht ist ausdrücklich kein gültiger Rechnungsdatensatz und laut Betreiber auch nicht für die Langzeitaufbewahrung gedacht. Prüffähig bleibt allein die XML-Datei, nicht der Ausdruck daraus. Für Vereine mit unternehmerischem Bereich hängt daran der Vorsteuerabzug, weil eine archivierte Ansicht den Originalbeleg nicht ersetzt.
Rechtsrahmen für Bund, Länder und Kommunen
Die XRechnung-Pflicht zerfällt in zwei getrennte Fragen. Die eine gilt der Verwaltung und lautet, ob sie einen solchen Datensatz annehmen muss. Die andere gilt dem Lieferanten und lautet, ob er ihn schicken muss. Beim Bund sind beide beantwortet, und die Einreichung läuft dort über die OZG-RE, bei Ländern und Kommunen ist nur die erste Frage geklärt. Diese Asymmetrie erklärt, warum dieselbe Frage je nach Auftraggeber anders ausfällt.
XRechnung-Pflicht beim Bund seit 2020
Für Bundesbehörden und ihre Lieferanten ist die Lage klar geregelt. Grundlage ist die E-Rechnungsverordnung, und ihre Ausnahmen sind eng gefasst.
Fünf Daten und Grenzen gelten:
❗ Bundesministerien empfangen seit dem 27.11.2018
❗ übrige Bundesstellen empfangen seit dem 27.11.2019
❗ Länder und Kommunen empfangen seit dem 18.04.2020
❗ Lieferanten des Bundes fakturieren seit dem 27.11.2020 elektronisch
❗ ausgenommen sind Direktaufträge bis 1.000 Euro netto
Diese letzte Grenze ist nicht die Vergabegrenze, auch wenn beide einmal beim selben Betrag lagen. Die Wertgrenze für Direktaufträge nach § 14 UVgO liegt beim Bund seit 2025 bei 15.000 Euro, die 1.000-Euro-Grenze der E-Rechnungsverordnung blieb davon unberührt.
Wann verlangt eine Kommune elektronische Rechnungen?
Auf kommunaler Ebene ist der Empfang seit dem 18. April 2020 vorgeschrieben, so will es die EU-Richtlinie 2014/55/EU. Eine XRechnung-Pflicht für Lieferanten entsteht dagegen erst durch Landesrecht, und dieses setzt jedes Land selbst. Über die Zulässigkeit einer Papierrechnung entscheidet damit das jeweilige Landesrecht, und es kann für Kommunen anders ausfallen als für Landesbehörden desselben Landes. Maßgeblich ist die Rechtslage des Auftraggebers, nicht die des Lieferanten.
XRechnung-Pflicht nach Landesrecht
Baden-Württemberg zeigt, wie feingliedrig das ausfällt. Die dortige E-Rechnungsverordnung verpflichtet Auftragnehmer des Landes zur elektronischen Rechnung, für Rechnungen an Kommunen gelten dagegen eigene, auf deren Bedürfnisse zugeschnittene Regelungen. Wer an mehrere Länder fakturiert, hat damit keine einheitliche XRechnung-Pflicht vor sich, sondern sechzehn Rechtslagen. Für die Verwaltung folgt daraus, dass der Empfangsweg auf absehbare Zeit auch Papier und PDF tragen muss.
Vom XML-Datensatz ins Fachverfahren
Der Empfang ist mit diesen Fristen geklärt, die Verarbeitung nicht. An dieser Stelle endet der digitale Weg, wenn das Fachverfahren oder das Haushalts-, Kassen- und Rechnungswesen den Datensatz nicht kennt. Das Fachverfahren muss den Standard aber nicht lernen. Eine Schicht davor liest die Datei, prüft sie und übergibt strukturierte Felder. Bei einem einzelnen Zielsystem reicht dafür eine Schnittstelle, bei mehreren beteiligten Verfahren beginnt das Gebiet von Middleware und API.
Wie oft ändert sich der Standard?
Ein Standard, der jährlich wechselt, ist für ein Fachverfahren ein Betriebsthema und kein Projekt. Die XRechnung-Spezifikation erscheint in Hauptversionen, dazwischen in Bündeln mit Fehlerkorrekturen.
Vier Angaben genügen für die Planung:
- Version 3.0 gilt seit dem 1. Februar 2024
- die Vorgängerversion 2.3 wurde am selben Tag außer Kraft gesetzt
- das Bündel 3.0.2 erhielt am 31. Januar 2026 einen Bugfix
- mittelfristig ist nur ein Hauptrelease pro Jahr vorgesehen
Der zweite Punkt ist der wichtige. Eine alte Version verliert ihre Gültigkeit zu einem festen Datum, sie läuft nicht aus. Bei einer gebuchten Integrationsplattform aus der Cloud trägt der Anbieter den Versionswechsel, bei einer eigenen Schicht das Haus.
Was vor dem Fachverfahren entstehen muss
Drei Aufgaben fallen unabhängig vom Fachverfahren an, und keine gehört hinein. Die Datei muss gelesen und gegen Schema und Geschäftsregeln geprüft werden. Das Ergebnis muss samt Prüfbericht am Vorgang hängen, damit eine Ablehnung begründbar bleibt. Und die Felder müssen in die Struktur des Zielsystems übersetzt werden, was der Kern jeder API- und Schnittstellenentwicklung ist. Erst danach beginnt die fachliche Bearbeitung.
TenMedia baut diese Vorschicht, also das Einlesen beider Syntaxen, die Prüfung gegen die veröffentlichte Konfiguration und die Übergabe ans Fachverfahren. Dieselbe Trennung zwischen Eingangskanal und Fachlogik trug schon die zentrale Verwaltungsplattform mit Inventursoftware. Eine tragfähige Verarbeitung entsteht damit vor dem Fachverfahren, nicht darin.