Challenges implementing EN16931

Now the EN16931 is completely published: The semantic data model is fixed, the syntaxes for the implementation are defined. The mapping between business terms (semantics) and technology (syntax) is defined.
Thanks to the publication on the official journal of the European Commission, the dates for the live operation are also clear. Thus, implementation should be easy now, one would think. But unfortunately it is not so. The technical documents leave some questions open, especially for codelists. And this can lead to not inconsiderable challenges during implementation.

Unclear codelists

This starts with one of the most important elements: the code for identifying the document type. In the semantic data model, all values ​​of the code list UNTDID 1001 are allowed, which represent invoices, invoice corrections or credit notes. However, these are not mentioned in the semantic data model, nor in the mapping documents. At the moment, it is only possible to speculate which codes are actually valid. If one looks into the code list UNTDID 1001, a large number of possible code values ​​are considered. Some of them are indisputable: 380 for the regular incoive, 381 for a credit note. At least, if the latter is not presented as a negative invoice. This is the case with ZUGFeRD 1.0, as well as some European Member States (for example the Netherlands).

For the other codes, implementation is more difficult. They often involve different processes. The receiving system must support this when, for example, it receives the pro forma invoice, or an invoice that only containts VAT.

Do the validation artifacts help here?

The validation artifacts mentioned in the technical documents could provide an indication of the implementation. This is a package of schematron files. With their help, XML instances can be checked against a set of business rules. Apart from tests of the structure and the business rules defined in the semantic data model, these tests also include the correct application of the technical codelists. The source of these validation artifacts is referenced to CEN’s FTP server, but there are no files to this day.

Undefined Codelists

A further challenge in the implementation is that the semantic data model refers to two codelists, which still do not yet exist. A codelist to qualify an electronic address (e.g., as an e-mail address, web page, etc.) and a codelist to define reasons for exceptions of VAT. Although there are already individual organizations or user groups, which have developed their own definitions. For both Codelists, this is not the case as the norm points to a definition from the EU project Connecting Europe Facility, which does not exist. It is therefore already foreseeable that the documents require an update or at least a clarification.

However, such an updating process within the standardization is lengthy. As a rule, it requires phases for commenting and quality assurance, for which minimum duration is provided. Thus, short-term publication is hardly to be expected.

Pragmatic approach to implementation

How should one proceed best? Waiting is actually out of the question, as the deadlines for implementation are already running. The real challenge for the implementation is not the technical implementation, but the processes of public contracting authorities have to be adapted efficiently. Only then the electronic invoices can be received and processed efficiently and without media breakage.

As far as the codelists are concerned, we should start with simple cases: for the document type, for example with the standard types 380 and 381, as well as 389, if a credit memo is to be implemented according to the credit method (self-issued invoice). The lack of the code list for VAT exemptions is unattractive, but in most cases it is not essential, since the few systems can now deal with all the cases envisaged by European legislation and their national implementation. The statement of the reason for exception in human-readable form supports the accountant, who then has to manually correct the correct tax case.

Only the lack of the code list for the qualification of electronic addresses can lead to challenges in practice. This is particularly true when a system is used to transfer the electronic invoices that uses exactly this field to identify the technical systems for dispatch and reception. As a rule, these systems have their own codelists for this purpose, but the aspect of standardization does not apply. In the worst case, the sender would have to maintain several codelists for this purpose. However, the systems for accounting must also support this, depending on the recipient. It is therefore hoped that clarification will be made as soon as possible.