Validierung von E-Rechnungen nach EN 16931 prüfen

Zum 1. Januar 2025 endete die Papier- und PDF-Zeitrechnung. Wer eine elektronische Rechnung nach § 14 UStG ausstellen muss, muss das nunmehr in einem strukturierten elektronischen Format tun. Goodbye PDF. Hello XML.

Insofern ergeben sich auch für den Vorsteuerabzug aus einer E-Rechnung einige Neuerungen. Es reicht nunmehr nicht mehr aus, dass die Pflichtangaben irgendwo, irgendwie auf der Rechnung stehen. Das Ganze muss nun einer Struktur folgen und diese Struktur ergibt sich aus EN 16931. Keine valide E-Rechnung heißt somit keinen Vorsteuerabzug.

„Bestand eine Verpflichtung zur Ausstellung einer E-Rechnung und wird stattdessen eine sonstige Rechnung im Sinne von § 14 Absatz 1 Satz 4 UStG ausgestellt, handelt es sich nicht um eine ordnungsmäßige Rechnung im Sinne von §§ 14, 14a UStG. Folglich berechtigt die ausgestellte Rechnung dem Grunde nach nicht zum Vorsteuerabzug nach § 15 Absatz 1 Satz 1 Nummer 1 UStG.“

(Quelle: Bundesministerium der Finanzen, Schreiben vom 15.Oktober 2024 – III C 2 - S 7287-a/23/10001 :007, Rn. 56.).

🧾 Was macht eine Rechnung zu einer E-Rechnung ?

Die Antwort lautet: EN 16931. Die Basis für jegliche Digitalisierungsvorhaben bildet immer ein Standard. Im Falle der E-Rechnung ist dies die europäische elektronische Rechnungsnorm EN 16931.

Diese Norm besteht insbesondere aus einem semantischen Datenmodell und konformen Syntaxen, konkret legt EN 16931 fest:

welche Informationen in einer E-Rechnung stehen müssen,
in welcher Form Informationen codiert sein müssen,
und in welcher technischen Struktur – UBL 2.1 oder UN/CEFACT CII – die E-Rechnung aufgebaut sein muss.

Und genau deshalb beginnt jeder funktionierende Rechnungseingangsprozess heute mit einem einzigen Wort: Validierung.

🔍 Alle versprechen Validierung. Kaum einer zeigt, was das heißt.

Der Markt ist voll mit Tools, die angeblich „voll EN 16931-konform“ arbeiten. Aber was heißt das konkret? Welche Validierungsschritte laufen wirklich im Hintergrund? Was genau prüft die Software – und was nicht?

Das Beste an der Validierung nach EN 16931: Alles, was du brauchst, ist öffentlich als Open Source. Selbst eine kleine Bonner Tax Tech Boutique könnte vollautomatisiert E-Rechnungen validieren. Crazy – aber wahr.

Und so läuft die Validierung ab:

Stufe 1: Schema-Validierung
Zuerst prüft die Schema-Validierung, ob die Rechnung in einer zulässigen Syntax vorliegt – also UBL 2.1 oder UN/CEFACT CII. Dabei geht es um die technische Struktur: Stimmen die XML-Tags? Ist die Datei formal sauber? Fehlt etwas in der Hierarchie? Wer hier schon patzt, kommt gar nicht erst zur nächsten Stufe.
Stufe 2: Business Rules EN 16931
Wenn die Syntax stimmt, prüft die Schemata-Validierung, ob die allgemeinen Business Rules nach EN 16931 eingehalten sind. Hier geht’s um Inhalte: Sind Adressfelder für Käufer und Verkäufer befüllt? Stimmt der Steuerbetrag rechnerisch mit dem angegebenen Steuersatz überein?
Stufe 3: CIUS-Prüfung
Je nach nationaler oder branchenspezifischer Ausprägung folgt eine dritte Ebene: Die CIUS-Regeln. Ob XRechnung, Peppol BIS Billing oder Factur-X – jedes Profil bringt zusätzliche Business Rules mit. Und jede davon kann zum Ablehnungsgrund werden.

👉 Und jetzt zum eigentlichen Problem:

Im Softwareauswahlprozess klingt alles gut. Die Marketingslides sehen professionell aus und der Softwareanbieter zeigt sich von seiner besten Seite. Aber sobald die Softwarelösung implementiert werden soll, zeigt sich: Vieles davon war Marketing.

