The European Norm on electronic invoicing

Based on the expected and huge savings derived from a massive adoption of the electronic invoice in Europe, the European Commission defined the goal “to see e-invoicing become the predominant method of invoicing by 2020 in Europe”. To achieve this goal, the European Committee for Standardization (CEN) established the Technical Committee TC 434 in 2014. The TC 434 was setup to define the European Norm on electronic Invoicing in the context of the EU Directive 2014/55.

Since 2014, the TC 434 has been working on the development of this European Norm (EN) defining the semantic model for the Core Electronic Invoice and other related Technical Specifications (TS) and Technical Reports (TR).

European Norm 16931

Today we have already a set of deliverables that will enter into force in the years to come. These deliverables have six parts:

• Part 1: Semantic data model of the core elements of an electronic invoice (European Norm).

• Part 2: List of syntaxes that comply with EN 16931-1 (Technical Specification).
• Part 3.1: Methodology for syntax bindings of the core elements of an electronic invoice (Technical Specification).
• Part 3.2: Syntax bindings of the core elements of an electronic invoice – Binding to ISO/IEC 19845 (UBL 2.1) (Technical Specification).
• Part 3.3: Syntax bindings of the core elements of an electronic invoice – Binding to UN/CEFACT XML (Technical Specification).
• Part 4: Guidelines on interoperability of electronic invoices at the transmission level (Technical Report).
• Part 5: Guidelines on the use of sector or country extensions in conjunction with EN 16931-1 (Technical Report).
• Part 6: Result of the test of the European standard with respect to its practical application for an end user – Testing methodology (Technical Report).

Most of these deliverables have already been voted and approved by the Member States, which means that the adoption of the EN in the European Member States is approaching. According to the Article 11 of the Directive 2014/55/EU:

“1. Member States shall adopt, publish and apply the laws, regulations and administrative provisions necessary to comply with this Directive at the latest by 27 November 2018. They shall forthwith communicate the text of those measures to the Commission.

2. By way of derogation from paragraph 1, Member States shall, not later than 18 months after the publication of the reference of the European standard on electronic invoicing in the Official Journal of the European Union, adopt, publish and apply the provisions necessary to comply with the obligation contained in Article 7 to receive and process electronic invoices.”

Which means that today, public entities (and national eGovernment organizations) should better start planning for this new standard that will be mandatory soon.

Interoperability as the driver

The main reason for this standard is (cross-border) interoperability. In order to achieve this cross-border interoperability, the EN has been working on two different levels: semantics and syntax. As we will see below, even if the idea is really good, there are some small things that might be addressed.

Semantics

The Norm defines a set of “core” semantic elements for the electronic invoice. The concept of core has been (and still is) controversial, but the idea is to have a “minimum” set of data concepts that “shall” or “may” be in an electronic invoice to enable a set of typical business processes also described in the EN.

The agreement on semantics implies interoperability at the semantic level, and this is quite a major achievement. These semantics are basically derived from the EU Directives, that are transposed to national legislations, so the semantics should be (and in fact are) common across Europe.

The tricky part on the work done on semantics is that not all the extremes have been addressed. In the current EN, there is an issue with code lists: the EN just points to “already existing” code lists instead of identifying specific semantic data codes. The Norm is about semantics, and the code lists hold semantic information, therefore it is not possible to leave that important part of the semantics as something handled by external and already existing code lists, which purpose and quality may not meet the needs of the EN. For instance, pointing to a “document type code list” from the “Invoice Type Code” element is an issue: The code list has a lot of data elements or concepts (such as Purchase Order, Despatch Advice, Proforma Invoice, etc). According to the EN, any of those codes can be used in a conformant electronic invoice, but it is no sense to use some of these codes in the ‘Invoice Type Code’: we can use a code that identifies the document as an Order!

Syntax

A syntax is needed to create and send the electronic invoices over the wire. The EN does not prescribe a unique syntax; however, based on a set of criteria, the EN started a process to select syntaxes from a list of international standard syntaxes. The EN will mandate the use of the syntaxes meeting these criteria, so every public entity must be able to receive and process electronic invoices in any of the listed syntaxes.

