ZUGFeRD-Rechnung: Beispiel mit PDF-Ansicht und XML erklärt

Wie sieht eine ZUGFeRD-Rechnung eigentlich aus? Die kurze Antwort: wie jede andere PDF-Rechnung. Die lange Antwort ist interessanter, denn in derselben Datei steckt eine zweite Rechnung, die kein Mensch liest – und die für das Finanzamt und die Buchhaltungssoftware Ihres Kunden die eigentliche ist. Dieser Artikel zeigt beide Seiten an einer durchgängigen Beispielrechnung: erst den Beleg, wie er auf dem Bildschirm erscheint, dann das XML, das darunter liegt, Feld für Feld erklärt.

Was Sie sehen und was drinsteckt

Eine ZUGFeRD-Datei hat zwei Ebenen. Die PDF/A-3 ist die Ansicht: Briefkopf, Anschrift, Positionen, Summen. Sie öffnen sie mit jedem PDF-Reader. Das eingebettete XML namens factur-x.xml ist der Datensatz: dieselben Angaben in benannten Feldern nach der Norm EN 16931, in der Syntax UN/CEFACT CII.

Beide müssen übereinstimmen. Steht in der PDF 902,02 Euro und im XML 902,00, ist die Rechnung fehlerhaft – und das BMF hat im Schreiben vom 15.10.2025 festgelegt, dass in diesem Fall die Daten des XML-Teils vor denen der Bilddatei gelten. Wie das Format aufgebaut ist und welche Versionen und Profile es gibt, erklärt der Artikel ZUGFeRD-Format und Versionen; die Grundlagen stehen im Leitfaden ZUGFeRD.

Die Beispielrechnung

Ein fiktiver Elektrobetrieb stellt einem Gewerbekunden eine Installation in Rechnung. Zwei Positionen, Regelbesteuerung mit 19 Prozent, Zahlungsziel 14 Tage. So sieht der sichtbare Teil aus:

Die Rechnungsnummer 0018-2609-BAUER liest sich so: laufende Nummer 18, ausgestellt im September 2026, Kunde Bauer. Die laufende Nummer vorn ist firmenweit fortlaufend; das Kürzel hinten ist eine Zusatzinformation, die vom Wortlaut des § 14 Abs. 4 Satz 1 Nr. 4 UStG gedeckt ist – dort verlangt ist nur eine einmalige, fortlaufende Nummer „mit einer oder mehreren Zahlenreihen". Warum das praktisch ist, erklärt der Artikel Rechnungsnummer pro Kunde.

Alle Beträge gehen auf: 8 × 85,00 = 680,00; 12 × 6,50 = 78,00; Summe 758,00; davon 19 Prozent sind 144,02; zusammen 902,02. Das ist keine Nebensache – der Validator rechnet genau das nach.

Dasselbe als XML

Hier der eingebettete Datensatz, gekürzt auf die tragenden Elemente. Der vollständige Baum ist etwa doppelt so lang; ausgelassen sind die zweite Position, Adressen und Bankverbindung.

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

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

  <rsm:ExchangedDocument>
    <ram:ID>0018-2609-BAUER</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260911</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>

  <rsm:SupplyChainTradeTransaction>

    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Installation Unterverteilung</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>85.00</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">8.00</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>680.00</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>

    <!-- Position 2 (Leitungsschutzschalter, 12 × 6,50 = 78,00) analog -->

    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>Meier Elektrotechnik</ram:Name>
        <!-- PostalTradeAddress, E-Mail-Adresse -->
        <ram:SpecifiedTaxRegistration>
          <ram:ID schemeID="VA">DE123456789</ram:ID>
        </ram:SpecifiedTaxRegistration>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Bauer GmbH</ram:Name>
        <!-- PostalTradeAddress, E-Mail-Adresse -->
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>

    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:ApplicableTradeTax>
        <ram:CalculatedAmount>144.02</ram:CalculatedAmount>
        <ram:TypeCode>VAT</ram:TypeCode>
        <ram:BasisAmount>758.00</ram:BasisAmount>
        <ram:CategoryCode>S</ram:CategoryCode>
        <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
      </ram:ApplicableTradeTax>
      <ram:SpecifiedTradePaymentTerms>
        <ram:DueDateDateTime>
          <udt:DateTimeString format="102">20260925</udt:DateTimeString>
        </ram:DueDateDateTime>
      </ram:SpecifiedTradePaymentTerms>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>758.00</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>758.00</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">144.02</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>902.02</ram:GrandTotalAmount>
        <ram:DuePayableAmount>902.02</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>

  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Drei Dinge fallen auf. Erstens die Namensräume am Anfang: rsm für das Dokument selbst, ram für die wiederverwendbaren Bausteine (fast alles), udt für einfache Datentypen wie das Datum. Zweitens die Codes statt Wörter: 380 statt „Rechnung", S statt „Regelsteuersatz", HUR statt „Stunde", 20260911 statt „11.09.2026". Drittens die Summen in drei Stufen: Position (LineTotalAmount 680,00), Steueraufschlüsselung (BasisAmount 758,00 → CalculatedAmount 144,02) und Gesamtsumme (GrandTotalAmount 902,02). Alle drei müssen zusammenpassen.

