XRechnung Beispiel: Aufbau und praktische Anwendung

Die meisten Handwerksbetriebe haben noch nie eine XRechnung von innen gesehen. Sie kennen ihre PDF-Rechnung mit Logo und Briefkopf – und plötzlich soll da eine Datei ohne sichtbares Layout an ihre Stelle treten. Ein konkretes Beispiel hilft mehr als jede abstrakte Normbeschreibung. Genau darum geht es hier: Wir zeigen, wie eine XRechnung wirklich aufgebaut ist, wo die Praxis von der Theorie abweicht und welche Fehler am häufigsten passieren.

Das ist keine akademische Übung. Ab 2027 (Betriebe über 800.000 € Vorjahresumsatz) und ab 2028 (alle übrigen) wird die E-Rechnungsstellung im B2B-Bereich zur Pflicht. Wer heute versteht, wie ein XRechnung-Beispiel funktioniert, hat die Umstellung schon halb geschafft.

Was ist XRechnung? – Begriffe entmystifizieren

Die XRechnung ist ein strukturierter Datensatz im XML-Format. Statt eines Bildes einer Rechnung enthält sie maschinenlesbare Felder: Rechnungsnummer, Betrag, Steuersatz, Empfänger – alles klar benannt und automatisch verarbeitbar.

Drei Begriffe werden oft verwechselt:

EN 16931 ist die europäische Norm, die vorgibt, welche Datenfelder eine E-Rechnung enthalten muss.
XRechnung ist die deutsche Ausprägung (CIUS) dieser Norm – reines XML, ursprünglich für öffentliche Auftraggeber.
ZUGFeRD kombiniert eine sichtbare PDF mit eingebettetem XML. Beide erfüllen EN 16931, sind aber unterschiedliche Container.

Welches Format zu welchem Betrieb passt, haben wir im Vergleich ZUGFeRD oder XRechnung ausführlich behandelt. Für öffentliche Aufträge ist XRechnung heute schon Pflicht, im B2B kommt sie mit der E-Rechnungspflicht ab 2027/2028.

Aufbau einer XRechnung – Das technische Gerüst

Eine XRechnung ist hierarchisch aufgebaut. Von oben nach unten:

Kopfdaten: Rechnungsnummer, Datum, Rechnungstyp, Währung.
Beteiligte: Verkäufer und Käufer mit Adressen und IDs.
Positionen: Jede Leistung mit Menge, Einzelpreis und Steuersatz.
Summen: Netto, Steuerbeträge, Bruttosumme.
Zahlungsbedingungen: IBAN, Fälligkeit, Zahlungsziel.

Jedes Feld hat eine sogenannte Business-Term-Nummer (BT), etwa BT-1 für die Rechnungsnummer. Diese Nummerierung stammt direkt aus der EN 16931 und sorgt dafür, dass jedes System dasselbe Feld gleich versteht.

Ein wichtiger Punkt für die Praxis: Eine maschinelle Validierung prüft nur die Struktur und die Regeln – nicht, ob die Summe inhaltlich stimmt. Ein XML kann fehlerfrei validieren und trotzdem einen falschen Betrag enthalten. Diese „stillen Fehler" sind die eigentliche Gefahr.

Praxisbeispiel 1: Einfache Standardrechnung

Nehmen wir einen SHK-Betrieb, der eine Heizungsreparatur abrechnet: 2,5 Stunden Arbeit à 65 €, eine Umwälzpumpe für 180 €, 19 % Umsatzsteuer.

Im XML sieht das (vereinfacht dargestellt) so aus:

BT-1 Rechnungsnummer: 2026-0473
BT-2 Rechnungsdatum: 2026-03-14
BT-3 Rechnungstyp: 380 (kaufmännische Rechnung)
BT-5 Währung: EUR
Position 1: Arbeitszeit, Menge 2,5, Einzelpreis 65,00, Steuer 19 %
Position 2: Umwälzpumpe, Menge 1, Einzelpreis 180,00, Steuer 19 %
BT-109 Nettosumme: 342,50
BT-112 Bruttosumme: 407,58

Häufigster Anfängerfehler: Rechnungsdatum und Leistungsdatum verwechseln. Das Rechnungsdatum (BT-2) ist der Ausstellungstag, das Leistungsdatum (BT-72) der Tag der Ausführung. Fehlt das Leistungsdatum ganz, kann die Betriebsprüfung nachfragen. Wer den Aufbau anhand einer echten Datei nachvollziehen will, kann eine XRechnung mit unserem Viewer lesbar machen und Feld für Feld durchgehen.

Praxisbeispiel 2: Rechnungskorrektur und Stornierung

Fehler passieren. Wichtig ist, sie sauber zu dokumentieren – nicht die alte Rechnung stillschweigend zu überschreiben.

Drei Fälle sind zu unterscheiden:

