Wie sieht eine E-Rechnung als Muster aus?

Eine E-Rechnung ist im Kern ein strukturierter XML-Datensatz nach EN 16931. Ein Muster besteht aus einem Kopf (Rechnungsnummer, Datum, Rechnungsart, Währung), den Parteien (Verkäufer mit USt-IdNr., Käufer), mindestens einer Rechnungsposition, einer Umsatzsteuer-Aufschlüsselung und den Gesamtsummen. Bei XRechnung ist das reines XML (UBL oder CII), bei ZUGFeRD/Factur-X steckt dasselbe XML zusätzlich in einem PDF.

Welche Felder muss ein E-Rechnungs-Muster mindestens enthalten?

EN 16931 verlangt unter anderem: Rechnungsnummer (BT-1), Rechnungsdatum (BT-2), Rechnungsart (BT-3), Währung (BT-5), Verkäufer inklusive USt-IdNr. (BG-4/BT-31), Käufer (BG-7), je Position Menge, Einzelpreis und Positionsnetto (BG-25), eine Umsatzsteuer-Aufschlüsselung je Steuersatz (BG-23) und die Dokumentsummen (BG-22). Fehlt ein Pflichtfeld, ist die Datei technisch unvollständig.

Wo bekomme ich ein echtes, valides E-Rechnungs-Muster?

Am verlässlichsten erzeugen Sie eines: fakturai generiert aus Ihren Daten eine ZUGFeRD-/Factur-X- oder XRechnung-Datei und prüft sie vor der Auslieferung gegen ein KoSIT-orientiertes Akzept-Gate. Eine vorhandene Beispieldatei können Sie kostenlos im Validator gegen EN 16931 prüfen.

Muster & Beispiel

E-Rechnung Muster & XRechnung-Beispiel (XML): so ist eine E-Rechnung aufgebaut

Kurz gesagt: Eine E-Rechnung ist kein hübsches PDF, sondern ein strukturierter Datensatz nach EN 16931. Ein Muster besteht immer aus denselben Bausteinen: Kopfdaten, Verkäufer und Käufer, Rechnungspositionen, einer Umsatzsteuer-Aufschlüsselung und den Summen. Unten sehen Sie einen annotierten XRechnung-XML-Ausschnitt mit den wichtigsten EN-16931-Feldern (BT-/BG-Codes) — und wie Sie daraus eine wirklich valide Datei machen.

Die Bausteine einer E-Rechnung (EN 16931)

Ob XRechnung (reines XML) oder ZUGFeRD/Factur-X (PDF mit eingebettetem XML) — inhaltlich tragen beide dieselben Felder. EN 16931 ordnet sie in Business Terms (BT-…) und Business Groups (BG-…). Diese Bausteine muss jedes Muster mindestens abbilden:

Baustein	EN-16931-Code	Beispiel
Rechnungsnummer	BT-1	RE-2026-0042
Rechnungsdatum	BT-2	2026-06-16
Rechnungsart	BT-3	380 (Rechnung)
Währung	BT-5	EUR
Leitweg-ID (nur B2G)	BT-10	04011000-12345-67
Verkäufer + USt-IdNr.	BG-4 / BT-31	Muster GmbH, DE123456789
Käufer	BG-7	Kunde AG
Rechnungsposition (Menge, Einzelpreis, Netto)	BG-25	2 × 50,00 € = 100,00 €
USt-Aufschlüsselung je Satz	BG-23	19 % auf 100,00 € = 19,00 €
Dokumentsummen	BG-22	Netto 100,00 € · Brutto 119,00 €

XRechnung-Beispiel (UBL-XML, annotiert)

Der folgende Ausschnitt zeigt eine XRechnung im UBL-Syntax mit den zentralen Pflichtbausteinen. Die Kommentare nennen den jeweiligen EN-16931-Code. Wichtig: Das ist ein bewusst vereinfachtes Lehrbeispiel, keine vollständig valide Datei — eine echte XRechnung 3.0 verlangt weitere Pflichtangaben (z. B. elektronische Adresse des Verkäufers, Zahlungsbedingungen, Kontaktdaten).

