XRechnung Beispiele: Der praktische Leitfaden

XRechnung-Beispiele sind der schnellste Weg, den viel beschworenen „Datensatz statt PDF" wirklich zu verstehen. Denn eine XRechnung ist keine hübsche Rechnung mit Layout, sondern eine strukturierte XML-Datei, die eine Maschine lesen kann. Wer einmal ein echtes Muster gesehen hat, versteht sofort, warum bestimmte Regeln gelten – und wo die typischen Fallen liegen. Dieser Leitfaden zeigt konkrete Anwendungsfälle, erklärt den Aufbau und benennt die Fehler, die in der Praxis am häufigsten passieren.

Grundlagen: Was ist XRechnung wirklich?

Definition und Abgrenzung zu ZUGFeRD

Die XRechnung ist ein reines XML-Format – ohne sichtbare PDF-Komponente. Öffnet man die Datei ungefiltert, sieht man Tags und Werte, keine Rechnung im gewohnten Sinn. Das unterscheidet sie grundlegend von ZUGFeRD, das PDF und eingebettete XML kombiniert (hybrid).

Beide erfüllen den europäischen Standard EN 16931. Der Unterschied ist praktischer Natur: ZUGFeRD kann jeder Mensch im PDF-Reader lesen, XRechnung braucht ein Anzeige-Tool. Welches Format besser passt, hängt vom Betrieb ab – dazu haben wir einen eigenen Vergleich zwischen ZUGFeRD und XRechnung geschrieben.

XRechnung vs. EN 16931 – wo liegt der Unterschied?

EN 16931 ist der europäische Rahmen. XRechnung ist die deutsche Ausprägung (eine sogenannte CIUS – Core Invoice Usage Specification), die den Rahmen für den deutschen Behördenkontext verengt und konkretisiert. Wer beide Begriffe verwechselt, riskiert Rechnungen, die zwar EN-16931-gültig, aber nicht XRechnung-konform sind – oder umgekehrt. Eine kompakte Begriffsübersicht bietet unser E-Rechnung-Glossar.

Wer muss XRechnungen versenden – wer nicht?

Die Empfangspflicht gilt seit dem 01.01.2025 für alle Unternehmen. Die Versandpflicht greift gestaffelt: ab 2027 für Betriebe mit über 800.000 € Vorjahresumsatz, ab 2028 für alle übrigen. Ausnahmen gibt es für Kleinbeträge unter 250 €, reine B2C-Rechnungen, bestimmte steuerfreie Leistungen und in Teilen für Kleinunternehmer. Wer genau wann dran ist, klärt unser Beitrag zur E-Rechnungspflicht 2027/2028.

XRechnung 3.0.1: Die aktuelle Version

Seit dem 01.02.2024 gilt die Version XRechnung 3.0.1 verpflichtend für Rechnungen an Bundesbehörden. Neu hinzugekommen sind unter anderem präzisierte Anforderungen an Felder wie BT-23 (Geschäftsprozesstyp), BT-34 (elektronische Adresse des Verkäufers) und BT-49 (elektronische Adresse des Käufers). Diese „BT"-Codes sind die Business Terms des Standards – jedes Feld einer XRechnung hat so eine Kennung.

Für die Praxis heißt das: Schreiben Sie neue XRechnungen in 3.0.1. Ältere Versionen werden von vielen Empfängern übergangsweise noch akzeptiert, aber jede seriöse Software erzeugt heute 3.0.1. Wer über einen Dienst konvertiert, muss sich um die Version in der Regel gar nicht kümmern – die aktuelle wird automatisch verwendet.

Praktische XRechnung-Beispiele: Echte Anwendungsfälle

Einfache Standard-Rechnung

Eine minimale XRechnung enthält immer: Rechnungsnummer, Rechnungsdatum, Verkäufer- und Käuferdaten mit Steueridentifikation, mindestens eine Position mit Menge, Einzelpreis und Steuersatz sowie die Summenblöcke. Optional sind etwa Bestellnummer, Lieferdatum oder Freitext-Hinweise.

Die häufigsten Fehler schon hier: falsche Dezimaltrennzeichen (XML verlangt den Punkt, nicht das deutsche Komma) und fehlende Umsatzsteuer-Identifikation. Ein echtes CII-XML-Muster können Sie mit unserem Tool „XRechnung lesbar machen" in eine verständliche HTML-Vorschau verwandeln – so sehen Sie Struktur und Inhalt nebeneinander.

B2B-Rechnung mit Rabatt und Versandkosten

Rabatte werden in der XRechnung nicht einfach vom Preis abgezogen, sondern als strukturierte Abschläge (Allowance) auf Positions- oder Dokumentebene abgebildet – mit eigenem Grund-Code. Versandkosten sind ein Zuschlag (Charge) und gehören ebenfalls strukturiert erfasst, nicht als versteckter Aufpreis. Wer Rabatt im Freitext beschreibt statt strukturiert, produziert einen klassischen Validierungsfehler.

Rechnung mit Stornierung und Korrektur

