The situation in Europe with regards to electronic invoicing is a useful example of the present confusion in eBusiness document standards.

This article will try to both explain the situation in Europe and also how UBL (the OASIS Universal Business Language) intends to satisfy European requirements. Without such an explanation, many of those implementing what they believe to be appropriate solutions will be misled into thinking they are standardizing, when in fact they aren't.

In late 2010 the European Commission issued a communication aiming to ‘Promote a common e-invoicing standard’.  It stated:

Following the recommendations of the Expert Group, "the UN/CEFACT Cross-Industry Invoice (CII) v.2 should be adopted as the common reference semantic data model upon which future e-invoice content standard solutions are based". It should be left to the market to utilise this data model and adapt it to specific business needs.

Unfortunately, the Commission have chosen to recommend a data model that is so big and complex that conformance does not ensure any consistency in what could be contained in an Invoice document. So the European standards organization, CEN, has been commissioned to create a meaningful subset, as well as a user guide, for how the data model should be used.  This CEN Message User Guideline project (MUG) is currently work-in-progress.

Meanwhile, UBL aims to ensure that the UBL Invoice both satisfies the requirements of the European Commission as well as those of the Single Euro Payments Area (SEPA), the European integrated retail payments market. 

The SEPA customer-to-bank electronic document formats (known as Payment Initiation or, without irony, pain messages) cover the ‘downstream’processing of invoice information for payment through the banking systems.  Like all XML financial industry standards,these are based on the ISO 20022 vocabulary.

The UBL Invoice is an ‘upstream’ document that must contain the information required by the banking system.  UBL 2.1 will provide a mapping of the UBL Invoice elements to the equivalent SEPA pain elements (there are an estimated 170 of these) so that applications can transform information in one format to the other. In a business sense, this means extracting payment information from an Invoice.

When the CEN MUG project finalizes its core invoice requirements, UBL will also map those to the UBL Invoice.  This should be straightforward, as the MUG will be similar to the existing CEN BII ‘core’ subset based on the UBL Invoice.

Together these tasks will ensure UBL meets all requirements of eInvoice users in Europe.

In practice, this means that anyone using the UBL Invoice does not need to (and should not) consider changing to various flavours of UN/CEFACT or any other XML document standards – despite the misinformation being circulated by vested interest groups.  Indeed, the UBL Invoice is the only XML Invoice document standard that is sanctioned, stable, integrated within a suite of supply chain documents and is the nearest thing the world has to a purpose-built ebXML document format. 

Significantly, UBL invoices have been used in some of the world’s most successful eInvoicing projects over the past 6 years– many within Europe.  It is unfortunate that the European Commission (itself a user of UBL for eInvoicing) is not capitalizing on this advantage in its policies.

This paradox exemplifies the confusion about standards and emphasizes that if the eInvoice community wants to find a clear path towards a single common standard format for XML business documents (such as eInvoices), then UBL is the most practical base to build upon.

Fortunately, history tells us that ultimately pragmatism will prevail and market requirements for eInvoice document standards will be met by the most suitable solution – is this case the one that exists and works.  Meanwhile we will have to bear with the noise and distraction of false prophets.  UBL can bear it if you can!