<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice
  xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
  <cbc:ID>RE-2026-0042</cbc:ID>                              <!-- BT-1  Rechnungsnummer -->
  <cbc:IssueDate>2026-06-16</cbc:IssueDate>                  <!-- BT-2  Rechnungsdatum -->
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>             <!-- BT-3  Rechnungsart (380 = Rechnung) -->
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>   <!-- BT-5  Währung -->
  <cbc:BuyerReference>04011000-12345-67</cbc:BuyerReference> <!-- BT-10 Leitweg-ID (nur B2G) -->

  <cac:AccountingSupplierParty>                              <!-- BG-4  Verkäufer -->
    <cac:Party>
      <cac:PartyName><cbc:Name>Muster GmbH</cbc:Name></cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cbc:PostalZone>10115</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE123456789</cbc:CompanyID>            <!-- BT-31 USt-IdNr. -->
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingCustomerParty>                              <!-- BG-7  Käufer -->
    <cac:Party>
      <cac:PartyName><cbc:Name>Kunde AG</cbc:Name></cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Kundenweg 2</cbc:StreetName>
        <cbc:CityName>München</cbc:CityName>
        <cbc:PostalZone>80331</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">19.00</cbc:TaxAmount>     <!-- BT-110 USt-Gesamtbetrag -->
    <cac:TaxSubtotal>                                        <!-- BG-23 USt-Aufschlüsselung -->
      <cbc:TaxableAmount currencyID="EUR">100.00</cbc:TaxableAmount> <!-- BT-116 -->
      <cbc:TaxAmount currencyID="EUR">19.00</cbc:TaxAmount>          <!-- BT-117 -->
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>                                  <!-- BT-118 USt-Kategorie (S = Regelsatz) -->
        <cbc:Percent>19.00</cbc:Percent>                    <!-- BT-119 USt-Satz -->
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <cac:LegalMonetaryTotal>                                   <!-- BG-22 Summen -->
    <cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount> <!-- BT-106 -->
    <cbc:TaxExclusiveAmount currencyID="EUR">100.00</cbc:TaxExclusiveAmount>   <!-- BT-109 -->
    <cbc:TaxInclusiveAmount currencyID="EUR">119.00</cbc:TaxInclusiveAmount>   <!-- BT-112 -->
    <cbc:PayableAmount currencyID="EUR">119.00</cbc:PayableAmount>             <!-- BT-115 Zahlbetrag -->
  </cac:LegalMonetaryTotal>

  <cac:InvoiceLine>                                          <!-- BG-25 Rechnungsposition -->
    <cbc:ID>1</cbc:ID>                                       <!-- BT-126 -->
    <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>              <!-- BT-129 Menge (C62 = Stück) -->
    <cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount> <!-- BT-131 Positionsnetto -->
    <cac:Item>
      <cbc:Name>Beratungsleistung</cbc:Name>                <!-- BT-153 Artikelname -->
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID><cbc:Percent>19.00</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">50.00</cbc:PriceAmount>               <!-- BT-146 Einzelpreis (netto) -->
    </cac:Price>
  </cac:InvoiceLine>
</ubl:Invoice>

XRechnung vs. ZUGFeRD: derselbe Datensatz, andere Verpackung

Ein XRechnung-Beispiel ist eine einzelne .xml-Datei. Ein ZUGFeRD-/Factur-X-Muster ist dagegen ein PDF/A-3 mit demselben Datensatz als eingebettetem CII-XML — Sie sehen also eine lesbare Rechnung und tragen den maschinenlesbaren Teil unsichtbar mit. Beide erfüllen die Pflicht, sofern sie ein EN-16931-konformes Profil nutzen (bei ZUGFeRD ab Profil COMFORT / EN 16931, nicht MINIMUM oder BASIC-WL). Welches Format wann passt, vergleichen wir im Beitrag XRechnung oder ZUGFeRD: Unterschied & welche brauche ich?

Vom Muster zur validen Datei

Ein Muster verstehen ist das eine — eine technisch versand- und buchungsfähige E-Rechnung erzeugen das andere. Zwei verlässliche Wege:

Erzeugen statt abtippen. fakturai erstellt aus Ihren Daten eine ZUGFeRD-/Factur-X- oder XRechnung-Datei und prüft sie vor der Auslieferung gegen ein KoSIT-orientiertes Akzept-Gate. So bekommen Sie kein Muster, sondern eine konkrete, geprüfte Rechnung.
Vorhandene Datei prüfen. Haben Sie bereits eine Beispiel- oder Echtdatei, laden Sie sie in den kostenlosen Validator und sehen ohne Konto, ob sie EN 16931 erfüllt.

E-Rechnung kostenlos prüfen

Typische Fehler an Mustern und Beispieldateien

Ein hübsches PDF für eine E-Rechnung halten — ohne strukturierten XML-Teil ist es keine.
Ein MINIMUM- oder BASIC-WL-ZUGFeRD-Muster verwenden — diese Profile tragen nicht die vollen EN-16931-Daten und erfüllen die Pflicht nicht.
Aus einem unvollständigen Lehrbeispiel eine produktive Rechnung bauen — Pflichtfelder fehlen, die KoSIT-Prüfung schlägt fehl.
USt-Aufschlüsselung (BG-23) und Summen (BG-22) nicht rechnerisch zueinander passend — eine der häufigsten Validierungsfehlerquellen.

Was fakturai nicht ersetzt

fakturai prüft und erzeugt die technische Format- und Strukturkonformität nach EN 16931 mit einem KoSIT-orientierten Akzept-Gate. Die inhaltliche und steuerliche Richtigkeit der Rechnung, die ordnungsgemäße Archivierung und die buchhalterische Behandlung bleiben in Ihrer Verantwortung. fakturai ersetzt keine Steuerberatung und gibt keine Rechts-, Steuer- oder Zustellungsgarantien.

Weiterlesen

German-first SEO page für „E-Rechnung Muster / XRechnung Beispiel" Intent. Illustrativer, vereinfachter XML-Ausschnitt (kein Validitätsversprechen); technische Struktursprache nach EN 16931 (GHOA-1671).

English companion: E-invoice example (XML): what a German e-invoice looks like.