Technisch heikel: Eine Stornorechnung hebt eine fehlerhafte Rechnung vollständig auf, eine Korrekturrechnung ersetzt sie, eine Gutschrift ist etwas ganz anderes (kaufmännisch wie umsatzsteuerlich). In der XML werden Bezug (BT-25, Referenz zur Originalrechnung) und ein passender Dokumententyp-Code gesetzt; bei Stornos arbeitet man mit Negativbeträgen. Die begriffliche Unterscheidung – und welcher Weg wann richtig ist – erklärt unser Beitrag E-Rechnung stornieren.

Reverse-Charge-Rechnung

Beim Reverse Charge (§ 13b UStG, z. B. Bauleistungen oder grenzüberschreitende Leistungen) schuldet der Leistungsempfänger die Umsatzsteuer. In der XRechnung wird dafür die Steuerkategorie „AE" (VAT Reverse Charge) mit 0 % Steuersatz und einem Pflicht-Hinweistext gesetzt. Beispiel: Ein Elektriker leistet an einen Generalunternehmer im Rahmen einer Bauleistung – die Rechnung weist keine USt aus, muss aber den Reverse-Charge-Hinweis tragen. Die korrekte Abbildung zeigt unser Artikel Reverse Charge in der E-Rechnung.

Rechnung mit Skonto

Skonto ist einer der häufigsten Stolpersteine. Es reicht nicht, „2 % Skonto bei Zahlung innerhalb 10 Tagen" ins Freitextfeld zu schreiben – der Standard erwartet die Zahlungsbedingungen strukturiert im dafür vorgesehenen Feld (BT-20) in einer maschinenlesbaren Syntax. Steht Skonto nur als Prosa im Text, meldet der Validator einen Fehler. Genau dieser Fall gehört zu den fünf häufigsten EN-16931-Fallstricken bei Handwerker-Rechnungen.

Branchenspezifische Beispiele

Handwerk: Material (19 %) und begünstigte Leistungen können unterschiedliche Steuersätze auf einer Rechnung haben – jede Position braucht ihren korrekten Steuercode. Pro Steuersatz muss ein eigener Summenblock aufgehen.
Anwaltskanzlei: RVG-Gebühren und Auslagen (Porto, Kopien) werden als getrennte Positionen abgebildet. Details im Beitrag E-Rechnung für Anwaltskanzleien.
Arztpraxis: Steuerfreie Heilbehandlungen und steuerpflichtige IGeL-Leistungen sauber trennen – siehe E-Rechnung für Arzt- und Zahnarztpraxen.
Online-Händler: Bei Marketplace-Szenarien ist die Frage entscheidend, wer technisch Rechnungsaussteller ist. Dazu E-Rechnung für eBay, Etsy, Shopify und Amazon.

Aufbau einer XRechnung – Technische Anatomie

Header: Metadaten

Die Felder customizationID und profileID sind kritisch: Sie sagen dem Empfänger, welcher Standard und welches Profil verwendet wurden. Fehlen oder stimmen sie nicht, wird die Datei oft schon abgewiesen. Dazu kommen Rechnungsnummer (eindeutig, lückenlos), Rechnungsdatum und – wo relevant – Liefer- und Fälligkeitsdatum.

Partie-Daten

Die XRechnung unterscheidet sauber zwischen Verkäufer, Käufer, Rechnungsadressat und optional abweichender Lieferadresse. Pflicht sind vollständige Adressdaten plus mindestens eine Steueridentifikation (USt-IdNr. oder Steuernummer). Unvollständige Adressdaten sind ein Dauerbrenner unter den Validierungsfehlern.

Positionsdaten

Jede Position enthält Menge, Einheit, Netto-Einzelpreis und Steuerkategorie. Die Steuerkategorie-Codes (S = Normal/reduziert, Z = Nullsatz, AE = Reverse Charge, E = steuerbefreit) müssen zum tatsächlichen Sachverhalt passen. Ein falscher Code hier zieht sich durch die gesamten Summen.

Zusammenfassung: Summen

Die Summenblöcke müssen rechnerisch aufgehen – Netto plus Steuer gleich Brutto, und das je Steuersatz getrennt. Der häufigste Fehler: manuell gerundete Beträge, die um ein oder zwei Cent von der berechneten Summe abweichen. Der Validator akzeptiert das nicht.

Zahlungsinformationen

