EN 16931 einfach erklärt: die Norm hinter der E-Rechnung

Wer sich mit E-Rechnungen beschäftigt, stößt früher oder später auf eine Norm-Nummer: EN 16931. Sie taucht in Software-Beschreibungen, Validator-Meldungen und Behörden-Texten auf, bleibt aber oft unerklärt. Dabei ist sie der eigentliche Kern der E-Rechnungs-Pflicht: EN 16931 legt fest, welche Informationen eine elektronische Rechnung enthalten muss und was diese Informationen bedeuten. Sie ist das semantische Datenmodell hinter jeder gültigen E-Rechnung – unabhängig davon, ob dahinter XRechnung oder ZUGFeRD steckt.

Was die Norm eigentlich regelt

EN 16931 beschreibt keine Datei und kein Aussehen, sondern eine „Kernrechnung": eine Liste von Informationselementen, die eine Rechnung inhaltlich vollständig machen. Dazu gehören zum Beispiel Rechnungsnummer, Datum, Verkäufer- und Käuferdaten, Steuersätze, Positionen und Summen. Die Norm definiert für jedes dieser Elemente, wie es heißt, ob es verpflichtend ist und in welcher Beziehung es zu anderen Elementen steht. Wie diese Elemente technisch in einer Datei landen – als XML nach welchem Schema – ist eine zweite, getrennte Frage.

Business Terms und Business Groups

Damit das Modell eindeutig referenzierbar ist, vergibt die Norm Kürzel. Einzelne Felder heißen Business Terms und werden mit „BT-" plus Nummer bezeichnet, zusammengehörige Feldgruppen heißen Business Groups und tragen ein „BG-" Kürzel. Diese Bezeichner tauchen später auch in Prüfmeldungen auf, weshalb es hilfreich ist, ein paar Beispiele zu kennen:

Kürzel	Bedeutung
BT-1	Rechnungsnummer
BT-2	Rechnungsdatum
BT-5	Rechnungswährung
BG-25	Rechnungsposition (Gruppe aus mehreren Feldern zu einer Position)
BG-22	Dokumentsummen (Netto, Steuer, Brutto)

Zwei Syntaxen, ein Modell

Das semantische Modell von EN 16931 wird in zwei technischen Syntaxen umgesetzt: UBL und CII (Cross Industry Invoice). Beide bilden dieselben Business Terms ab, nur mit unterschiedlicher XML-Struktur. XRechnung kann wahlweise als UBL oder als CII vorliegen, ZUGFeRD nutzt ausschließlich CII (eingebettet in eine PDF). Wer verstehen will, welche Variante für den eigenen Anwendungsfall passt, findet Hintergrund im Beitrag XRechnung oder ZUGFeRD.

CIUS: die Norm mit nationaler Schärfung

EN 16931 ist bewusst offen gehalten, damit sie in unterschiedlichen Ländern und auf unterschiedlichen Plattformen funktioniert. Damit sie in der Praxis eindeutig anwendbar wird, gibt es sogenannte Core Invoice Usage Specifications, kurz CIUS. Eine CIUS darf die Norm nur einschränken oder präzisieren – etwa ein optionales Feld verpflichtend machen –, ihr aber nie widersprechen. XRechnung ist die deutsche CIUS, Peppol BIS Billing die entsprechende europäische Ausprägung für den Peppol-Verbund. Beide bauen auf demselben EN-16931-Modell auf, unterscheiden sich aber in Details wie Pflichtfeldern oder Referenznummern.

Wie die Einhaltung geprüft wird

Ob eine konkrete Rechnungsdatei die Norm einhält, wird technisch mit Schematron-Regeln geprüft – das sind maschinell auswertbare Geschäftsregeln, die auf den XML-Inhalt angewendet werden. Die Regeln der EN 16931 selbst heißen BR-… (Business Rules), zum Beispiel BR-16: eine Rechnung muss mindestens eine Position enthalten. Rechenregeln, die Summen und Beträge auf Konsistenz prüfen, tragen das Kürzel BR-CO-…. Darüber hinaus gibt es länderspezifische Zusatzregeln; die deutschen heißen BR-DE-… und kommen aus der XRechnung-CIUS.

Was das für die eigene Prüfung bedeutet

Für den Alltag reicht es nicht, zu wissen, dass es diese Norm gibt – entscheidend ist, ob eine konkrete Datei ihr auch entspricht. Genau das prüft der E-Rechnungsprüfer: er wendet dieselbe Regel-Engine an wie der offizielle KoSIT-Validator, also Schema-Prüfung, EN-16931-Schematron und die XRechnung-CIUS-Regeln, und übersetzt jeden Verstoß in eine deutsche Erklärung mit Bezug auf das betroffene BT- oder BR-Kürzel. Die Prüfung läuft dabei clientseitig im Browser, die Datei verlässt also das eigene Gerät nicht.

Wer verstehen will, welche Fehler in der Praxis am häufigsten auftreten und wie sie sich beheben lassen, findet konkrete Beispiele im Beitrag zu den häufigen Prüffehlern. Wichtig bleibt in jedem Fall: Eine bestandene formale Prüfung nach EN 16931 und KoSIT-Schema sagt etwas über die technische und strukturelle Korrektheit der Rechnung aus – sie ersetzt keine steuerliche oder rechtliche Beratung im Einzelfall.