In unseren Projekten haben wir das systematisch geprüft – mit gezielt manipulierten E-Rechnungen aus unserem greenvoice. Package-Testset. Immer wieder zeigte sich: Viele Softwarelösungen setzen die offiziellen Validierungsregeln nicht vollständig um.

Warum? Weil viele Softwareanbieter wie Softwareanbieter denken: Eine Business Rule, die die Verarbeitung stört? Raus damit.

Leidtragender? Der bist Du! Als Unternehmer, der auf eine gültige E-Rechnung vertraut – und beim Vorsteuerabzug in die Röhre schaut.

🥇 Validierung ist gut. Aber Tax CMS ist besser.

Validierung ist die erste Verteidigungslinie zur Sicherstellung des Vorsteuerabzugs. Sie prüft, ob alle notwendigen Felder befüllt sind – Adressfelder, USt-IdNr., Steuersätze, Steuerbeträge etc.. Sie erkennt auch bestimmte Berechnungsfehler: Wenn der Steuerbetrag nicht zum Steuersatz passt, fällt das auf.

1. Was die Validierung aber nicht erkennt!

Ob die Inhalte in der E-Rechnung auch wirklich richtig sind, also ob etwa die Adressdaten auf der Rechnung auch wirklich mit euren Stammdaten übereinstimmen, ist nicht Teil vom Validierungsprozess nach EN 16931. Besonders tückisch ist es zudem, wenn die Validierung bestimmte stammdatenrelevante Informationen scheinbar prüft, wie die folgenden Beispiele verdeutlichen.

Inhalt in BT-31 „Umsatzsteuer-Identifikations-nummer des Verkäufers“	Validierungs-ergebnis nach EN 16931	Fehlermeldung / Anmerkung
DE123456789	valid	Keine Fehlermeldung
123456789	invalid	val-sch.1.1 BR-CO-09 error [BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.
DE123	valid	Keine Fehlermeldung, obwohl die USt-IdNr. offensichtlich zu kurz ist.

Die Validierung prüft also nur, ob das Feld formal befüllt ist, aber nicht, ob der Inhalt steuerlich korrekt ist. Eine syntaktisch gültige, aber faktisch nutzlose USt-IdNr. führt zu keinem Fehler. Dasselbe gilt für Steuersätze: Auch ein „Regelsteuersatz“ von 25 % wird nicht beanstandet – wenn der Rechenweg aufgeht.

2. Technisch valide heißt nicht steuerlich verwertbar - und hier kommt das Tax CMS ins Spiel.

Denn was die Validierung nach EN 16931 nicht abdeckt, muss dein Tax CMS, dein steuerliches Kontrollsystem, entsprechend entdecken.

Das betrifft insbesondere:

Stammdatenabgleich: Ist die angegebene USt-IdNr. überhaupt gültig? Passt sie zum Leistenden?
Logikprüfung: Stimmen die verwendeten Steuersätze mit dem tatsächlichen Leistungsort und der Leistungsart überein
Adressprüfung: Fehlt ein Pflichtfeld oder ist eine Kombination offensichtlich falsch?

Herkömmliche E-Rechnungssoftwarelösungen beschränken sich meist auf die reine Validierung und bieten keine weitergehenden umsatzsteuerlichen Prüfschritte. Hier muss ein ausgeklügeltes Tax CMS den entscheidenden Unterschied machen.

Abschließend: Mit der E-Rechnung kommen strukturierte umsatzsteuerliche Daten an. Das ist grundsätzlich positiv – wenn diese Daten zunächst die Validierung nach den Vorgaben bestehen. Danach sollte der Steuerpflichtige diesen Datenschatz aber auch wirklich nutzen: automatisiert vorgehen, datengestützte Überprüfungen durchführen.

Hierfür ist es unerlässlich, dass Unternehmen wissen, wie die Datenstruktur einer E-Rechnung nach EN 16931 aufgebaut ist – also wo welche Information an welcher Stelle in welcher Form steht. Nur dann lassen sich Automatisierungspotenziale überhaupt identifizieren und nutzen.

Unerlässlich ist hierbei erneut: Testen mit Testrechnungen. Nur so lässt sich praktisch nachvollziehen, welche Datenqualität und Datengranularität künftig die umsatzsteuerlichen Prozesse prägen wird.

______________________