Menü
Menü
Ab dem 01. Januar 2025 zählt in Deutschland die E-Rechnungspflicht. Was das konkret bedeutet, wieso eine solche Änderung eingeführt wird und was sich für Unternehmen in Zukunft ändert, sind Themen, mit denen wir uns in der folgenden Blogreihe beschäftigen werden.
Weitere Teile der Blogreihe zur E-Rechnung:
TEIL 1: Was bedeutet die E-Rechnung
TEIL 2: Übergangsregeln und Zeitplan der E-Rechnung
TEIL 3: Formatunterschiede der E-Rechnung
TEIL 4: Voraussetzungen für die Übertragung der E-Rechnung
TEIL 6: Verarbeitung der E-Rechnung in Microsoft Dynamics 365 Business Central / Navision
TEIL 7: Häufige Fragen zur E-Rechnung
TEIL 8: Zulässige Formate in Deutschland
Neben den technischen Herausforderungen, eine elektronische Rechnung zu erzeugen oder zu verarbeiten, gibt es auch inhaltliche Hürden, welche eine Konsequenz aus den technischen sind.
Eingangsrechnungen wurden bisher manuell erfasst oder verarbeitet; daran verändert sich im Grunde nicht viel. Genauso wie man zuvor ein Programm brauchte, um ein PDF anzuzeigen, benötigt man nun mindestens ein Textprogramm, welches XML darstellen, und allem formatieren kann.
Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) machen bei elektronischen Rechnungen im Übrigen auch keinen Unterschied – es zählen die gleichen Vorgaben wie bei vorher elektronisch übermittelten Belegen!
Gut zu wissen:
Beim unbedarften Recherchieren im Internet stößt man ab und an auf einen abenteuerlichen Click-Bait, dessen Ziel es meistens ist, zum Erwerb von Dokument-Management-Systemen zu motivieren.
Diese Systeme können Unternehmensprozesse tatsächlich vereinfachen und durchaus hilfreich sein, man braucht sie aber nicht zwingend bei der Einführung der elektronischen Rechnung – hier kommt es immer auf die Verhältnismäßigkeit an.
Zur reinen Anzeige von elektronischen Rechnungen gibt es bereits gute Open-Source Programme. Der Quba-Viewer der ZUGFeRD-Community sei hier beispielsweise zu nennen.
Wenn es um die Validierung von elektronischen Rechnungen geht, lohnt sich ein Blick zu github. Die Koordinierungsstelle für IT-Standards bietet auf github ein Repository mit einem Validatoren und den zugehörigen Schemata.
Und hinsichtlich der GoBD (Grundsätze ordnungsgemäßer Buchführung): “Bei Fragen oder Unsicherheiten, wenden Sie sich an Ihren Steuerberater oder Wirtschaftsprüfer”.
Hier führt im Grunde kein Weg an einem EDV-gestützten Verfahren vorbei. Die Formate manuell zu erstellen oder zu übertragen, wird auf Dauer keinen Sinn ergeben und abhängig vom Volumen der Ausgangsrechnungen schlichtweg nicht möglich sein. Da es nunmehr eine gesetzliche Vorgabe ist, müssen alle Hersteller entsprechend nachliefern.
Bei Systemen, die keine Updates mehr erhalten oder schlichtweg durch Anpassungen nicht mehr updatefähig sind, sollte man über einen Umstieg auf eine neue Version oder Anbieter nachdenken.
Die Frist hierfür wäre durch die Ausnahmeregelungen mindestens bis Ende 2026.
Da derzeit zwei Formate gängig sind, wird sich zeigen, ob sich am Ende ein Format durchsetzen wird. Idealerweise unterstützt das EDV-System beide Varianten. Legt man sich nur auf ein Format fest, kann es also sein, dass der Rechnungsempfänger über Argumente verfügt, doch noch von “seinem Standardformat” zu überzeugen.
Kurz und knapp:
Neben technischen Komponenten müssen sich Unternehmen jedoch auch um eine inhaltliche kümmern: ihre Konfigurations- und Stammdaten.
Die CEN-Norm EN 16931 definiert beispielsweise in den Integritätsbedingungen als Geschäftsregel BR-11, dass im Dokument die Postanschrift des Käufers einen Ländercode der Käuferanschrift enthalten muss. Im dazugehörigen semantischen Modell wird dies unter BT-55 wie folgt konkretisiert
“Die Listen der zugelassenen Länder werden von der EN ISO 3166-1 Maintenance Agency „Codes for the representation of names of countries and their subdivisions” geführt.”
Laut ISO wäre das entweder “DE”, “DEU” oder 276. Die UNECE empfiehlt hier allerdings den “ISO ALPHA 2 Country” oder den numerischen Code.
Bei “Deutschland” oder bei einem nicht in den Stammdaten hinterlegten Land, kann, je nach Regeln eines Validators, im Rahmen einer automatisierten Verarbeitung beim Empfänger ein System letzteres als Warnung ausweisen.
Ist beispielsweise bisher bei einer Rechnung über eine innergemeinschaftliche Lieferung der Hinweis auf “Steuerfreie innergemeinschaftliche Lieferung” nur als Text anzugeben, so muss in einer elektronischen Rechnung nach BR-118 der CEN-Norm EN 16931 eine codierte Bezeichnung der Umsatzsteuerkategorie nach UNTDID 5305 angegeben werden – dies ersetzt den Texthinweis.
Ähnlich verhält es sich mit dem Leistungszeitraum. Soll dieser definiert werden, muss er als Startdatum und Enddatum erfasst werden. Der Hinweis als Text ist irrelevant. Unabhängig davon, ob es bei ZUGFeRD in der optischen Version enthalten ist.
Auch die Maßeinheit wird hier klar eingegrenzt: Die Koordinierungsstelle für IT-Standards, welche für die Koordination der XRechnung mit der öffentlichen Verwaltung zuständig ist, definiert hier zum Beispiel, dass
Die Maßeinheit [...] unter Anwendung der in UN/ ECE Rec No 20 Intro 2.a) beschriebenen Methode aus den Listen UN/ECE Recommendation No. 20 „Codes for Units of Measure Used in International Trade“ und UN/ECE Recommendation No 21 „Codes for Passengers, Types of Cargo, Packages and Packaging Materials (with Complementary Codes for Package Names)“ ausgewählt werden muss.
Bedeutet also: Stand auf der Rechnung bisher “Stück” muss also unter Umständen elektronisch “PCE” übermittelt werden.
Gut zu wissen:
Schlägt nun ein Prüfmechanismus beim Empfänger an, bedeutet das erst einmal, dass etwas nicht dem entspricht, wie es erwartet wurde. Ob der Empfänger den Beleg dann verwirft, hängt von den Regeln des Empfängers ab. Der Beleg wird per se nicht ungültig – dies entscheidet der Empfänger. Gründe hierfür reichen von fehlenden umsatzsteuerlichen Pflichtinformationen bis hin zu Informationen, die für den Prozess ausschlaggebend sind.
Bei der Einführung der elektronischen Rechnung müssen sich Unternehmen also nicht nur um die technische Erzeugung der Rechnungsdatei kümmern. Vielmehr muss auch ein Augenmerk auf Stamm- und Konfigurationsdaten sowie Code-Standards zwischen beiden Partnern gelegt werden.
MARKUS WEILAND
project manager
Das könnte Sie auch interessieren
