Is ZUGFeRD 2.0 just as easy to use as its predecessor or any other data formats for e-invoices?

ZUGFeRD 2.0

We still love the concept of ZUGFeRD for hybrid invoices: Structured data is an important ingredient for many digital workflows and invoices are an important part of all business. In essence, invoices are a good example for structured data - but are still exchanged as paper or plain PDF files. Even though everybody knows that exporting and importing structured data from and into ERP systems would be much faster and less error prone.

A standard was needed and ZUGFeRD was the first widely used hybrid invoice standard. It does not only standardize the structure (that did e.g. EDI long time ago), it also allows for independent transition from paper to digital for sender and receiver. A ZUGFeRD invoice can always be used as a paper replacement, the only things that you need are a device and a PDF viewer. But if the receiver has its machinery ready, it also allows for direct import of structured data unveiling all the advantages of digitization.

We have recently updated our PDF technology to ZUGFeRD 2.0 which is also supported in the solution for Microsoft Dynamics NAV (current name is Business Center) that we built with Konica Minolta Business Solutions and COI. What is ZUGFeRD 2.0? Is it better than the old ZUGFeRD? We need to look back to understand the background.

One reason for the new version is public administration. Many of such entities suffer from their long processes that frequently involve several employees to sign off for invoices. That in turn often prevents them from using invoice boni or skonti granted fast payment and might even result in additional payments. It is easy to see that digital processes could create substantial savings via faster invoice processing. Therefore, EU government requires every public administration entity to accept electronic invoices (for federal entities starting in April ‘19, for state level entities in April ‘20). Since that requires further clarification about what an electronic invoice is, they asked their standardization organization, CEN, to come up with a standard for electronic invoices for public administration entities which has been published as EN16931. For the ones who know EU, it will not come as a surprise that the standard is a compromise: It specifies the required content (semantical information) and how it is bound to concrete syntaxes, namely UN/CEFACT, EDIFACT and UBL. It neither requires nor disallows hybrid invoices based on PDF/A-3.

During development of EN16931 France began to like ZUGFeRD so much, that they built their own specification on it (which has the name Factur-X). But since there are a few additional requirements in Factur-X, it was not completely the same as ZUGFeRD 1.0. That had to be fixed with ZUGFeRD 2.0.

But back to the CEN norm. In Germany, the Federal Ministry of the Interior took up the task to define processes. And the IT people there found it smart to find a solution that would work ideally for themselves and then just make their portal open for other authorities. From their point of view, the PDF container was just an annoying companion, so they did not build on the ZUGFeRD model for a hybrid invoice. It is easy to see that XML only might work for public administration entities with fully digital invoice processes – which, as of today, is definitely not the case in every public administration. But we all know how quick public administration is to introduce changes such as digital workflows, do we? So from that perspective, the Federal Ministry of the Interior was a very much forward looking organization.

Just to be clear: In a fully digital world there would be no need for the PDF container – at least as long as everything works as expected. The PDF container is serving paper like workflows and might be seen as a temporary solution. But as such, it makes a lot of sense and at least we see no good reason to not use it: PDF compresses the XML structure and it is easy to extract it from the PDF container. And there is another reason: An electronic invoice may come with additional information in a separate file, e.g. a list of items provided. In an XML world these additional files will usually come in via external file references. In PDF they can easily be attached in the same way as the XML structure is and links can refer from the PDF andthe XML to these other attachments.

But anyway, XRechnung is not a big deal for many users of ZUGFeRD: If electronic invoices are created with an ERP system and if that system does also maintain information about what communication means and format a receiver prefers, the process can be fully automated: Sending XRechnung to the Federal Ministry of the Interior and it’s fans and ZUGFeRD to the remaining administration and industry.