IBAN und BIC gehören strukturiert erfasst, die IBAN mit korrektem Ländercode („DE…"). Zahlungsfrist und Skonto-Frist müssen zeitlich plausibel sein.

Häufige Fehler und Fallstricke

Formatfehler: nicht geschlossene Tags, ungültige Zeichen, Komma statt Punkt bei Beträgen, Encoding-Probleme bei Umlauten.
Logische Fehler: Rundungsabweichungen, falsche Steuerkategorien, doppelte Rechnungsnummern.
Identifikation: fehlende Steuernummer/USt-IdNr., falsch formatierte IBAN.
Datumslogik: Lieferdatum nach Rechnungsdatum, Zahlungsziel in der Vergangenheit, Skonto-Frist nach Fälligkeit.

Wenn PDF und XML nicht übereinstimmen

Eine reine XRechnung braucht gar keine sichtbare PDF-Darstellung. Kritisch wird es beim hybriden ZUGFeRD-Format: Weichen sichtbares PDF und eingebettete XML voneinander ab, gilt steuerlich die XML – mit teils unangenehmen Folgen. Diesen unterschätzten Fall behandelt unser Artikel zur ZUGFeRD-Falle bei PDF-XML-Diskrepanz.

XRechnung erstellen und versenden

Drei Wege zur XRechnung

XML von Hand schreiben – technisch möglich, in der Praxis kaum sinnvoll.
Automatische Konvertierung – eine Software erkennt die Rechnungsdaten aus dem PDF und erzeugt das strukturierte Format. Das ist der Belegschmied-Ansatz.
Native Erzeugung durch ERP- oder Faktura-Software.

Automatische Konvertierung: PDF → XRechnung

Bei der Konvertierung liest die Software die relevanten Felder aus und baut daraus den strukturierten Datensatz. Entscheidend ist danach die Validierung: Ein guter Dienst stoppt bei Unklarheiten und fragt nach, statt eine womöglich falsche Summe still zu übernehmen. Prüfen können Sie jederzeit selbst mit unserem kostenlosen Validierungs-Tool.

CC-Workflow als Brückenlösung

Der praktikabelste Weg ohne Software-Wechsel: Rechnung wie gewohnt als PDF per E-Mail versenden und die Belegschmied-Adresse in CC setzen. Rund 90 Sekunden nach Versand erfolgt die Umwandlung automatisch im Hintergrund. Bestehende Word- oder Programm-Workflows bleiben unangetastet – Details unter E-Rechnungen automatisch versenden.

Speicherung und GoBD-Archivierung

XRechnungen müssen mindestens 10 Jahre revisionssicher aufbewahrt werden – unveränderbar, mit Audit-Trail und SHA-256-Hashing. Wie sich das automatisch lösen lässt, erklärt GoBD-konforme Archivierung automatisch.

Validierung und Compliance-Check

Die Validierung erfolgt gegen die offiziellen Schematron-Regeln der KoSIT. Man unterscheidet Syntax-Check (ist das XML technisch sauber?) und inhaltliche Validierung (halten die Business Rules?). Typische Meldungen sind BR-Regel-Verletzungen (etwa BR-CO-26, wenn keine Verkäufer-Identifikation vorliegt) und semantische Fehler.

Der entscheidende Punkt: Eine intelligente Validierung stoppt bei Unklarheiten, statt eine fehlerhafte Rechnung durchzuwinken. Denn eine formal akzeptierte, inhaltlich falsche Rechnung kann später bei der Betriebsprüfung teuer werden.

Checkliste: XRechnung vor dem Versand prüfen

Rechnungsnummer eindeutig und lückenlos?
Verkäufer, Käufer und Rechnungsadressat vollständig?
Steuernummer/USt-IdNr. vorhanden und korrekt?
Summen rechnerisch stimmig, keine Rundungsabweichung?
Datumslogik plausibel (Lieferdatum ≤ Rechnungsdatum)?
Steuerkategorien korrekt (S, Z, E, AE)?
IBAN mit Ländercode, BIC gültig?
Dezimaltrennzeichen durchgehend Punkt?
Skonto strukturiert, nicht im Freitext?
Validierungsbericht fehlerfrei?

Gute Ressourcen zum Weiterlesen

KoSIT – offizielle technische Spezifikation und Schematron-Regeln: xeinkauf.de/xrechnung
BMF – rechtlicher Rahmen der E-Rechnungspflicht; die praktischen Auswirkungen fassen wir im Beitrag zum BMF-Schreiben vom 15.10.2025 zusammen.
Belegschmied-Tools – alle kostenlosen Werkzeuge (validieren, visualisieren, konvertieren) gebündelt unter belegschmied.de/tools.

FAQ

Kann ich eine XRechnung in einem Text-Editor erstellen? Technisch ja, praktisch kaum. Ein einziger falscher Tag oder ein Komma statt Punkt macht die Datei ungültig. Automatisierung ist der realistische Weg.

Darf ich weiterhin PDF-Rechnungen versenden? Im B2C-Bereich ja. Im B2B-Bereich nur noch bis zum jeweiligen Stichtag 2027/2028 – danach ist das strukturierte Format Pflicht.

Muss ich alte Rechnungen nachträglich umwandeln? Nein. Die Pflicht gilt nur für neue Rechnungen ab dem jeweiligen Stichtag.

Kann ich XRechnung und ZUGFeRD gemischt verwenden? Ja, beide erfüllen EN 16931. Idealerweise standardisieren Sie sich auf ein Format und dokumentieren die Entscheidung.

Welche Version sollte ich schreiben? XRechnung 3.0.1 – aktuell seit dem 01.02.2024.

Wer prüft, ob meine XRechnung konform ist? Zunächst Sie selbst per Validator, dann der Empfänger beim Einlesen, und im Zweifel die Finanzbehörde bei einer Prüfung.