EN 16931 für Nicht-Entwickler erklärt

EN 16931 ist der europäische Standard für den Kern einer elektronischen Rechnung. Er legt fest, welche fachlichen Informationen eine E-Rechnung enthalten soll und wie diese Informationen zusammenhängen: Käufer, Verkäufer, Positionen, Steuerangaben, Summen und Zahlungsinformationen.

Wichtig: EN 16931 ist nicht einfach „eine XML-Datei“. Der Standard beschreibt vor allem das semantische Modell. Die konkrete technische Darstellung erfolgt über Syntaxen wie UBL oder CII und über Profile wie XRechnung oder ZUGFeRD/Factur-X EN16931.

Der Standard entstand aus der EU-Richtlinie zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen. Ziel war Interoperabilität: Eine E-Rechnung soll zwischen unterschiedlichen Systemen, Ländern und öffentlichen Auftraggebern verarbeitet werden können.

Die Europäische Kommission beschreibt E-Invoicing als Austausch von Rechnungen in einem strukturierten, maschinenlesbaren elektronischen Format, das automatische und elektronische Verarbeitung ermöglicht. EN 16931 definiert dafür die Kernelemente.

Semantik bedeutet hier: Was bedeutet ein Rechnungsfeld fachlich? Ein Rechnungsdatum, ein Steuersatz oder ein Zahlungsbetrag soll in verschiedenen Systemen gleich verstanden werden. Genau das ist die Stärke von EN 16931.

Ein PDF kann dieselben Informationen sichtbar enthalten, aber nicht zuverlässig als strukturierte Daten. EN 16931 beschreibt, welche Informationen als verarbeitbare Daten vorhanden sein müssen, damit Software sie automatisch prüfen und weiterverarbeiten kann.

EN 16931 ist der europäische Kern. XRechnung ist die deutsche CIUS, also eine nationale Konkretisierung dieses Kerns. ZUGFeRD/Factur-X kann ebenfalls ein EN16931-Profil verwenden, ist aber als Hybridformat aus PDF/A-3 und XML anders verpackt.

Weil Rechnungsinformationen strukturiert sind, lassen sich fachliche Regeln automatisch prüfen. Dazu gehören Pflichtfelder, Code-Listen, Summen, Steuerlogik, Zahlungsdaten und Beziehungen zwischen Positionen und Gesamtsummen.

Beispiele sind: Die Summe der Positionsbeträge muss zur angegebenen Gesamtsumme passen. Eine Steuerbefreiung braucht eine passende Begründung. Ein Betrag muss in der richtigen Währung und mit zulässiger Genauigkeit angegeben sein.

Eine XML-Datei kann technisch zum UBL- oder CII-Schema passen und trotzdem gegen EN-16931-Regeln verstoßen. Das Schema prüft vor allem Struktur und Datentypen. Die fachlichen Zusammenhänge werden häufig über Schematron- beziehungsweise Business-Rule-Prüfungen kontrolliert.

Genau deshalb kann eine Datei „gültige XML“ sein und trotzdem als E-Rechnung scheitern. Für Unternehmen ist die Fehlerebene wichtig: Syntaxproblem, Schemafehler, Business Rule oder Profilanforderung.

Kleine und mittlere Unternehmen müssen den Standard nicht wie Entwickler lesen. Sie sollten aber verstehen, warum die Rechnung maschinenlesbare Daten braucht und warum ein sichtbares PDF nicht automatisch genügt.

Praktisch bedeutet EN 16931: Rechnungen sollten aus Software heraus strukturiert erzeugt, validiert und bei Fehlern verständlich erklärt werden. Wer nur visuelle Rechnungen prüft, übersieht die eigentliche Verarbeitungsschicht.

Typische Fehler betreffen fehlende Pflichtangaben, nicht passende Summen, unklare Steuerkategorien oder falsche Codes. Für die Buchhaltung ist der technische Regelcode allein oft zu wenig. Hilfreich ist eine Erklärung, welches Geschäftsfeld betroffen ist und was wahrscheinlich geändert werden muss.

Ein guter Validierungsbericht übersetzt deshalb Standardregeln in handlungsnahe Hinweise: Stammdaten ergänzen, Rundungslogik prüfen, Steuerkategorie korrigieren oder Exportprofil anpassen.