Tim McGrath, vice chair of OASIS UBL , explains in his recent post on UBL XML.org, that UBL is the clearest path towards a single common data format for XML business documents. Underneath is an impressum of his post (all credit go to Tim McGrath):
“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!
Source: UBL.XML.org
Related posts
- EXPP Summit 2011 in Barcelona: observations
- Recent Finnish research shows: decreasing adoption rates of e-billing by consumers
- Californian DWC Issues eBilling Rules
- Big news in the world of SAP EDI and B2B
- How eBilling can help SEPA Direct Debit acceptance
- EBICS – The Standard for Corporate-to-Bank Communication?
- Is promoting e-Billing the same as Greenwashing?
- eFactura, the Argentinian Electronic Invoice method
- UN/Cefact ISO 20022 XML or/and UN/Cefact CII2?
- Market penetration of e-invoicing in Europe
“standard” and “format” are two words you CANNOT use together!
After more than 20 years of failures trying to define “standard format(s)”, is it not possible to stop wasting money?
When you do integrate two applications (or more), you will have to map/mediate their respective interfaces.
I have personally named the root cause of this as the “Krakow Conjecture”: <>.
Look at what happened the past 20/30 years, IT application is about modelling a portion of the reality into a data model, and during the time I have spent to write this comment, you probably had hundreds of developers who have modelled the same portion of the reality with different data models ;-)
Of course, an “Invoice” stays an “Invoice”, and then, it is quite frustrating to see all these different “data models” of the same “Invoice”… Of course, you are then dreaming about a “common” “standard” “data model” of an “Invoice”, but you can keep on dreaming about THE standard… I don’t ;-)
For the optimistic ones, you might still think that there is ANOTHER way than “data model” to capture a portion of the reality into a IT system and continue the quest towards a standard “thingy”, but PLEASE stop with the idea of a “standard format”!!! For the ones who simply want to continue to integrate two applications (or more), you should simply improve your “mapping skills”.
Voila, that’s my opinion ;-)
Hello Patrice,
Thank you for pointing out to our slip of the pen; we changed ‘standard format’ into ‘data format’.
Admin
Why don’t we re title this, ‘In Search of the Holy Grail!”
I agree with Patrice. The comments on are right on. Even within the same ‘data format’ a minor version change can cause havoc.
In the post above multiple ‘data formats’ are mentioned in this search of the holy grail… UN/CEFACT Cross-Industry Invoice (CII) v.2 (what about those using v.1?), MUG, etc, etc
Hello Patrice and Gary,
It wouldn’t be fun if there were no-one to disagree with you. So I will give it a try.
Patrice - you say that “For the optimistic ones, you might still think that there is ANOTHER way than “data model” to capture a portion of the reality into a IT system..” and “you should simply improve your ‘mapping skills’”.
You are right and wrong at the same time. If we are to realize a vision of a 4-corner model (supplier - service provider A - service provider B - customer) - then a standard (on the wire) data format that can be validated is needed between the service providers. There are 500 service providers in Europe alone and it is impossible to make bilateral interchange agreements with all of them. We will never get to a situation of global reach with the current modus operandi.
I dont think that it can be disputed that it can be done. It works in so many other domains and a data model just doesn’t scale. We dont have a long enough life span to do all these mappings.
I know it will work in real life - see how operators and software providers exchange several version of UBL with more than 30,000 public public sector institutions in Denmark with hundreds of different ERP- and workflow-systems.
I acknowledge that mapping is still a very important discipline and will be moving forward. But we should use our mapping skills to map legacy formats to well documented “on the wire” data formats. All that is needed is authoritative validation tools that cover more than the basic structural syntax. Co-constraint validation with tools like schematron can close the gap.
Happy mapping
Mikkel Hippe Brun
Tradeshift
It should be mentioned that Tim Mc Grath is one of the current Vice Chairs of UN/CEFACT having a mission to help develop UN XML messages for Supply Chain.
UN/CEFACT and OASIS UBL have signed a couple of years ago a MoU building the basis of convergence of the two syntaxes.
It’s interesting to read that Tim only speaks about UBL as the single syntax to use and leaves UN XML aside despite his engagement there.
Natascha,
Maybe Tim is contemplating that future UN XML will be a sort
of UBL 3.0? I think something could be done if UBL will be based on the UN CCL (Common Components Libary). Then, what Mikkel was saying back in 2011 could be possible, a common data model with common data elements library.