Die XML-Struktur einer ZUGFeRD-Rechnung: Felder und Gruppen

Die sichtbare Seite einer ZUGFeRD-Rechnung ist für Menschen. Die eingebettete XML ist für Software — und sie liest keinen Briefkopf, sondern Felder mit festen Namen an festen Plätzen. Diese Seite zeigt, welche Felder es gibt, wo sie liegen und welche davon in der Praxis über Annahme oder Ablehnung entscheiden.

Die XML folgt der UN/CEFACT-Syntax Cross Industry Invoice (CII) — einer der beiden Syntaxen, die EN 16931 anerkennt. Die andere ist UBL, im Peppol-Netz verbreitet. Inhaltlich sagen beide dasselbe; sie buchstabieren es nur anders.

Die drei Blöcke

• ExchangedDocumentContext — wonach das Dokument gebaut ist. Hier steht die Profilkennung BT-24 (siehe Profile), und nur hier. Ein Empfänger liest sie zuerst, weil sie bestimmt, gegen welches Regelwerk er prüft.
• ExchangedDocument — die Identität der Rechnung: Nummer BT-1, Typcode BT-3, Ausstellungsdatum BT-2 und Freitexte.
• SupplyChainTradeTransaction — alles Übrige, in drei Gruppen: TradeAgreement (wer mit wem, unter welchen Referenzen), TradeDelivery (was wann wohin) und TradeSettlement (Zahlung, Steuer, Summen).

Jede Rechnungsposition liegt als eigenes IncludedSupplyChainTradeLineItem in der Transaktion — und wiederholt darin dieselbe Dreiteilung im Kleinen: Preisvereinbarung, gelieferte Menge, Abrechnung der Position.

Warum die Felder BT und BG heißen

Die Norm beschreibt zuerst die Bedeutung und erst danach die Schreibweise. Ein BT (Business Term) ist ein einzelnes Feld, ein BG (Business Group) eine Gruppe zusammengehöriger Felder. „Name des Verkäufers“ ist BT-27, egal ob das Dokument in CII oder UBL geschrieben ist — die XML-Elemente heißen unterschiedlich, das Feld ist dasselbe.

Praktisch heißt das: Wenn ein Prüfbericht BT-31 beanstandet, brauchen Sie den XML-Pfad nicht zu kennen. Sie brauchen zu wissen, welche Angabe fehlt — hier die USt-IdNr. des Verkäufers. Die Regelcodes, die auf diese Felder verweisen, stehen in Geschäftsregeln.

Was jede Rechnung tragen muss

Die folgenden Felder verlangt die Norm ohne Ausnahme. Fehlt eines, meldet die Prüfung eine BR-*-Regel und das Dokument ist ungültig.

Auffällig ist, was hier nicht steht: die USt-IdNr. Sie ist nicht immer Pflicht — aber sobald Sie Steuer ausweisen oder Reverse Charge anwenden, verlangt sie BR-CO-09 samt Länderpräfix.

Verkäuferangaben: der Briefkopf als Felder

Auf Papier ist der Verkäufer das, was oben links steht. In der XML sind es benannte Felder, und die Software des Empfängers liest diese, nicht Ihr Layout.

• BT-27 — Name des Verkäufers. Der rechtliche Name, nicht die Marke aus dem Logo.
• BG-5 — Postanschrift, mit Ländercode. Ohne Ländercode kommt die Rechnung nicht durch.
• BT-31 — USt-IdNr., mit Präfix (DE…, FR…).
• BT-32 — Steuernummer, wo statt der USt-IdNr. verwendet.

Ein Tippfehler in BT-31 ist der teuerste unter den billigen Fehlern: Er fällt beim Erstellen nicht auf, wiederholt sich auf jeder Rechnung des Jahres und taucht erst auf, wenn ein Empfänger die Nummer prüft. Deshalb gehören diese Angaben einmal ins Firmenprofil und nicht in jede Rechnung neu getippt.

Käuferreferenz und Bestellnummer: die Felder, die über die Zahlung entscheiden

