eInvoice and EN16931: 1 Standard, 2 Syntaxes, many CIUS

Better interoperability and no purely national extensions. Thus the eInvoice is to lead its triumph from the public administration in Europe to the economy. Thus the idea of ​​the fathers of EN16931 before. After the publication, the question arises as to why it was not only possible to agree on a syntax for implementation, since this would have been easier for implementation. This initially very logical reasoning, however, is too brief. The electronic exchange of invoices is not a new issue. At least not for all market participants in Europe. For decades, various processes have been established in the economy, especially EDI, especially on the basis of UN / EDIFACT. This global standard is the world’s most widely used standard in business.

However, not by contracting authorities. Many European countries used a standard based on XML in the area of ​​B2G with UBL. Especially in France and Germany, the CrossIndustryInvoice has gained momentum in recent years, not least thanks to the ZUGFeRD format. In the Netherlands, flowers and agricultural products are also traded mainly on the basis of the CrossIndustryInvoice. In this respect, the economy is still a lot ahead of the administration at the European level.

However, the EN16931 and the related directive are addressed in particular to contracting authorities as recipients of invoices. When discussing the number of syntaxes, therefore, the overall cost of the combination of norm and legislation must also be considered. The mixed mixture and the advantage of the economy, which still exists in many countries, therefore has a decisive influence on the decision: since UN / EDIFACT has hardly been used in the administration, but the economy is an important data exchange standard, the standard takes this syntax into account also. CEN / TS 16931-3-4 therefore defines the technical illustration of the semantic data model in UN / EDIFACT. However, this syntax is not mandatory, but can be maintained or re-implemented on a voluntary basis.

If I send only the obligatory elements, I have less to do !?

With the definition of the standard now everything is clear, especially since it is only the core elements of an eInvoice. Quite simply, it is not so easy. According to the semantic data model, only a few elements are mandatory. If one leaves legal aspects and business rules aside, see an electronic invoice, which contains only the obligatory data, very lean.

This data is far from sufficient for the goal of automated processing, and in particular of the audit, let alone the obscurity. However, on the other hand, not every recipient needs all the available features that the semantic data model provides. To solve this dilemma, the standard provides the idea of ​​the Core Invoice Usage Specification. It is intended to enable the eInvoice receiver to define which of the optional elements it needs for automated billing processing.

And that is not new in itself. Only the term CIUS is new. In the case of standardization, the concept of application is usually used for this purpose. It is intended to help the payer what information the invoice recipient needs beyond the mandatory data (data model and tax). Such application recommendations exist so far for certain user groups, as well as for large invoice recipients. The core of these recommendations is, in most cases, to establish a technical link between the invoice file and the system of the recipient. Typical elements for this are, for example, the order number, contract number, a cash reference or another transaction number. On a paper invoice, such a field is often labeled “Your reference”.

A further aspect of an application recommendation is usually to define which values ​​of codelists can be processed on the receiver side. For example, the list of possible quantity units contains more than 2000 different values. In addition, the standard supports more than 40 different document types, which can represent variants of the invoice or credit note.

More or less interoperability of the eInvoice thanks to the CIUS

But this is precisely where the challenge begins with interoperability. For what does it mean in practice if an invoice recipient rejects an invoice because it can not process a particular document type? Then the invoice sender will probably have to deposit this in his system. Interoperability has just declined, as the systems must suddenly differ between different billing recipients. An example of this is the discussion of whether to send a billing correction with the document type 381 – Credit note, or as 380 – Invoice with negative totals. The standard explicitly allows both possibilities. For example, the Netherlands today only sends out negative invoices for this purpose. In other countries, however, credit notes are common.

Now, if the Netherlands is to create a CIUS that limits the corresponding codelist so that no credit note instances are allowed, but another Member State does not allow the use of the negative account, there is no longer any interoperability. When exchanging invoices between these two countries, a conversion is compulsory.

In the definition of the CIUS, the norm also provides for a further possible restriction which reduces interoperability. The explicit prohibition of sending optional items. The use of this option means that a new channel for the dispatch of invoices is compulsorily created for this recipient group and the cost of implementation increases.

Recommendation on the use of CIUS

The basic idea of ​​CIUS is outstanding. In practice, only a CIUS actually enables the automated processing of invoices when implementing EN16931. A CIUS provides the possibility to define, at a central location, which information a receiver group needs for automated processing. In particular, the use of generic elements for the technical transmission of these assignment values ​​greatly increases interoperability. In this case, the technical implementation is separated from the technical requirements. For example, if a receiver group requires a cost center, the second a routing ID, and the third a transaction number, then three different technical implementations need not to be defined. For example, all three information could be submitted in the BuyerReference field. The interpretation of the value defines the recipient. Under normal circumstances, the the recipient transmits the information to be given to the invoice provider at the time of ordering.

In principle, the CIUS also offers a further possibility to deal with unnecessary information. There is an alternative to prohibiting unnecessary optional elements. If a CIUS clarifies clearly and transparently that this information is ignored during the audit and processing, this does not limit interoperability. The sender does not have to reconfigure his software, but can send the same structure to all billing recipients.

Prospects for translators and billers

If as many specifiers of a CIUS approach these recommendations, the complexity of the implementation is significantly reduced. However, a challenge remains. As a rule, an invoice recipient needs only 20 to 25 information to process an invoice automatically: about 15 information for the (taxable) mandatory data, and the rest depending on the respective accounting processes. And precisely these requirements change from recipient group to recipient group. For simpler implementation, however, they should not be defined individually, if possible in an association, or at the level of the country. However, it is already clear today that the number of CIUSs in Europe will rise sharply. A central access to such information is therefore particularly desirable.