XRechnung: der deutsche CIUS für die elektronische Rechnung
XRechnung ist die deutsche nationale Spezifikation für elektronische Rechnungen — jene Schicht, die den abstrakten europäischen Standard in eine Form bringt, die für die deutsche Steuerverwaltung handhabbar ist. Sie ist kein Dateiformat, sondern ein Core Invoice Usage Specification (CIUS) auf der Grundlage von EN 16931. XRechnung verschärft die europäische Grundnorm dort, wo das deutsche Recht und die deutschen Empfangssysteme zusätzliche Anforderungen stellen. Gepflegt wird der Standard von der KoSIT (Koordinierungsstelle für IT-Standards), einer gemeinsamen Einrichtung von Bund und Ländern.
Rechtsgrundlage und Zeitplan
Die XRechnung-Pflicht ist in mehreren Stufen eingeführt worden:
- November 2020. Bundes- und die meisten Länderbehörden verlangen XRechnung für Rechnungen an die öffentliche Verwaltung oberhalb von 1.000 €. Die Pflicht erstreckt sich nach und nach auf den gesamten öffentlichen Sektor.
- Januar 2025. Alle deutschen B2B-Empfänger müssen technisch in der Lage sein, elektronische Rechnungen in einem EN-16931-konformen Format entgegenzunehmen — XRechnung oder Factur-X / ZUGFeRD. Die Ära der PDF-per-E-Mail ist im B2B-Bereich offiziell vorbei.
- Januar 2027. Die elektronische Rechnungsstellung wird für das Ausstellen von B2B-Rechnungen verpflichtend, mit einer letzten Übergangsregelung für Unternehmen unterhalb der Grenze von 800.000 € Jahresumsatz.
- Januar 2028. Die Übergangszeit endet. Jede B2B-Rechnung zwischen inländischen deutschen Unternehmen muss in einem EN-16931-konformen Format ausgestellt sein.
Rechtsgrundlage ist das Wachstumschancengesetz von 2024, das §14 UStG so ändert, dass die elektronische Rechnung der Regelfall und die Papierrechnung die Ausnahme ist. Den weiteren rechtlichen und betrieblichen Rahmen — akzeptierte Formate, Übermittlungswege, Archivierung und das Leitweg-ID-System für den öffentlichen Sektor — beschreibt unser Beitrag zur E-Rechnung in Deutschland.
Zwei Syntaxen, eine Spezifikation
Ein häufiges Missverständnis: XRechnung ist kein einzelnes XML-Format. Die Spezifikation lässt zu, dass eine Rechnung in einer der beiden von EN 16931 anerkannten Syntaxen ausgedrückt wird — UBL 2.1 oder UN/CEFACT CII —, und eine konforme Rechnung in beiden Formen ist gleichwertig. Empfangssysteme müssen beide verarbeiten können. In der Praxis bevorzugt der öffentliche Sektor eher UBL, während aus der Wirtschaft kommende Rechnungen häufiger CII verwenden, doch keine dieser Vorlieben ist rechtlich verankert. Die Abwägung zwischen den beiden findet sich in unserem Vergleich UBL gegen CII.
XRechnung ist auch nicht das einzige rechtlich gültige Format für den deutschen B2B-Markt. Das hybride PDF-XML-Format Factur-X / ZUGFeRD ist gleichermaßen anerkannt, und die Wahl zwischen den beiden ist eine echte architektonische Entscheidung und keine rechtliche Bevorzugung — siehe XRechnung gegen ZUGFeRD für die Abwägungen.
Was XRechnung der EN 16931 hinzufügt
Der Beitrag von XRechnung besteht in einer Reihe zusätzlicher Geschäftsregeln — der BR-DE-*-Familie —, die Felder einschränkt oder verlangt, die die europäische Grundnorm freistellt. Die wichtigsten Ergänzungen sind:
- Verpflichtende Zahlungsanweisung (BR-DE-1). Die Rechnung muss angeben, wie der Käufer zahlen soll — typischerweise per SEPA-Überweisung mit IBAN oder per Lastschriftmandat. Ohne diese Angabe ist eine automatisierte Verarbeitung auf der Empfängerseite nicht möglich.
- Verpflichtender Verkäufer-Ansprechpartner (BR-DE-2, -5, -6, -7). Ein benannter Ansprechpartner mit Telefon oder E-Mail. Kein anonymes info@-Postfach, sondern eine Person oder Funktion, an die sich die Kreditorenbuchhaltung des Käufers wenden kann.
- Verpflichtende Stadt und Postleitzahl für Verkäufer und Käufer (BR-DE-3, -4, -8, -9). Die europäische Grundnorm lässt diese in manchen Fällen weg; XRechnung tut das nicht.
- Käuferreferenz (BR-DE-15). Pflichtfeld. Bei Rechnungen an die öffentliche Verwaltung ist dies die Leitweg-ID — ein Routing-Identifikator, den die empfangende Stelle dem Lieferanten im Voraus mitteilt.
- Eingeschränkte Rechnungstyp-Codes (BR-DE-17). Nur eine Teilmenge von UNTDID 1001 ist zulässig: 326 (Teilrechnung), 380 (Handelsrechnung), 384 (Korrekturrechnung), 389 (Selbstfaktura), 381 (Gutschrift) und einige Codes für Bauleistungen.
- Strukturierte Skonto-Kodierung (BR-DE-18). Wenn Skonto angeboten wird, muss es in einer festgelegten strukturierten Form innerhalb des Feldes Zahlungsbedingungen ausgedrückt werden, damit Empfangssoftware das Skonto automatisch verarbeiten kann, statt Freitext zu zerlegen.
- Kohärenz der Zahlungsmittel (BR-DE-23 bis -25). Welches Zahlungsmittel die Rechnung auch deklariert — Überweisung, Kartenzahlung, Lastschrift —, nur die zugehörige Geschäftsgruppe darf vorhanden sein.
Eine typische XRechnung wird gegen rund 200 Regeln geprüft: die EN-16931-Grundnorm plus etwa 30 BR-DE-Regeln plus die zusätzlichen BR-CO-- und BR-CL--Prüfungen, die der europäische Standard ohnehin mitbringt.
Die Leitweg-ID
Bei Rechnungen an die deutsche öffentliche Verwaltung ist die Käuferreferenz (BT-10) kein Freitextfeld. Sie muss eine Leitweg-ID sein — ein strukturierter Routing-Identifikator, den die empfangende Stelle dem Lieferanten im Voraus mitteilt. Die Leitweg-ID sagt dem Empfangsportal, an welche Abteilung, Behörde oder Untereinheit die Rechnung gehört, und ist Voraussetzung dafür, dass die Rechnung über die öffentlichen E-Rechnungs-Portale (ZRE für den Bund, OZG-RE für mehrere Länder, eigene Portale anderswo) zugestellt werden kann.
Im B2B-Bereich ist die Käuferreferenz ebenfalls Pflichtfeld, kann aber jede zwischen den Parteien vereinbarte Angabe enthalten — üblicherweise eine Bestellnummer, eine Vertragsreferenz oder eine kundeninterne Kennung.
Die XRechnung-Extension
Die Standard-XRechnung deckt den EN-16931-Informationsumfang ab. Einige reale deutsche Rechnungsszenarien — Unter-Positionen für zusammengesetzte Leistungen, Drittzahler-Aufteilungen, zusätzliche Referenzstrukturen — verlangen Felder, die nicht zur europäischen Grundnorm gehören. Die XRechnung-Extension ergänzt diese als optionale Elemente, validiert durch die BR-DEX-*-Familie. Eine Rechnung mit Extension-Feldern ist nicht mehr reines EN 16931, bleibt aber von Extension-fähigen Empfangssystemen verarbeitbar.
Die Extension ist optional. Die meisten Rechnungen brauchen sie nicht.
Eine XRechnung validieren
Den offiziellen Validator veröffentlicht die KoSIT; er prüft die Datei gegen das hinterlegte Schematron. Er ist die maßgebliche Instanz für die Frage, ob eine Datei XRechnung-konform ist, und jede Abweichung zwischen einem Drittwerkzeug und der KoSIT sollte zugunsten der KoSIT aufgelöst werden. Unser Validator bringt dieselben Schematron-Regeln mit, ein grüner Bericht bei uns entspricht also einem grünen Bericht der KoSIT — im Streitfall zählt jedoch das offizielle Werkzeug.
Was XRechnung nicht löst
Die Grenzen der Spezifikation lohnen es, ausdrücklich genannt zu werden. XRechnung schweigt zu:
- Übermittlung. Wie die Datei beim Empfänger ankommt — über PEPPOL, das Bundesportal ZRE, per E-Mail, SFTP oder über das eigene Upload-Formular eines Kunden — ist nicht Gegenstand von XRechnung. Öffentliche Empfänger schreiben jeweils ihre eigenen Kanäle vor; im B2B-Bereich ist es eine Sache der Vereinbarung zwischen den Parteien.
- Archivierung. Acht Jahre für Buchungsbelege gemäß §147 AO (durch das Bürokratieentlastungsgesetz IV 2025 von zehn auf acht Jahre verkürzt), mit den zusätzlichen GoBD-Anforderungen an Integrität und Nachvollziehbarkeit. Wie die Datei gespeichert wird, regelt XRechnung nicht.
- Signierung. Das deutsche Recht verlangt für gewöhnliche B2B-Rechnungen keine qualifizierte elektronische Signatur mehr, doch einzelne Branchen (insbesondere Teile des Bauwesens und der öffentlichen Beschaffung) haben weiterhin eigene Anforderungen.
- Lebenszyklus. »Empfangen«, »freigegeben«, »bezahlt«, »beanstandet« — das ist Sache des Empfängers, nicht des Standards.
Wer ein als »XRechnung-fähig« beworbenes Produkt prüft, sollte fragen: welche Versionen werden unterstützt, wird gegen das mitgelieferte KoSIT-Schematron validiert, werden sowohl UBL als auch CII verarbeitet, und wie integriert sich das Produkt in die Übermittlungskanäle, die die Kunden tatsächlich nutzen.