Eine rechnerisch einwandfreie Rechnung kann aus einem Grund zurückkommen, der mit Beträgen nichts zu tun hat: Der Empfänger kann sie keiner Stelle, keinem Vertrag und keiner Bestellung zuordnen.

• BT-10 — Käuferreferenz. Eine Kennung, die der Kunde vorab nennt. Bei öffentlichen Auftraggebern ist das die Leitweg-ID, und die deutsche Regel BR-DE-15 macht das Feld verpflichtend.
• BT-13 — Bestellreferenz. Die Bestellnummer des Kunden, mit der sein System Rechnung und Bestellung automatisch zusammenführt.

Große private Auftraggeber arbeiten inzwischen genauso: keine Referenz, keine automatische Verbuchung. Fragen Sie beides bei der Beauftragung ab, nicht erst in der Mahnung.

Lieferdatum und Abrechnungszeitraum — zwei verschiedene Dinge

Eine Rechnung trägt mindestens zwei Daten mit verschiedener Bedeutung, und ihre Verwechslung gehört zu den leiseren Quellen von Ärger.

Das deutsche Recht verlangt den Zeitpunkt der Leistung auf der Rechnung. Ihn in der strukturierten Datei wegzulassen ist also keine Formfrage. Bei wiederkehrender Abrechnung sagt der Zeitraum dem Empfänger außerdem ohne einen Blick in den Positionstext, wofür er zahlt — und BR-29 achtet darauf, dass das Startdatum nicht hinter dem Enddatum liegt.

Positionen: Menge, Einheit, Preis

Eine Position trägt vier Angaben, die zusammengehören:

• BT-129 — die Menge;
• BT-130 — der Code der Mengeneinheit;
• BT-146 — der Einzelpreis;
• BT-131 — der Nettobetrag der Position.

Die Einheit ist kein Freitext. „Stk.“, „Paket“ oder „Std.“ genügen nicht — verlangt ist ein Code aus der Liste UN/ECE Recommendation 20, damit beide Systeme dasselbe darunter verstehen.

Rabatte, Zuschläge und Versand

Eine Zeile „minus 10 %“ ist für Menschen lesbar und für Software bedeutungslos. Die Norm hat dafür eigene Plätze: BG-20 für Nachlässe und BG-21 für Zuschläge auf Dokumentebene, dazu die Entsprechungen auf jeder Position.

Jeder Nachlass und jeder Zuschlag trägt drei Dinge:

• einen Betrag — BT-92 beim Nachlass, BT-99 beim Zuschlag;
• einen Grund, als Klartext oder als Code (BT-98 bzw. BT-105), damit der Empfänger richtig verbucht;
• Steuerkategorie und Steuersatz, denn ein Rabatt mindert die Bemessungsgrundlage und folgt derselben steuerlichen Behandlung.

Versand, Verpackung und Zahlungszuschläge gehören ebenfalls hierher und nicht in den Einzelpreis. So ausgewiesen überstehen sie die Rundungsprüfungen des Empfängers; im Einzelpreis versteckt, erzeugen sie BR-CO-*-Differenzen, die hinterher niemand mehr zuordnen kann.

Zahlungsbedingungen

„Zahlbar innerhalb von 14 Tagen“ ist ein Satz. In der strukturierten Rechnung wird daraus:

• BT-9 — das Fälligkeitsdatum als konkretes Datum, nicht als Beschreibung;
• BT-20 — die Zahlungsbedingungen im Text, einschließlich Skonto;
• BG-16 — die Zahlungsanweisung: Zahlungsmittel, IBAN, Kontoinhaber.

Der Sinn: Das System des Empfängers kann die Zahlung einplanen, ohne Freitext zu lesen. Ein Fälligkeitsdatum als Satz statt als Datum bedeutet in der Praxis, dass Ihre Rechnung in der Warteschlange landet, in der jemand sie von Hand anfasst.

Mehr als eine Währung

Wird die Rechnung in einer Währung ausgestellt, die Umsatzsteuer aber in einer anderen abgeführt, verlangt die Norm beides ausdrücklich statt einer Annahme:

• BT-5 — die Währung der Rechnung;
• BT-6 — die Währung der Steuerabrechnung, wenn sie abweicht;
• den Umrechnungskurs zum Ausstellungsdatum.