As we can imagine, most of the public entities and governments wanted the less number of syntaxes the better. And this can be understood because, even if there is a promise of interoperability because of the restriction of the syntax to the EN semantic model, dealing with several syntaxes means multiplying the implementation costs for public entities.

At the end of the assessment process, the agreement has been to implement the EN “only” with two different XML syntaxes: UBL 2.1 and CII 16B (yet too many!) and the EN has created the bindings and the validation artifacts for them.

In theory, it should be easy to transform from one syntax to the other when both are constrained by the same EN semantic model, however, the public entities shall store and process the original invoice, which means that, at the end of the day, they will need to be able to process both of them, and this is something that will have to be done per each public entity in Europe, which would dramatically increase the costs of electronic invoicing handling in the public sector.

Choosing a syntax is a convention, and one single option would have been better to simplify the adoption and roll-out of the EN in Europe.

A warning for the future

So here we are, with a norm with some (few) loose ends in the semantics, and two syntaxes to be used for the implementation.

To add yet another complexity, the EN states that you can either restrict the model by means of a Core Invoice Usage Specification (CIUS) or you can extend it by creating an extension.

Creating an extension means adding data elements not defined in the EN. For communities creating extensions, they have to be aware that these extensions will not be considered conformant to the EN. So in theory, public entities can define extensions to the EN, but they are obliged to support and receive also electronic invoices based on the EN, therefore, even if they can define an additional invoice model with extra elements, they are forced to support the EN model as well. No interoperability problems as long as they will have to handle invoices without the extra data elements they are defining.

On the other hand, a CIUS is basically a restriction. We have said that the EN has some (few) loose ends, so you may want to restrict them in order to, for instance, prohibit the use of the code Purchase Order in the Invoice Type Code element. This makes sense, but it is a way of resolving an issue derived from a problem when defining the semantic model. And the main problem with CIUS is that, if a community creates a CIUS that does not break the rules of the EN, they can claim conformance to the EN using the CIUS.

The consequence is that using a CIUS restricting the EN, a community will be able to reject valid invoices according to the EN but that do not fulfill the rules defined in the CIUS. And this opens again the non-interoperable silos model of the MIG (Message Implementation Guidelines) already invented in the EDI old-times (CIUS = MIG).

Imagine that country A creates a CIUS restricting the EN. This CIUS states that the codes for an Invoice Type Code (to continue with the same example) may only be Commercial Invoice. Country B has defined another CIUS stating that the codes for Invoice Type Code are Commercial Invoice and Corrective Invoice. When a user on country B sends a corrective invoice to a public entity in country A to correct an invoice using Corrective Invoice code in Invoice Type Code, country A public entity will reject it because it is not conformant according to country’s A CIUS (they do not support the Corrective Invoice code). This can generate lots of cross-CIUS interoperability problems. There are many examples where the proliferation of CIUS could derive into a fragmented e-Invoicing landscape in Europe.

Totally the opposite to what was intended with the EN16931.

Is there a solution?

Most of the things are already defined, so there is not much room for changes or improvements neither on the semantic model or on the extension and restrictions mechanisms. We also do not know how Member States will deal with the EN and with the legal requirements from the EC, whether they understand they need to be as close to the EN as possible or they start adding additional national requirements on top of the EN, defining new CIUS and rejecting other EN conformant documents will be key in the coming months and years.

So my three conclusions/suggestions right now are:

1. At least one CIUS will have to be created to remove loose ends in the EN, or the EN to be amended.
2. One of the two syntaxes should be deprecated and its mandatory use withdrawn.
3. National CIUS should only apply to domestic suppliers, not preventing cross-border exchange of electronic invoices.

Special attention should be paid during the dissemination of the European Norm to avoid a step back in the interoperability gains achieved with projects like PEPPOL.

The EN is a major achievement. The work done by all the members of the TC 434 has also been huge. An real important effort towards a European agreement, and an impressive technical work with many decisions made after longs hours of discussions across countries.

So now, for the countries implementing the EN, my message would be to stay as close to the EN as possible avoiding a potential non-desirable fragmented scenario for the years to come.

Oriol Bausà
B2Brouter CEO