Eine ZUGFeRD-Beispielrechnung gelesen: jedes Feld der XML erklärt

Der schnellste Weg, eine ZUGFeRD-Datei zu verstehen, ist keine Spezifikation, sondern eine echte Rechnung, einmal von oben nach unten gelesen. Genau das tut dieser Beitrag mit der Beispielrechnung dieser Seite: eine fiktive Rechnung über IT-Beratung, zwei Scanner und fünf Fachbücher, mit zwei Steuersätzen und SEPA-Zahlung. Sie können die Datei herunterladen und jeden Block mitlesen. Was das Format im Großen ist, welche Profile es gibt und wofür sie stehen, erklärt der Leitfaden zum ZUGFeRD-Format; alle Beispieldateien dieser Website, vom MINIMUM-Profil bis zu den absichtlich fehlerhaften, liegen gesammelt auf der Beispieldateien-Seite. Hier geht es um das Kleine: Was steht in dieser Datei, Zeile für Zeile?

Zur Einordnung: Eine ZUGFeRD-Datei ist ein PDF, in dem die Rechnungsdaten als XML-Datei namens factur-x.xml mitreisen. Was Sie unten sehen, ist der Inhalt dieser eingebetteten Datei. Die Feldnamen wirken sperrig, aber die Struktur ist immer dieselbe: erst der Kopf, dann die Positionen, dann Parteien, Lieferung und Zahlung, zuletzt die Summen.

Der Kopf: Welche Regeln gelten, und welche Rechnung ist das

<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

Die erste inhaltliche Angabe der Datei sagt, nach welchem Regelwerk sie gebaut ist. urn:cen.eu:en16931:2017 steht für das Profil EN 16931, den empfohlenen Standard für den B2B-Austausch. Validatoren lesen zuerst diese Zeile, denn sie entscheidet, welche Prüfregeln gelten.

<rsm:ExchangedDocument>
  <ram:ID>RE-2026-0815</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260615</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>

Drei Angaben, drei Klassiker:

• ID ist die Rechnungsnummer aus dem eigenen Nummernkreis.
• TypeCode 380 heißt „Handelsrechnung". Eine Gutschrift im Sinne einer Rechnungskorrektur trüge 381 oder 384, und an genau diesem Code hängen ganze Prüfketten.
• format="102" bedeutet: Das Datum steht als JJJJMMTT. 20260615 ist der 15. Juni 2026. Wer im XML ein Datum sucht, sucht also eine achtstellige Zahl.

In Fehlermeldungen von Validatoren tauchen für diese Felder Kürzel wie BT-1 (Rechnungsnummer) oder BT-3 (Rechnungstyp) auf: Die Norm nummeriert jedes Geschäftsfeld durch, und die XML-Elemente sind nur deren technische Adressen.

Die Positionen: eine Zeile der Rechnung, ein Block im XML

Jede Rechnungsposition ist ein IncludedSupplyChainTradeLineItem. Die erste Position der Beispieldatei, acht Stunden IT-Beratung, sieht so aus:

<ram:IncludedSupplyChainTradeLineItem>
  <ram:AssociatedDocumentLineDocument>
    <ram:LineID>1</ram:LineID>
  </ram:AssociatedDocumentLineDocument>
  <ram:SpecifiedTradeProduct>
    <ram:Name>IT-Beratung</ram:Name>
    <ram:Description>Einrichtung E-Rechnungs-Workflow</ram:Description>
  </ram:SpecifiedTradeProduct>
  <ram:SpecifiedLineTradeAgreement>
    <ram:NetPriceProductTradePrice>
      <ram:ChargeAmount>120.00</ram:ChargeAmount>
      <ram:BasisQuantity unitCode="HUR">1.0000</ram:BasisQuantity>
    </ram:NetPriceProductTradePrice>
  </ram:SpecifiedLineTradeAgreement>
  <ram:SpecifiedLineTradeDelivery>
    <ram:BilledQuantity unitCode="HUR">8.0000</ram:BilledQuantity>
  </ram:SpecifiedLineTradeDelivery>
  <ram:SpecifiedLineTradeSettlement>
    <ram:ApplicableTradeTax>
      <ram:TypeCode>VAT</ram:TypeCode>
      <ram:CategoryCode>S</ram:CategoryCode>
      <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
    </ram:ApplicableTradeTax>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>960.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>

Von oben nach unten:

