CIUS, Shrödinger’s new cat

European Member States have been working on the definition of a standard model for the electronic invoice for quite a while. All represented countries in the CEN (European Committee for Standardisation) have been able to participate, contribute and vote.

As Europeans, we have reached consensus, and we have agreed the new European Norm 16931 as the common semantic model in Europe.

With its implementation through two different syntaxes, UBL and CII, this standard has entered into force last 18th of April.

The European Norm includes the concept of the CIUS (Core Invoice Usage Specification). A CIUS allows an entity to define specific rules for the treatment of EN invoices. Defining a CIUS, you cannot go beyond the boundaries defined by the EN, this means not adding business terms  and not breaking the rules defined by the EN. However, you can add restrictions: For instance, you can make an optional element mandatory in your CIUS. You can restrict a code list. You can set the length of a specific data field, or you can add any type of business rules.

So far so good the CIUS… looks like a brilliant idea.

But the consequence of the existance of the CIUS concept is that, instead of accepting the standard EN as-is, many countries in Europe seem eager to create its own CIUS. And it could be a good idea if the intention is to explicit domestic or routing rules, but it seems CIUSes are also being used to add requirements that were not included (or even rejected) into the agreed EN.

In my opinion, the biggest error of the EN has been to include the CIUS in the definition of its Compliance. Currently section 4.4.3 of the EN reads as follows:

“A receiving party may only claim compliance to the core invoice model if he accepts invoices that comply with the core invoice model in general, or with a CIUS, that is itself compliant with the core invoice model”

With this definition, any receiver can reject EN invoices based on the fact that they do not comply with the restrictions of their specific CIUS. These entities can still claim compliance to the EN as they comply with their own CIUS, but they can reject an EN compliant invoice as it does not comply with the restrictions of their own CIUS.

Like with the Schrödinger’s cat, the electronic invoice falls into a paradox:  Whether or not an electronic invoice is compliant to the EN is unknown until it interacts with, or is observed by the external world. When this happens, it becomes compliant or not. Therefore we can have an electronic invoice compliant and not compliant at the same time. You might say that an invoice has a quantum state.

Even though the EN is a huge achievement and will bring a lot of value, we run the risk of building non-interoperable islands in Europe. If we cannot send electronic invoices to all our customers in Europe using the same format and the same delivery mechanism, why have we done all the effort to define this European standard in the first place?

I think that CIUSes should not be used as a tool to reject valid EN invoices.

I believe this has never been the aim of the European Norm and we cannot afford repeating the same errors done in the deployment of the old EDI world (pain we are still suffering).

Everybody shall accept electronic invoices according to the European Norm, so please, remove the “or with a CIUS” from the compliance statement.

In summary, if you want to create a CIUS, do it, but ACCEPT all EN electronic invoices despite the CIUS they are created with.

Oriol Bausà
B2Brouter CEO