ZUGFeRD 2.0 / Factur-X zur Kommentierung veröffentlicht
Am heutigen Freitag hat das Forum elektronische Rechnung Deutschland zusammen mit dem französischen Partnerforum einen Entwurf für das Profil EN16931 von ZUGFeRD 2.0 / FACTUR-X veröffentlicht. Bis zum 25. August 2017 kann somit die neue Fassung analysiert und kommentiert werden. Voraussichtlich Ende September wird dann die Finale Fassung von Factur-X veröffentlicht. Hier geht es zum Original-Artikel samt Downloads.
Wir haben einen ersten Blick hineingeworfen. Was ist anders?
Zunächst fällt auf, dass es sich bei der ZUGFeRD 2.0 um eine Core Invoice Usage Specification (CIUS) handelt. Das bedeutet, dass sie das semantische Datenmodell der EN16931 konform abbildet. Die EN16931 ist eine europäische Norm für ein semantischen Datenmodell einer elektronischen Kernrechnung für öffentliche Auftraggeber. Durch die Wahl, ZUGFeRD 2.0 als CIUS abzubilden, sind einige der bekannten Möglichkeiten aus ZUGFeRD 1.0 entfallen. Diese sollen aber im ZUGFeRD 2.0 Extended Profil wieder enthalten sein.
Was ändert sich an der Syntax?
In der Tat wurde mit der Anpassung an die europäische Norm auch die Syntax umgestellt. FACTUR-X verwendet nun eine der beiden gemäß EN16931 definierten Syntaxen: Die UN/CEFACT Cross Industry Invoice in der Version D16B SCRDM. Die Grundstruktur der Syntax zwischen ZUGFeRD 1.0 und ZUGFeRD 2.0 ist zwar gleich geblieben, hat sich jedoch jeder einzelne XPath verändert. Dies liegt insbesondere daran, dass der Name des Root-Elements von CrossIndustryDocument auf CrossIndustryInvoice geändert wurde. Darüber hinaus haben sich aber auch noch ein paar wenige weitere Elemente in Ihrem Namen geändert. In einem weiteren News-Eintrag werden wir ausführlich darüber berichten.
Ändert sich etwas an der hybriden Rechnung?
Ja und Nein. Die Grundstruktur der Verwendung von PDF/A-3 bleibt gleich. Lediglich der Namespace wurde von ferd an den neuen Namen FACTUR-X angepasst. Neu ist nun allerdings ein erwähnenswerter Hinweis, der zuvor nicht so deutlich zu sehen war. Es ist ausdrücklich zugelassen, XML und PDF in zwei getrennten Dateien zu senden oder auch nur rein strukturierte Daten. Bei letzterem handelt es sich somit um keine hybride Rechnung mehr und Anwendergruppen, die auf die bildliche Darstellung verzichten können, steht somit eindeutig auch die Nutzung von FACTUR-X offen. Die Verwendung getrennter XML und PDF-Dateien ist streng genommen ebenfalls keine hybride Rechnung mehr. Darüber hinaus könnte ein solches Vorgehen – wenn es ohne bilaterale Absprache durchgeführt wird – beim Empfänger für Verwirrung sorgen.
War der Schritt überhaupt notwendig? Warum kommte nicht ZUGFeRD 1.0 beibehalten werden?
Liest man den Entwurf erschließt sich, dass der Grund insbesondere die Umstellung der “alten” Version der Cross Industry Invoice auf die neue Version D16B der eigentliche Grund für das Update waren. Die europäische Norm definiert zwar in ihrem Teil 1: EN16931-1 lediglich ein semantisches Datenmodell. Dies ließe sich mit minimalem Update auch in ZUGFeRD 1.0 vollständig abbilden. Jedoch führt der Teil 2 der Norm CEN/TS EN16931-2 eine Liste mit Syntaxen, die konform zur Norm sind und somit zwingend von öffentlichen Auftraggebern akzeptiert werden müssen. Und hier steht nun einmal die Version D16B, die syntaktisch mit ZURFeRD 1.0 nicht kompatibel ist. Bei der Frage, ob ZUGFeRD 1.0 nun konform zur Norm ist, müsste man in Bezug auf Teil 1 eigentlich mit “beinahe” antworten. Beim Vergleich mit der Syntaxliste ändert sich diese Aussage jedoch direkt zu einem klaren Nein.
Muss ich auf ZUGFeRD 2.0 umstellen?
Es kommt darauf an. Wie so oft. Generell ist ZUGFeRD weiterhin völlig berechtigt einsetzbar. Entscheidend kann hier nun aber sein, was der jeweilige Empfänger der hybriden Rechnung empfangen will. Handelt es sich nämlich um einen öffentlichen Auftraggeber, der erst über die EN16931 angefangen hat, sich aktiv mit der elektronischen Rechnung zu beschäftigen, so wird er ausschließlich ein Format akzeptieren, welches Konform zur Norm ist. Öffentliche Auftraggeber, die bereits heute ZUGFeRD 1.0 empfangen, könnten den Kanal weiterhin geöffnet lassen. Gerade wenn ich als Rechnungssender jedoch viele Kunden im Bereich öffentlicher Auftraggeber habe (z.B. Krankenhäuser, Flughäfen, Kindergäten, Schulen, Wasserwerke, …), so kann es sich empfehlen frühzeitig seinen Softwarehersteller nach einem Update zu fragen.
XRechnung als Beispiel für ZUGFeRD 2.0
Abschließend sei noch angemerkt, dass der Entwurf von ZUGFeRD 2.0 als Syntax-Bespiel auch eine Rechnung im Format XRechnung enthält. Dies ist laut Entwurf problemlos möglich, da ZUGFeRD 2.0 als so genannte “fully compliant CIUS” alle weiteren Anwendungsspezifikationen mit einschließt.
