ZUGFeRD 2.0 / FACTUR-X published for public review
Today, the German forum for electronic invoicing (FeRD), together with the French partner forum, published a draft for the EN16931 profile of ZUGFeRD 2.0 / FACTUR-X. Until August 25th 2017, the new version can be analyzed and commented. Probably end of September, the final version of Factur-X will be released. Click here for the original article with downloads.
We took a first look. What is different?
First, it is noticeable that ZUGFeRD 2.0 is a Core Invoice Usage Specification (CIUS). This means that it conforms to the semantic data model of EN16931. EN16931 is a European standard for a semantic data model of an electronic core invoice for contracting authorities. By choosing to map ZUGFeRD 2.0 as a CIUS, some of the well-known features of ZUGFeRD 1.0 have been omitted. These are, however, to be included in the ZUGFeRD 2.0 Extended Profile.
What changes in syntax?
In fact, the syntax was adapted to the European standard. FACTUR-X now uses one of the two syntaxes defined according to EN16931. The UN / CEFACT Cross Industry Invoice in version D16B SCRDM. The basic structure of the syntax between ZUGFeRD 1.0 and ZUGFeRD 2.0 has remained the same, but every single XPath has changed. This is due in particular to the fact that the name of the root element of CrossIndustryDocument has been changed to CrossIndustryInvoice. In addition, a few more elements have changed in name. In another news entry we will report in detail.
Is there a change in the hybrid invoice format?
Yes and no. The basic structure of using PDF/A-3 remains the same. Only the namespace was adapted by ferd to the new name FACTUR-X. New is now however a noteworthy note, which was previously not so clearly stated. It is expressly permitted to send XML and PDF in two separate files or even purely structured data. The latter is therefore no longer a hybrid invoice format and user groups, which can dispense with the pictorial representation, thus clearly now can use FACTUR-X as ell. The use of separate XML and PDF files, strictly speaking, is no longer a hybrid invoice. Moreover, if this is done without a bilateral agreement, such an approach could create confusion among the recipient.
Was the step necessary at all? Why was ZUGFeRD 1.0 not just updated?
Analyzing the new design reveals that the actual reason for the update was in particular the conversion of the “old” version of the Cross Industry Invoice to the new version D16B. The European standard defines only a semantic data model in its part 1: EN16931-1. This could be mapped completely with minimal update also in ZUGFeRD 1.0. However, Part 2 of the CEN / TS EN16931-2 standard carries out a list of syntaxes which are in conformity with the standard and are therefore compulsorily accepted by contracting authorities. And here is the version D16B defined, which is syntactically incompatible with ZURFeRD 1.0. In the question of whether ZUGFeRD 1.0 is now conform to the standard, one would have to answer “almost” with regard to Part 1. When compared to the syntax list, however, this statement changes directly to a clear no.
Do I need to switch to ZUGFeRD 2.0?
It depends on. As so often. In general, ZUGFeRD is still fully justifiable. However, what the recipient of the hybrid invoice wants to receive is decisive here. For instance, if a public contracting entity, which has started to deal actively with electronic invoices through EN16931, it will only accept a format which conforms to the standard. Public contractors who already receive ZUGFeRD 1.0 would still be able to leave the channel open. However, especially when you have a lot of customers in the field of public clients (eg hospitals, airports, childcare centers, schools, waterworks, etc.), it is a good idea to ask your software manufacturer for an update.
XRechnung as an example for ZUGFeRD 2.0
Finally, it should be noted that the draft of ZUGFeRD 2.0 also contains an invoice in the form of XRechnung as a syntax example. This is possible according to the design, since ZUGFeRD 2.0 as so-called “fully compliant CIUS” and so includes all other invoice specifications.