Fehlen diese Felder, ist das ein häufiger Grund für abgelehnte grenzüberschreitende Rechnungen — und einer, den man an den Beträgen nicht sieht.

Eine Gutschrift ist keine Rechnung mit Minus

Das ist der Fehler, den Buchhalter mitbringen, die von einfachen PDFs kommen. In der Norm ist die Gutschrift ein eigener Dokumenttyp, gesteuert über BT-3:

• 380 — Rechnung;
• 381 — Gutschrift.

Die Beträge stehen darin positiv; die Richtung ergibt sich aus dem Typcode. Dazu gehört der Verweis auf das korrigierte Dokument — BG-3 mit der Nummer der Vorgängerrechnung (BT-25), auf das BR-55 achtet. Eine „Rechnung mit negativen Beträgen“ besteht die Prüfung nicht und ist für den Empfänger auch nicht verbuchbar.

Häufige Fragen

Muss ich die XML von Hand schreiben können?

Nein. Sie sollten lesen können, was ein Prüfbericht meldet — das ist etwas anderes. Ein Bericht nennt den Regelcode und das Feld; von dort führt der Weg in das System, das die Rechnung erzeugt, nicht in einen XML-Editor.

Wo finde ich das Profil in der Datei?

Im Element GuidelineSpecifiedDocumentContextParameter im ersten Block, das ist BT-24. Welche URN was bedeutet, steht in Profile.

Ist CII besser als UBL?

Nein, es ist eine andere Schreibweise desselben Modells. ZUGFeRD und Factur-X verwenden CII, Peppol überwiegend UBL. Wenn Ihnen jemand UBL vorgibt, geht es um das Netz, über das er empfängt, nicht um die Qualität der Daten.

Darf ich eigene Felder ergänzen?

Nur über das Profil EXTENDED, und auch dann versteht sie nur eine Software, die sie kennt. Alles, was die Norm abbildet, gehört in ihre eigenen Felder — dort wird es gelesen.

Warum beanstandet die Prüfung eine Summe, obwohl die Seite stimmt?

Weil sie die Felder rechnet, nicht die Seite. Die häufigste Ursache sind Rabatte, die im Einzelpreis stecken, statt als BG-20 ausgewiesen zu sein. Die Regelfamilien dazu stehen in Geschäftsregeln.

Muss die XML mit der sichtbaren Seite übereinstimmen?

Ja, und im Zweifel gilt die XML. Das BMF-Schreiben vom 15. Oktober 2025 stellt für Hybridformate klar, dass der strukturierte Teil maßgeblich ist; weichen die Teile voneinander ab, steht der Vorsteuerabzug im Risiko.

Wie sehe ich mir die XML einer eingegangenen Rechnung an?

Am einfachsten über eine Prüfung — der Bericht zeigt Profil, Felder und Befunde. Das Vorgehen im Einzelnen steht in Rechnung prüfen.

Kurz zusammengefasst

• Drei Blöcke, und im dritten steckt fast alles — Summen und Steuer liegen ganz unten in der Abwicklung.
• BT ist ein Feld, BG eine Gruppe. Die Nummer ist syntaxunabhängig: BT-27 ist in CII und UBL derselbe Verkäufername.
• Zwölf Felder sind ausnahmslos Pflicht, die USt-IdNr. kommt hinzu, sobald Steuer ausgewiesen wird.
• BT-10 und BT-13 entscheiden über die Zahlung, nicht über die Gültigkeit — beim öffentlichen Auftraggeber macht BR-DE-15 daraus eine Pflicht.
• Einheiten sind Codes aus UN/ECE Rec 20, kein Freitext.
• Rabatte gehören in BG-20, nicht in den Einzelpreis — sonst gehen die Summen nicht auf.
• Gutschrift heißt Typcode 381 mit positiven Beträgen und Verweis auf die Ursprungsrechnung.

Die XML hinter Ihren eigenen Rechnungen sehen, ohne sie zu bauen? Kostenloses Konto anlegen — oder eine vorhandene Datei ohne Anmeldung prüfen und den Aufbau am eigenen Dokument nachvollziehen.