E-Rechnung Beispiel: Wie BT-Nummern, XML-Aufbau und Prüfregeln zusammenhängen
|
Eine E-Rechnung ist ein strukturierter Datensatz: Jede Angabe, von der Rechnungsnummer (BT-1) bis zum Bruttobetrag (BT-112), steht in einem fest definierten Feld der europäischen Norm EN 16931. Diese Felder heißen Business Terms, kurz BT. Wer die BT-Nummern kennt, kann jedes E-Rechnung Beispiel lesen, egal ob es als XRechnung oder als ZUGFeRD-Datei ankommt.
Wie schnell das Thema an Gewicht gewinnt, zeigt eine aktuelle Umfrage. Laut dem Market Momentum Index 2025 von Deep Analysis und AIIM erwarten Unternehmen in der DACH-Region, dass ihr Papieraufkommen innerhalb eines Jahres um die Hälfte sinkt. Die Autoren nennen die E-Rechnungspflicht als einen möglichen Grund.
Dieser Artikel zeigt eine Lieferantenrechnung an einen Industriebetrieb Feld für Feld. Sie sehen, wie die Felder im XML stehen, welche Prüfregeln an ihnen hängen und was mit einer Rechnung passiert, die durchfällt.
Wichtige Erkenntnisse
- Jede Angabe einer E-Rechnung hat eine feste BT-Nummer aus der EN 16931, zum Beispiel BT-1 für die Rechnungsnummer oder BT-13 für die Bestellreferenz
- Zusammengehörige Felder bilden Business Groups (BG), etwa BG-4 für den Verkäufer oder BG-25 für eine Rechnungsposition
- Dieselbe BT-Nummer steht in UBL und CII an unterschiedlichen Stellen im XML, die Bedeutung bleibt gleich
- An den BT-Feldern hängen Geschäftsregeln wie BR-S-02 oder BR-CO-15, und eine Rechnung, die eine Regel verletzt, gilt als ungültig
- Aus einer PDF-Rechnung wird nur dann eine gültige E-Rechnung, wenn alle Pflichtfelder vorhanden sind, und genau daran scheitern Umwandlungen in der Praxis
Was ist eine E-Rechnung?
Eine E-Rechnung ist eine Rechnung in einem strukturierten elektronischen Format, das ein System ohne Texterkennung auslesen kann. In Deutschland folgt sie dem Datenmodell der EN 16931 und liegt als XRechnung (reines XML) oder als ZUGFeRD (PDF mit eingebettetem XML) vor. Jede Angabe steckt in einem nummerierten Feld.
E-Rechnung Beispiel: eine Lieferantenrechnung an einen Fertiger, Feld für Feld
Unser Beispiel ist eine fiktive Rechnung der Muster Hydraulik GmbH an die Beispiel Maschinenbau AG über 200 Hydraulikzylinder. Solche Rechnungen kommen in einem Industriebetrieb hundertfach am Tag an, und jede muss zu Bestellung und Wareneingang passen.
Die Tabelle zeigt die wichtigsten Felder in der Reihenfolge der EN 16931: erst Kopf und Referenzen, dann die Parteien, dann die Summen, zuletzt die Positionen. „Pflicht“ bedeutet, dass das Feld immer vorhanden sein muss. „Bedingt“ bedeutet, dass eine Geschäftsregel es je nach Fall verlangt.
| BT-Nummer | Feld | Beispielwert | Status |
| BT-1 | Rechnungsnummer | RE-2026-04711 | Pflicht |
| BT-2 | Rechnungsdatum | 2026-10-15 | Pflicht |
| BT-3 | Rechnungstyp | 380 | Pflicht |
| BT-5 | Währung | EUR | Pflicht |
| BT-10 | Käuferreferenz | KST-4410 | In XRechnung Pflicht |
| BT-12 | Vertragsreferenz | RV-2025-018 | Optional |
| BT-13 | Bestellreferenz | 4500123456 | Optional |
| BT-15 | Wareneingangsreferenz | WE-889120 | Optional |
| BT-27 | Name des Verkäufers | Muster Hydraulik GmbH | Pflicht |
| BT-31 | USt-ID des Verkäufers | DE123456789 | Bedingt |
| BT-44 | Name des Käufers | Beispiel Maschinenbau AG | Pflicht |
| BT-109 | Gesamtbetrag netto | 24000.00 | Pflicht |
| BT-110 | Umsatzsteuer gesamt | 4560.00 | Bedingt |
| BT-112 | Gesamtbetrag brutto | 28560.00 | Pflicht |
| BT-129 | Menge | 200 | Pflicht |
| BT-130 | Maßeinheit | H87 | Pflicht |
| BT-153 | Artikelname | Hydraulikzylinder HZ-40 |
Pflicht |
Rechnungskopf: Nummer, Datum, Typ, Währung
Der Kopf identifiziert die Rechnung. Auffällig ist BT-3: Dort steht ein Code aus einer festen Liste, hier 380 für eine Handelsrechnung. Eine Gutschrift trägt 381. Datumsangaben stehen im XML im Format Jahr, Monat, Tag, Beträge mit Punkt als Dezimaltrenner.
Referenzen: Bestellung, Vertrag, Wareneingang, Leitweg-ID
Die Referenzen gehören in der EN 16931 noch zum Rechnungskopf. Für Industrieunternehmen sind sie der wichtigste Teil: Über die Bestellreferenz (BT-13) und die Wareneingangsreferenz (BT-15) ordnet Ihr System die Rechnung automatisch der richtigen Bestellung zu. Fehlen sie, beginnt die Suche per Hand.
Die Käuferreferenz (BT-10) dient der Weiterleitung beim Empfänger. Bei Rechnungen an Behörden steht hier die Leitweg-ID, im B2B-Geschäft etwa eine Kostenstelle oder eine interne Einkäufernummer.
Verkäufer und Käufer
Die Angaben zu den Parteien sind in Business Groups gebündelt. BG-4 enthält alles zum Verkäufer, darunter Name (BT-27) und USt-ID (BT-31), BG-5 seine Anschrift. Für den Käufer gelten BG-7 und BG-8. So weiß ein System, dass eine Postleitzahl zur Verkäuferanschrift gehört. Die Lieferadresse hat mit BG-15 eine eigene Gruppe.
Summen und Steuern
Die Gesamtbeträge stehen in BG-22, die Aufschlüsselung der Umsatzsteuer in BG-23. Ihr Rechenweg ist fest vorgegeben: Netto (BT-109) plus Steuer (BT-110) ergibt Brutto (BT-112).
Rechnungspositionen
Die Positionen stehen in der Norm am Ende. Jede ist eine eigene Gruppe (BG-25) mit Menge (BT-129), Maßeinheit (BT-130) und Artikelname (BT-153). Die Maßeinheit ist wieder ein Code: H87 steht für Stück.
Gleiche BT-Nummer, anderes XML: das Beispiel in UBL und CII
Die EN 16931 legt fest, welche Felder es gibt. Wie sie im XML heißen, bestimmt die Syntax. In Deutschland sind zwei zugelassen: UBL und CII. Eine XRechnung kann in beiden vorliegen, eine ZUGFeRD-Rechnung nutzt CII.
So sehen Rechnungsnummer (BT-1) und Bestellreferenz (BT-13) unseres Beispiels in UBL aus:
<cbc:ID>RE-2026-04711</cbc:ID> <!-- BT-1 -->
<cac:OrderReference>
<cbc:ID>4500123456</cbc:ID> <!-- BT-13 -->
</cac:OrderReference>Und so in CII:
<rsm:ExchangedDocument>
<ram:ID>RE-2026-04711</ram:ID> <!-- BT-1 -->
</rsm:ExchangedDocument>
<ram:BuyerOrderReferencedDocument>
<ram:IssuerAssignedID>4500123456</ram:IssuerAssignedID> <!-- BT-13 -->
</ram:BuyerOrderReferencedDocument>Für Ihre Buchhaltung ist das dieselbe Information. Für die Software, die die Rechnung einliest, sind es zwei verschiedene Fundstellen. Wer E-Rechnungen von vielen Lieferanten empfängt, braucht deshalb eine Verarbeitung, die beide Syntaxen auf dieselben BT-Felder abbildet.
BT-Felder automatisch auslesen.
Wir zeigen Ihnen, wie Sie eingehende E-Rechnungen direkt aus der XML-Datei auslesen können.
Welche Prüfregeln an den BT-Feldern hängen
Eine E-Rechnung ist gültig, wenn sie das XML-Schema und die Geschäftsregeln der EN 16931 erfüllt. Diese Regeln prüfen Zusammenhänge zwischen Feldern. Ein Prüfprotokoll nennt bei einem Fehler meist nur das Kürzel der Regel, deshalb hilft es zu wissen, was dahintersteckt.
| Regel | Was sie prüft | Betroffene Felder |
| BR-S-02 | Bei Positionen mit Regelsteuersatz muss eine Steuerkennung des Verkäufers vorhanden sein | BT-151, BT-31, BT-32, BT-63 |
| BR-CO-26 | Der Verkäufer muss eindeutig identifizierbar sein | BT-29, BT-30, BT-31 |
| BR-CO-15 | Brutto muss Netto plus Steuer ergeben | BT-109, BT-110, BT-112 |
| BR-DE-15 | Eine XRechnung muss eine Käuferreferenz enthalten | BT-10 |
| PEPPOL-EN16931-R003 | Über Peppol braucht jede Rechnung eine Käufer- oder Bestellreferenz | BT-10, BT-13 |
Was passiert, wenn eine E-Rechnung die Prüfung nicht besteht?
Bei hohem Rechnungsvolumen ist eine fehlerhafte E-Rechnung Alltag. Entscheidend ist, dass Ihr Team sofort sieht, welche Regel verletzt ist und wer handeln muss.
Die Prüfung läuft in drei Stufen
Zuerst erkennt das System anhand des Schemas, um welches Format es sich handelt. Danach prüft es, ob das XML technisch korrekt aufgebaut ist. Zuletzt laufen die Geschäftsregeln aus der Tabelle oben. Jede Stufe kann eine Rechnung stoppen.
Ablehnen oder klären lassen
Für eine durchgefallene Rechnung gibt es zwei saubere Wege. Bei klaren Fehlern wie einem Rechenfehler oder einer unbekannten Bestellnummer geht die Rechnung mit Begründung an den Lieferanten zurück. Bei unklaren Fällen prüft ein Mensch die Daten und entscheidet.
Mit Doxis wird der Prüfbericht mit allen verletzten Regeln zusammen mit der Rechnung archiviert. Welche Regel eine Rechnung gestoppt hat, bleibt damit auch bei einer späteren Betriebsprüfung nachvollziehbar.
Ausgelesene Daten sind noch keine gültige Rechnung
Manche Systeme lesen eine fehlerhafte E-Rechnung einfach per Texterkennung aus der PDF-Ansicht aus. Damit haben Sie Daten im System, die Rechnung bleibt aber formal fehlerhaft. Lassen Sie einen Prüffehler deshalb immer klären, bevor Sie die Rechnung buchen.
Warum aus einer PDF-Rechnung nicht automatisch eine E-Rechnung wird
Viele Lieferanten schicken weiterhin PDF-Rechnungen, und auch beim eigenen Rechnungsausgang liegt die Idee nahe, vorhandene PDFs umzuwandeln. Technisch geht das: Software liest die PDF aus und schreibt die Werte in eine XRechnung.
Schwierig wird es bei den Pflichtfeldern. Eine PDF enthält, was der Mensch beim Lesen braucht. Die EN 16931 verlangt zusätzlich Angaben wie eine Steuerkategorie pro Position oder eine Käuferreferenz. Fehlt eine dieser Angaben im Original, entsteht eine E-Rechnung, die an den Regeln aus der Tabelle oben scheitert.
Planen Sie bei jeder Umwandlung deshalb eine menschliche Prüfung ein, bevor die Rechnung rausgeht. Dauerhaft lösen Sie das Problem an der Quelle: Wenn Ihr ERP die Pflichtfelder aus Stammdaten und Bestellung befüllt, entsteht die E-Rechnung von Anfang an vollständig.
Wo Sie offizielle Beispieldateien finden
Für Tests mit echten Dateien gibt es zwei verlässliche Quellen. Die Koordinierungsstelle für IT-Standards (KoSIT) veröffentlicht die XRechnung-Testsuite mit Beispielrechnungen in UBL und CII für zahlreiche Geschäftsfälle. Beispiele für ZUGFeRD stellt das Forum elektronische Rechnung Deutschland bereit.
Nutzen Sie diese Dateien, um Ihre eigene Verarbeitung zu testen: Liest Ihr System beide Syntaxen? Erkennt es eine fehlerhafte Rechnung und meldet die richtige Regel?
E-Rechnungen mit Doxis auslesen, prüfen und ins ERP übergeben
Für Ihr Team zählt am Ende eins: dass jede Eingangsrechnung, egal ob XRechnung, ZUGFeRD oder PDF, als vollständiger und geprüfter Datensatz in Ihrem ERP ankommt. Mit Doxis erkennt das System das Format, prüft Schema und Geschäftsregeln und übergibt die Daten an Ihr ERP. Fehlerhafte Rechnungen gehen mit Begründung zurück oder an Ihr Team zur Klärung.
Wie viel das ausmacht, zeigt der Industriezulieferer Stabilus: Bei über 65.000 Rechnungen im Jahr sank die Durchlaufzeit der Rechnungsprüfung mit Doxis um durchschnittlich 70 %.
Die E-Rechnung ist dabei ein Teil Ihrer Finanzprozesse. Auf der Doxis-Plattform laufen Rechnungseingang und Freigabe-Workflows mit der Archivierung zusammen. Rechnung und Prüfbericht liegen so in einer gemeinsamen Akte.
- Gängige Eingangsformate wie XRechnung in UBL und CII, ZUGFeRD und Factur-X
- Prüfung jeder eingehenden E-Rechnung gegen Schema und Geschäftsregeln der EN 16931
- Klare Wege für fehlerhafte Rechnungen: Ablehnung mit Begründung oder Klärung durch Ihr Team
- PDF-Rechnungen werden ausgelesen und in strukturierte Daten umgewandelt
- Empfang über Peppol, Doxis ist Peppol Service Provider
- Archivierung von Rechnung, eingebettetem XML und Prüfbericht
In einer Forrester-TEI-Studie erzielte ein Modellunternehmen mit Doxis einen ROI von 336 %. Fordern Sie jetzt eine kostenlose Demo an.
XRechnung, ZUGFeRD und PDF in einem Prozess.
Erfahren Sie, wie Doxis jedes Format ausliest und geprüfte Rechnungsdaten direkt an Ihr ERP übergibt.
FAQs zu E-Rechnungsbeispielen
Was bedeutet BT bei der E-Rechnung?
BT steht für Business Term. Jede BT-Nummer bezeichnet ein festes Feld im Datenmodell der EN 16931, zum Beispiel BT-1 für die Rechnungsnummer.
Welche BT-Felder sind in einer E-Rechnung Pflicht?
Immer vorhanden sein müssen unter anderem Rechnungsnummer (BT-1), Rechnungsdatum (BT-2), Rechnungstyp (BT-3), Währung (BT-5), Verkäufer (BT-27), Käufer (BT-44) und die Gesamtbeträge. Eine XRechnung verlangt zusätzlich die Käuferreferenz (BT-10).
Was ist der Unterschied zwischen BT und BG?
Ein BT ist ein einzelnes Feld, eine BG (Business Group) bündelt zusammengehörige Felder. BG-4 fasst zum Beispiel alle Angaben zum Verkäufer zusammen.
Wo steht die Leitweg-ID in der E-Rechnung?
Die Leitweg-ID steht im Feld Käuferreferenz (BT-10). Sie wird nur bei Rechnungen an öffentliche Auftraggeber benötigt.
Was bedeutet der Rechnungstyp 380?
380 ist der Code für eine Handelsrechnung im Feld BT-3. Eine Gutschrift hat den Code 381.
Ist eine PDF-Rechnung eine E-Rechnung?
Eine reine PDF-Rechnung gilt nicht als E-Rechnung, weil ihr der strukturierte Datensatz fehlt. Eine ZUGFeRD-Datei sieht aus wie eine PDF und enthält zusätzlich das XML.
Ist ZUGFeRD 1.0 noch eine gültige E-Rechnung?
ZUGFeRD 1.0 erfüllt die EN 16931 nicht und gilt daher nicht als E-Rechnung. Gültig sind ZUGFeRD-Versionen ab 2.0 mit einem EN-16931-konformen Profil.
Wie können wir helfen?
+49 (0) 228 90896-0Ihre Nachricht hat uns erreicht!
Wir freuen uns über Ihr Interesse und melden uns in Kürze bei Ihnen.