Die Umsetzung der XRechnung ist kein einmaliges Projekt

Schaut man sich die Berichte der letzten Monate an, so sieht es oft so aus, als ob Ende dieses Jahres die elektronische Rechnung endgültig Einzug gehalten hat. Doch nicht zuletzt aufgrund des föderalen Systems in Deutschland ist dem nicht so. In diesem Artikel wird der aktuelle Stand der Umsetzung der elektronischen Rechnung an öffentliche Auftraggeber näher beleuchtet.

Einheitliche Standards für eine einheitliche Umsetzung

Im Allgemeinen sind Standards eine feine Sache. Sie erlauben es komplexe Anforderungen über Organisationsgrenzen hinweg einheitlich umzusetzen. Das führt in der Regel zu Kosteneinsparungen und Effizienzgewinn. Aus Sicht der öffentlichen Auftraggeber ist daher die Definition eines einheitlichen Standards für elektronische Rechnungen ebenfalls eine feine Sache. Insbesondere dann, wenn diese über europäisches und nationales Recht dazu verpflichtet sind, elektronische Rechnungen anzunehmen.

Behörden und andere öffentliche Auftraggeber sind teilweise in sehr komplexen Strukturen aufgestellt. Ein Ansatz, der Rechnungsstellern die Zustellung elektronischer Rechnungen vereinfachen soll, sind die so genannten zentralen Rechnungseingangsportale, ZRE. Diese werden zum Beispiel vom Bund, aber auch individuell von einigen Bundesländern betrieben.

Wenn es nun also Änderungen am zugrundeliegenden Standard XRechnung gibt, macht es Sinn, die ZREs einheitlich zu einem Stichtag zu aktualisieren. Jedoch setzt der Standard XRechnung die entsprechenden Anforderungen an die Rechnungssteller anders um, als es bei Datenaustauschstandards für die Wirtschaft üblich ist.

Aktualisierungszwang alle 6 Monate

Der aktuelle XRechnungs-Standard bringt auch die verpflichtende Umstellung bei den Rechnungsstellern mit sich. Es wird ein verbindlicher Gültigkeitszeitraum einer jeweiligen Version von XRechnung vereinbart. Derzeit beträgt der Gültigkeitszeitraum jeweils 6 Monate. Der Vorlauf für eine neue Version beträgt ebenfalls 6 Monate, so dass Rechnungssteller und Softwareunternehmen nur diesen Zeitraum für eine Umstellung haben.

So ist zum Beispiel derzeit XRechnung in der Version 1.2.2 gültig. Sie wurde am 19.12.2019 veröffentlicht. Sie wurde zum 01.07.2020 gültig und wird zum 31.12.2020 ungültig. Dies bedeutet, dass exakt ab Null Uhr an Neujahr eine Versionsumstellung stattfinden muss. Dies ist für viele Rechnungssteller und Softwarehersteller etwas Neues. Zumal in der Regel genau um den Zeitraum herum auch Jahresrechnungen erstellt werden. Erfolgt also ein automatisierter Rechnungslauf am 31.12.2020, so muss exakt um Mitternacht das Ausgabeformat gewechselt werden, falls der Lauf entsprechend umfangreich ist.

Soweit zumindest die Theorie. Fraglich ist, wie die einzelnen Rechnungseingangsstellen mit dieser Frist umgehen? Gilt das Datum der Rechnungsstellung 31.12. noch Version 1.2.2 und 01.01. dann Version 2.0.0 – oder gilt der Moment des Zugangs? Sollte das System des Rechnungsempfängers hier wenig kulant umgesetzt sein, hätte das definitiv Auswirkungen auf die entsprechenden Prozesse bei Rechnungsstellern: Geht im Rechnungslauf irgendetwas schief, würden die verspätet eingehenden Rechnungen abgelehnt werden. Diese wären jedoch bereits im Ausgangsarchiv des Senders abgelegt. Prozessmäßig also eine echte Herausforderung.

Aber gehen wir einmal davon aus, dass nur das Datum selbst relevant ist und nicht der Zeitpunkt des Zugangs. Selbst dann führt diese Regel dazu, dass alle Rechnungssteller von öffentlichen Auftraggebern, die XRechnungen versenden, fortan zweimal pro Jahr ihre Systeme aktualisieren müssen. Gut für die Dienstleister. Aber fraglich ist, ob da noch von Effizienzgewinn gesprochen werden kann?

Warum gibt es denn überhaupt die Änderungen?

Nun könnte man meinen, dass dies nur ein vorübergehendes Phänomen ist. Jedoch sind bereits jetzt mehr als 50 Ergänzungen an der Norm EN16931 selbst auf europäischer Ebene (CEN) in Bearbeitung. Und weitere Anforderungen sind bereits formuliert. Die Ergebnisse dieser Bearbeitung auf europäischer Ebene werden voraussichtlich 2022 veröffentlicht.