• LineID nummeriert die Position.
• Name und Description sind Bezeichnung und Zusatztext, wie auf jeder Rechnung.
• ChargeAmount 120.00 mit BasisQuantity 1 HUR heißt: Der Preis gilt je einer Stunde. HUR ist der Einheiten-Code für Stunde aus der Codeliste UN/ECE Rec 20; eine Einheit steht im XML nie als Wort, immer als Code.
• BilledQuantity 8 HUR: abgerechnet werden acht Stunden.
• CategoryCode S mit 19.00: regelbesteuert zum Regelsatz. Die Kategorie ist eine eigene Angabe neben dem Prozentsatz, und bei 0-Prozent-Fällen wird sie zur eigentlichen Information.
• LineTotalAmount 960.00: der Nettobetrag der Zeile, 8 mal 120.

Die zwei weiteren Positionen der Datei folgen demselben Muster und variieren nur die Werte: zwei Dokumentenscanner zu je 349 Euro mit dem Einheiten-Code C62 (Stück), und fünf Fachbücher zu 24,90 Euro, als Bücher mit 7 Prozent statt 19. Dieser dritte Block ist der interessanteste, denn er zwingt die Datei weiter unten zu zwei getrennten Steuerblöcken.

Die Parteien: getrennte Felder statt Adresszeile

<ram:SellerTradeParty>
  <ram:Name>Muster &amp; Soehne GmbH</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID>HRB 98765</ram:ID>
  </ram:SpecifiedLegalOrganization>
  <ram:DefinedTradeContact>
    <ram:PersonName>Petra Muster</ram:PersonName>
    ...
  </ram:DefinedTradeContact>
  <ram:PostalTradeAddress>
    <ram:PostcodeCode>10115</ram:PostcodeCode>
    <ram:LineOne>Lindenallee 12</ram:LineOne>
    <ram:CityName>Berlin</ram:CityName>
    <ram:CountryID>DE</ram:CountryID>
  </ram:PostalTradeAddress>
  <ram:SpecifiedTaxRegistration>
    <ram:ID schemeID="VA">DE123456789</ram:ID>
  </ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>

Der Verkäuferblock zeigt zwei Eigenheiten des Formats. Erstens: Die Anschrift steht in getrennten Feldern, mit dem Land als Zwei-Buchstaben-Code; eine zusammengeklebte Adresszeile gibt es nicht. Zweitens: Das kleine schemeID="VA" sagt, dass die Nummer eine Umsatzsteuer-Identifikationsnummer ist; eine Steuernummer trüge FC. Ein Kontakt mit Name, Telefon und E-Mail steht hier ebenfalls, im Beispiel Petra Muster mit Berliner Durchwahl.

Der Käuferblock ist das Spiegelbild mit weniger Pflichten: Name, Anschrift, USt-IdNr. Dazwischen steht mit BuyerOrderReferencedDocument die Bestellnummer des Kunden, BEST-2026-0421, damit dessen Buchhaltung die Rechnung dem Vorgang zuordnen kann. Das Lieferdatum ist ein eigener kleiner Block: der 15. Juni 2026, wieder als format="102".

Zahlung und Steuern: die Blöcke, die Prüfungen scheitern lassen

<ram:SpecifiedTradeSettlementPaymentMeans>
  <ram:TypeCode>58</ram:TypeCode>
  <ram:PayeePartyCreditorFinancialAccount>
    <ram:IBANID>DE89370400440532013000</ram:IBANID>
  </ram:PayeePartyCreditorFinancialAccount>
  ...
</ram:SpecifiedTradeSettlementPaymentMeans>

TypeCode 58 ist der Code für die SEPA-Überweisung, gefolgt von IBAN und BIC des Verkäufers. Auch die Zahlungsart ist also ein Code, keine Formulierung wie „Überweisung aufs bekannte Konto".

Dann die Stelle, an der die dritte Position ihre Wirkung zeigt:

<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>315.02</ram:CalculatedAmount>
  <ram:BasisAmount>1658.00</ram:BasisAmount>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>8.72</ram:CalculatedAmount>
  <ram:BasisAmount>124.50</ram:BasisAmount>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>7.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>