Die vollständige Fassung dieses Beispiels haben wir mit dem Referenzvalidator Mustangproject gegen das Profil EN 16931 geprüft: keine Fehler.

Die wichtigsten Felder erklärt

Die EN 16931 gibt jedem Feld eine Nummer, den Business Term (BT). Diese Nummern tauchen in Fehlermeldungen von Validatoren auf – wer sie kennt, versteht die Meldung. Die Felder aus dem Beispiel:

Die Spezifikation definiert weit mehr Felder – Leistungszeitraum, Leitweg-ID, Rabatte, Vorauszahlungen. Für eine gewöhnliche Rechnung sind die zwölf oben plus Adressen, Positionen und E-Mail-Adressen das, was zählt. Was der Gesetzgeber unabhängig vom Format auf jeder Rechnung verlangt, listet der Artikel Pflichtangaben auf der Rechnung.

Wo Sie offizielle Beispieldateien finden

Das FeRD liefert mit jeder Spezifikation ein Paket mit Beispieldateien je Profil – vollständige ZUGFeRD-PDFs samt XML, dazu ein Stylesheet, das das XML lesbar anzeigt. Kostenlos nach Registrierung auf ferd-net.de.

Das Mustangproject pflegt auf GitHub eine Sammlung von Testdateien (github.com/ZUGFeRD/corpus): gültige ZUGFeRD- und Factur-X-Dateien in mehreren Versionen und Profilen, außerdem absichtlich fehlerhafte Dateien zum Testen von Validatoren. Die Sammlung versteht sich als Community-Projekt, nicht als offizielle FeRD-Veröffentlichung – zum Lernen und Testen taugt sie trotzdem.

Wie Sie das XML aus einer ZUGFeRD-PDF holen

Sie haben eine ZUGFeRD-Rechnung bekommen und möchten hineinsehen? Drei Wege:

Im PDF-Reader. Öffnen Sie die Datei in einem vollwertigen Reader – Adobe Acrobat Reader, Foxit, PDF-XChange. Der Browser reicht nicht. Klicken Sie auf das Büroklammer-Symbol (Anhänge). Dort liegt factur-x.xml; Sie können es speichern und in einem Texteditor öffnen.

Im Quba-Viewer. Das kostenlose Open-Source-Programm für Windows, macOS und Linux (quba-viewer.org) öffnet die PDF, zeigt die Rechnung an und daneben den XML-Inhalt in lesbarer Form. Die Datei bleibt auf Ihrem Rechner.

Mit Mustangproject. Wer die Kommandozeile nicht scheut, extrahiert das XML mit einem Befehl: java -jar Mustang-CLI-2.26.0.jar --action extract --source rechnung.pdf --out factur-x.xml. Dasselbe Werkzeug prüft die Datei auch – wie, steht im Artikel ZUGFeRD-Validator.

Was das Beispiel für Ihre eigenen Rechnungen heißt

Das XML entsteht nicht aus der PDF, sondern aus den Rechnungsdaten – Kunde, Positionen, Steuersatz, Zahlungsziel. Fehlt eines davon oder ist es nur als Freitext vorhanden („Stück" statt H87, „19 %" statt 19.00), kann kein normkonformes XML entstehen. Deshalb gehört die Prüfung der Pflichtfelder an den Anfang, nicht ans Ende: Wer die Rechnung erst festschreibt und dann merkt, dass die E-Mail-Adresse des Kunden fehlt, kann sie nur noch stornieren.

Häufige Fragen