Zusätzlich führen konkrete Anforderungen einzelner Branchen – wie z.B. der Baubranche zu Änderungen an der XRechnung. Beachtet man dann noch, dass in vielen Bundesländern und Kommunen der Rechtsrahmen für die elektronische Rechnung noch nicht abschließend geklärt ist, ist mit fortlaufenden Aktualisierungen der XRechnung für mindestens drei bis fünf weitere Jahre zu rechnen.

Die Wirtschaft macht es seit Jahren vor: Den Sender entlasten und beide gewinnen

Dies bedeutet mindestens sechs bis zehn weitere Aktualisierungen der XRechnung. Die Anzahl der Rechnungssender wächst – und somit auch der Umstellungsaufwand. Eine wahre Kostenexplosion zu Lasten der Wirtschaft könnte entstehen.

Dabei ist die Lösung eigentlich schon vorhanden, denn elektronischer Datenaustausch ist nichts Neues. So werden zum Beispiel die beiden Rechnungssyntaxen UBL und CrossIndustryInvoice seit vielen Jahren regelmäßig aktualisiert. Der entscheidende Unterschied ist jedoch der Ansatz und die Implementierung in der Praxis:

Es wird nur dann ein neuer Standard umgesetzt, wenn die neuen Möglichkeiten auch tatsächlich benötigt werden.

Ob man die Datenaustauschstandards der Konsumgüterbranche, Finanzbranche, Automobilbranche oder aus dem Transportwesen anschaut. Es gibt immer die Situation, dass einzelne Geschäftspartner oder deren Vertreter neue Prozessanforderungen haben – oder dass es neue regulatorische Anforderungen gibt, die von bestimmten Geschäftspartnern zu erfüllen sind.

Ziel der Standardisierung ist es dann, für die aufgetretene Anforderung eine einheitliche Lösung zu finden. Somit gibt es einen klaren Lösungsweg, falls künftig eine weitere Organisation dieselbe Anforderung hat. Diese konkrete Lösung implementieren dann aber nur diejenigen Geschäftspartner, die auch tatsächlich die Anforderungen umsetzen müssen.

Dieser Ansatz hat natürlich auch einen Nachteil. Hat einer der Geschäftspartner mit unterschiedlichen Anforderungen zu tun, kann es dazu führen, dass er mehrere Profile desselben Standards umsetzen muss. Vielleicht ist es genau dieser Punkt, den der XRechnungs-Standard vermeiden will?

Ein – aus Sicht des Gesamtsystems – effizienterer Ansatz bestünde nämlich darin, zwar ein “gültig ab” Datum für neue XRechnungsversionen zu definieren, jedoch die alten Versionen nicht automatisch ungültig werden zu lassen. Die Änderungen zwischen den Versionen 1.x waren (prozess-) technisch gesehen gering und hatten nur in wenigen Situationen Auswirkungen auf viele Rechnungssteller. Auch die Einführung der Version 2.0.0 mit der Erweiterungsmöglichkeit für Unterpositionen betrifft längst nicht alle Rechnungssteller.

Alle Rechnungssteller müssen regelmäßig ihre Systeme aktualisieren

Die Einführung des Gültigkeitszeitraums führt jedoch dazu, dass alle Ersteller ihre Systeme aktualisieren müssen – auch wenn sie von der Änderung nicht betroffen sind. So wurden zum Beispiel in der Version 1.2.2 drei neue Rechnungsvarianten (gleich drei neue Codes in einer Codeliste) für die Baubranche aufgenommen. Wer jetzt jedoch nicht zur Baubranche gehört und diese Rechnungsvarianten nicht benötigt, muss als Rechnungssteller dennoch sein System aktualisieren, damit er diese Codes benutzen könnte. Dies scheint mir nicht sinnvoll zu sein.

Abwärtskompatible XRechnungen zulassen

Sinnvoller wäre es dann doch auch die Bereitstellung älterer XRechnungsversionen durch den Rechnungssteller zuzulassen, solange diese abwärtskompatibel sind. Dies würde die Rechnungssteller massiv entlasten und die Systeme müssten nur aktualisiert werden, wenn es tatsächlich neue relevante Änderungen gibt.

Gleichzeitig könnte das Betriebskonzept der zentralen Rechnungseingangsportale so angepasst werden, dass trotzdem der Aufwand auch auf Empfängerseite vertretbar bleibt. Solange die XRechnung abwärtskompatibel bleibt, lässt sich jede ältere Version mit minimalem Aufwand – häufig ist dieser sogar gar nicht vorhanden – mit einer neueren Version verarbeiten. Die empfangenden Systeme könnten im einfachsten Fall die älteren Versionen ohne Anpassung verarbeiten, da sich lediglich die Versionskennung geändert hat. Alternativ könnte – bei kompatiblen Versionen – das empfangende System eigenständig die Versionsangabe aktualisieren (mappen), bevor es die Datei an das nachfolgende System weiterreicht. Dadurch werden die Daten weder strukturell noch inhaltlich verändert.