Stornorechnung: Die ursprüngliche Rechnung wird vollständig neutralisiert (negativer Betrag mit Bezug auf die Originalnummer).
Korrekturrechnung: Eine neue Rechnung ersetzt die alte, mit Verweis (BT-25, „Vorangegangene Rechnung").
Gutschrift: Ein eigenständiges Dokument, oft im Reverse-Charge-Kontext.

Wenn also aus 342,50 € versehentlich 324,50 € wurden, ändert sich nicht nur die Positionszeile, sondern auch alle Summenfelder und der Steuerbetrag. Der Unterschied zwischen den drei Fällen und die richtige Vorgehensweise stehen ausführlich im Beitrag E-Rechnung stornieren.

Wichtig: Eine gute Software sollte bei Korrekturen stoppen und nachfragen, statt automatisch einen neuen Betrag zu übernehmen. Genau diese Sorge – dass eine Umwandlung still eine falsche Summe übernimmt – ist berechtigt und der Grund für intelligente Fehler-Stopps.

Praxisbeispiel 3: Besonderheiten nach Branche

Nicht jede Branche rechnet gleich:

Handwerk arbeitet oft mit Teil- und Abschlagsrechnungen; Materiallieferscheine gehören als Anhang ins ZUGFeRD-PDF.
Anwaltskanzleien rechnen nach RVG und haben besondere Anforderungen an Gebührenpositionen – Details im Beitrag E-Rechnung für Anwaltskanzleien.
Arzt- und Zahnarztpraxen trennen steuerfreie Heilbehandlungen von umsatzsteuerpflichtigen IGeL-Leistungen – hier greifen DSGVO-Fragen zusätzlich.
Online-Händler auf eBay, Etsy oder Shopify müssen klären, wer eigentlich Rechnungsaussteller ist – Marktplatz oder Händler.

Für Handwerksgewerke haben wir eigene Seiten, etwa für Maler oder SHK.

Pflichtfelder einer XRechnung – Die wichtigsten Felder

Die Business Terms gliedern sich grob so:

BT-1 bis BT-10: Kopfzeile – Rechnungsnummer, Datum, Typ, Währung.
BT-11 bis BT-20: Verkäufer- und Käuferdaten, inklusive USt-IdNr. oder Steuernummer.
BT-21 bis BT-31: Positionsdaten – Artikel, Menge, Preis, Steuersatz.
BT-35 bis BT-49: Summen, Zahlungsbedingungen, Bankverbindung, Rechnungsbegründung.

Eine häufige Falle ist die fehlende oder falsch formatierte Umsatzsteuer-ID. Die EN-16931-Regel BR-CO-26 verlangt mindestens eine eindeutige Kennung des Verkäufers – USt-IdNr. oder Steuernummer. Fehlt beides, wird die Rechnung abgelehnt. Welche Feldfehler in der Praxis am häufigsten vorkommen, zeigt der Beitrag zu den 5 häufigsten EN-16931-Fallstricken.

XRechnung 3.0.1 – Die neuesten Anforderungen

Seit dem 1. Februar 2024 gilt der Standard XRechnung 3.0.1. Neu sind unter anderem verschärfte Anforderungen an BT-23 (Geschäftsprozess-Kennung), BT-34 (elektronische Adresse des Verkäufers) und Regeln rund um BT-49 (elektronische Adresse des Käufers). Diese Felder sind für Rechnungen an Bundesbehörden verpflichtend.

Für die meisten kleinen Betriebe ist das Gute: Man muss diese Details nicht selbst kennen, wenn die Software die aktuelle Version erzeugt. Wer mit älteren Vorlagen arbeitet, sollte prüfen, ob sein Werkzeug den 3.0.1-Standard unterstützt. Die maßgeblichen Spezifikationen veröffentlicht die KoSIT auf xeinkauf.de.

Von der PDF-Rechnung zur XRechnung – Der Automatisierungsweg

Der einfachste Weg für Betriebe ohne IT-Hintergrund: die gewohnte PDF weiter schreiben und die Umwandlung automatisieren lassen. Bei Belegschmied funktioniert das über den CC-Workflow – Sie versenden Ihre Rechnung wie immer per E-Mail und setzen die Belegschmied-Adresse in CC. Rund 90 Sekunden später liegt beim Empfänger die fertige EN-16931-Rechnung.

Dabei muss die Software die Felder aus der PDF interpretieren. Genau hier stolpert reine Automatik: Kunden-IDs, mehrdeutige Steuerklassifizierungen oder abweichende Summen zwischen sichtbarem Text und Datenebene. Deshalb gilt der Grundsatz: Bei Unklarheit stoppen, nicht überrollen. Ein Betrag, der nicht eindeutig zugeordnet werden kann, darf nicht stillschweigend übernommen werden.

Validierung einer XRechnung – Was wird geprüft?

Die Prüfung läuft auf drei Ebenen:

Formal: Ist das XML strukturell korrekt und schema-konform?
Geschäftsregel: Stimmen die Summen? Passen die Steuerbeträge zu den Positionen?
Kontext: Ist der Empfänger bekannt, passt die Rechnung zum Auftrag?

Fehler werden in Klassen eingeteilt: Info, Warning und Error. Ein Error muss den Versand stoppen. Sie können jede Datei kostenlos mit unserem E-Rechnung-Validator gegen EN 16931 und die KoSIT-Regeln prüfen – anonym, ohne Anmeldung.

Was keine Software prüfen kann: ob die Leistung tatsächlich erbracht wurde. Die technische Korrektheit sagt nichts über die inhaltliche Wahrheit aus.

Häufige Fehler in XRechnung-Beispielen

PDF und XML enthalten unterschiedliche Summen. Steuerlich gilt nur die XML – diese ZUGFeRD-Falle ist besonders tückisch, weil der Fehler unsichtbar bleibt.
Rechnungsnummer doppelt vergeben. Verstößt gegen die Eindeutigkeitspflicht.
Steuersätze falsch klassifiziert (Standard, ermäßigt, null, Reverse Charge).
Empfänger-ID fehlt oder ist falsch formatiert.
Widersprüchliche Zahlungsbedingungen, die Systeme nicht lesen können.
Falsche Zeichenkodierung – ohne sauberes UTF-8 werden Umlaute zu Fragezeichen.

Reverse Charge – Ein spezielles XRechnung-Beispiel

Reverse Charge greift, wenn die Steuerschuld auf den Leistungsempfänger übergeht – etwa bei bestimmten Bauleistungen (§13b UStG) oder grenzüberschreitenden B2B-Dienstleistungen.

Beispiel: Eine deutsche Agentur rechnet an eine belgische GmbH. Der Steuersatz ist 0 %, aber nicht als steuerfrei, sondern mit der Kennung AE (VAT Reverse Charge) und einem Hinweistext. Häufiger Fehler: Reverse Charge ganz vergessen oder mit dem falschen Steuerkategorie-Code versehen. Die korrekte Abbildung steht im Beitrag Reverse Charge in der E-Rechnung.

GoBD-Archivierung und XRechnung

Eine XRechnung ist ein steuerlich relevantes Dokument und muss GoBD-konform archiviert werden: unveränderbar, jederzeit lesbar, mit Audit-Trail und mindestens zehn Jahre Aufbewahrung. In der Praxis bedeutet das Versionskontrolle und Integritätsschutz per SHA-256-Hashing.

Idealerweise passiert das automatisch – die Archivierung sollte ein Schutzbereich sein, keine zusätzliche Aufgabe. Belegschmied legt ein- und ausgehende E-Rechnungen revisionssicher ab, ohne dass Sie manuell etwas ordnen müssen.

Kostenlose XRechnung-Beispiele – aber richtig

Offizielle Beispieldateien finden Sie bei der KoSIT und über das Bundesfinanzministerium. Achtung: Viele im Netz kursierende Beispiele sind veraltet (noch Version 2.x) oder enthalten Fehler. Prüfen Sie jede Download-Datei vor der Produktivnutzung mit einem Validator – nicht blind übernehmen.

Ausnahmen und Sonderregelungen

Kleinbeträge unter 250 €: keine generelle Befreiung von der Pflicht ab 2027/2028.
Kleinunternehmer (§19 UStG): dürfen XRechnung ausstellen, mit reduzierten Anforderungen – Details im Beitrag E-Rechnung als Kleinunternehmer.
B2C: reine Privatkunden-Rechnungen brauchen keine XRechnung.
Steuerfreie Leistungen: werden mit passendem Steuerkategorie-Code und Begründung dokumentiert.

Einen vollständigen Überblick gibt der Beitrag zu allen Ausnahmen von der E-Rechnungspflicht.

Häufig gestellte Fragen

Muss ich sofort umstellen? Nein – die Versandpflicht greift ab 2027/2028. Die Empfangspflicht gilt allerdings bereits seit dem 01.01.2025.

Kann ich meine Word-Vorlagen weiterverwenden? Ja – mit dem CC-Workflow bleibt Ihr gewohnter Prozess erhalten.

Was passiert, wenn ich die Pflicht nicht erfülle? Fehlende E-Rechnungen können zu Problemen beim Vorsteuerabzug und zu erhöhtem Prüfungsfokus führen.

Ist ZUGFeRD besser als XRechnung? Weder noch – sie sind komplementär. ZUGFeRD hat ein sichtbares PDF, XRechnung ist reines XML.

Können kleine Betriebe das technisch überhaupt? Ja, mit der richtigen Software und ohne IT-Kenntnisse.

Fazit & nächste Schritte

XRechnung ist nicht kompliziert – aber die Details zählen. Ein Beispiel zeigt den Aufbau, ersetzt aber nicht das Verständnis für den Kontext: Leistungsdatum, Steuerklassifizierung, korrekte IDs und eine saubere Archivierung entscheiden über eine gültige Rechnung.

Der beste Zeitpunkt zum Anfangen ist jetzt. Testen Sie den Weg von der gewohnten PDF zur fertigen E-Rechnung 30 Tage kostenlos und ohne Kreditkarte – oder stöbern Sie zunächst durch unsere kostenlosen Tools, um ein Gefühl für Erstellung, Validierung und Visualisierung zu bekommen. Wer Begriffe nachschlagen will, findet im E-Rechnung-Glossar alles verständlich erklärt.