EN 16931, XRechnung, Factur-X, ZUGFeRD: die E-Rechnungsformate

Die E-Rechnung in Europa wirkt wie ein Zoo aus Abkürzungen, aber die Struktur darunter ist einfach: ein semantischer Standard, zwei XML-Syntaxen, nationale Profile obendrauf und ein hybrider Kniff, der das XML in ein PDF packt. Wer die Schichten einmal gesehen hat, kann jeden Formatnamen einordnen.

Das Fundament: EN 16931

EN 16931 ist der europäische Standard für den Inhalt einer elektronischen Rechnung. Er definiert die Datenfelder einer Rechnung (Verkäufer, Käufer, Positionen, Steueraufschlüsselung, Summen), nummeriert sie von BT-1 bis BT-165 und legt die Regeln fest, die sie zusammenhalten: welche Felder Pflicht sind und wie die Summen aufgehen müssen (die BR-*-Geschäftsregeln). Die E-Rechnungsregeln der meisten EU-Länder bauen darauf auf.

EN 16931 legt bewusst kein Dateiformat fest. Dafür benennt er zwei XML-Syntaxen:

• UBL 2.1, ein OASIS-Standard, Elementnamen wie <cbc:ID> und <cac:AccountingSupplierParty>.
• UN/CEFACT CII (Cross-Industry Invoice), Elementnamen wie <ram:SellerTradeParty>.

Derselbe Rechnungsinhalt lässt sich in beiden Syntaxen schreiben. Alles Weitere ist eine Schicht über diesen beiden.

Das deutsche Profil: XRechnung

XRechnung ist das deutsche Profil (eine CIUS, “Core Invoice Usage Specification”) von EN 16931, gepflegt von der KoSIT, aktuell in Version 3.0.2. Es akzeptiert beide Syntaxen und verschärft die Regeln: Die Käuferreferenz (BT-10) wird Pflicht, und bei Behördenrechnungen steht dort die Leitweg-ID, die die Rechnung zur richtigen Stelle leitet.

Für Rechnungen an deutsche öffentliche Auftraggeber ist XRechnung seit 2020 Pflicht. Im B2B-Bereich führt Deutschland die E-Rechnung seit Januar 2025 stufenweise ein (jedes Unternehmen muss empfangen können); das Ausstellen wird 2027 für Unternehmen über 800.000 Euro Umsatz Pflicht, 2028 für alle.

Das Hybridformat: Factur-X und ZUGFeRD

Factur-X (französischer Name) und ZUGFeRD (deutscher Name) sind derselbe deutsch-französische Standard, gemeinsam veröffentlicht von FeRD und FNFE-MPE. Die Idee: ein normal aussehendes PDF (PDF/A-3), in das das maschinenlesbare CII-XML eingebettet ist. Ein Mensch öffnet das PDF und sieht eine Rechnung; Software extrahiert das XML und liest strukturierte Daten. Aktuelle Ausgabe: Factur-X 1.09.

Factur-X gibt es in Profilen mit wachsender Vollständigkeit (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). Das Profil EN 16931 enthält eine vollständige, standardkonforme Rechnung; die kleineren Profile enthalten weniger als den vollen Datensatz, was zählt, wenn die Gegenseite das XML allein verarbeiten muss.

Die französische Pflicht

Frankreich schaltet am 1. September 2026 um: Jedes umsatzsteuerpflichtige Unternehmen muss elektronische Rechnungen empfangen können, große und mittlere Unternehmen müssen sie ausstellen (kleine folgen am 1. September 2027). Die Rechnungen laufen über staatlich zugelassene Plattformen, und Factur-X ist neben UBL und CII eines der Kernformate der Reform.

Welches Format begegnet Ihnen also?

Was “gültig” heißt, Schicht für Schicht

Eine Datei kann wohlgeformtes XML und trotzdem eine ungültige Rechnung sein. Echte Validierung prüft jede Schicht: die Syntax (Schema), die EN-16931-Geschäftsregeln (Pflichtfelder, Summenkohärenz) und die Zusatzregeln des Profils (Käuferreferenz der XRechnung, Codelisten). Genau das führt die einvoicekit-API aus, ein HTTP-Aufruf pro Datei, egal welches dieser Formate Sie senden: Ein Factur-X-PDF wird automatisch entpackt, XRechnung wird in beiden Syntaxen geprüft. Für den Schnelltest gibt es den kostenlosen Validator, der dasselbe vollständige offizielle Regelwerk ausführt.

Wer XRechnung aus Code erzeugt, findet den kompletten Ablauf in XRechnung in Python validieren.