Je Steuersatz ein Block. Die Beratung und die Scanner (960 plus 698 gleich 1.658 Euro) sammeln sich im 19-Prozent-Block mit 315,02 Euro Steuer, die Bücher (124,50 Euro) im 7-Prozent-Block mit 8,72 Euro. Gerundet wird einmal je Block, nicht je Position, und die Basisbeträge müssen exakt die Summe der zugehörigen Zeilen sein. Diese Aufstellung ist das häufigste Opfer handgestrickter Rechnungen; warum, zeigt der Summen-Beitrag zu BR-CO-10.

Daneben stehen die Zahlungsbedingungen als Text („Zahlbar innerhalb von 30 Tagen ohne Abzug.") mit dem Fälligkeitsdatum 15. Juli 2026 als Datumsfeld: Der Mensch liest den Satz, die Maschine das Feld.

Der Summenblock: fünf Zahlen, eine Kette

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1782.50</ram:LineTotalAmount>
  <ram:TaxBasisTotalAmount>1782.50</ram:TaxBasisTotalAmount>
  <ram:TaxTotalAmount currencyID="EUR">323.74</ram:TaxTotalAmount>
  <ram:GrandTotalAmount>2106.24</ram:GrandTotalAmount>
  <ram:DuePayableAmount>2106.24</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Ganz unten schließt sich die Rechnung: die Summe aller Positionen (1.782,50), daraus die Steuerbasis, die Steuer aus beiden Blöcken (315,02 plus 8,72 gleich 323,74), Brutto (2.106,24) und der zu zahlende Betrag. Jede dieser Zahlen ist aus den vorigen herleitbar, und genau das rechnet ein Prüfprogramm nach. Wer die Datei im ZUGFeRD-Validator prüft, sieht diese Kette bestätigt; wer sie lieber als gewohnte Rechnung ansieht, öffnet sie im XRechnung-Viewer, der auch ZUGFeRD-PDFs darstellt.

Was Sie aus zehn Minuten Lesen mitnehmen

1. Alles Fachliche ist ein Code: Rechnungstyp 380, Einheit HUR, Kategorie S, Zahlungsart 58, Land DE. Freitext ist die Ausnahme, nicht die Regel.
2. Jede Zahl hängt an einer Kette: Zeilen ergeben Steuerbasen, Steuerbasen ergeben Summen. Nichts steht isoliert.
3. Die BT-Nummern sind Ihr Wörterbuch: Wenn eine Fehlermeldung BT-31 nennt, ist damit ein konkretes Feld gemeint, und Sie können es in der Datei ansteuern.

Mit diesem Blick sind auch die Fehlermeldungen der Prüfprogramme keine Hieroglyphen mehr, sondern Wegweiser zu einem Feld, das Sie jetzt finden.

Rechtsstand: Oktober 2026, zuletzt geprüft am 29. September 2026. Grundlage sind die Norm EN 16931 mit den Codelisten UN/ECE Rec 20 und UNTDID/UNCL sowie die ZUGFeRD-Spezifikation von FeRD. Die Beispieldatei enthält fiktive Werte. Dieser Artikel ist keine Steuerberatung.

Häufige Fragen

Wo steckt die XML in einer ZUGFeRD-Rechnung?

Als eingebettete Datei namens factur-x.xml im PDF. Das PDF ist ein PDF/A-3, ein Archivformat, das Anhänge erlaubt; die Rechnung reist also als Dokument und als Datensatz in derselben Datei.

Was bedeutet TypeCode 380?

380 ist der Code für eine gewöhnliche Handelsrechnung. Rechnungskorrekturen tragen 381 oder 384. Der Code entscheidet mit, welche Prüfregeln gelten und wie das Empfängersystem die Datei verbucht.

Warum enthält die Datei zwei ApplicableTradeTax-Blöcke?

Weil sie zwei Steuersätze enthält: 19 Prozent für Beratung und Scanner, 7 Prozent für die Bücher. Das Format verlangt je Satz und Kategorie einen eigenen Block mit eigener Basis und eigener Steuer, und gerundet wird je Block genau einmal.

Was heißt format="102" bei den Datumsangaben?

Das ist der Code für die Schreibweise JJJJMMTT: 20260615 ist der 15. Juni 2026. Alle Datumsangaben der Datei folgen diesem Muster, ob Rechnungs-, Liefer- oder Fälligkeitsdatum.

Ist die Beispieldatei eine gültige E-Rechnung?

Ja, sie ist eine gültige Datei im Profil EN 16931 mit fiktiven Werten und eignet sich zum Testen von Viewer, Validator und Buchhaltungssoftware. Nur bezahlen sollte sie niemand.