In a previous blog we introduced the notion of the OASIS Universal Business Language (UBL) to be used in the exchange of business documents between a supplier and a customer. We focused on the invoice document, although UBL 2.1 now defines 65 business documents to support the exchange of most business transactions in any supplier/customer interaction.
In the past, the typical way of exchanging invoice data was to generate a paper invoice at the supplier end, and use the physical mail system to facilitate the exchange of the document. Variations of this included generation of a PDF and exchanging the document using an e-mail system with the PDF attached.
Any reasonably sized customer would then be saddled with a significant problem – moving the data off the paper or PDF into their mechanized systems (typically proprietary) that will process the data. Methods to accomplish this includes re-keying/error correcting the data, or performing a Scan/OCR/error correction process. In Canada, a very conservative estimate of the costs to process a single invoice from paper or PDF is $10 (based on European estimates of €7-15 per invoice). A customer that had to process a huge number of invoices (e.g. the Canadian Government has to process millions of transactions) could incur significant expense doing nothing other than re-creating data in electronic form that used to be in electronic form at the supplier end.
Thus the implementation of an infrastructure that could support the electronic exchange of invoice data in a globally open way could greatly benefit all organizations that had to process very large numbers of invoices. But what of the small to medium sized organizations – the very backbone of businesses in Canada. If you are an organization that only sends out a few invoices per month, are there benefits for you as well? Fortunately there are more benefits beyond cost savings in data input savings for the customer.
First let us examine such an infrastructure, and then use a specific example of what is already accomplished.
In any exchange of documents between a customer and a supplier, we require an infrastructure that provides two key components:
- A way to encode the document so that the business data can be exchanged and understood by all – best to be a global open standard that is vendor/software/hardware independent.
- An electronic infrastructure to support the physical exchange of the document between any customer and any supplier – more that one infrastructure is OK as long as they support the same global open standard and provide portals to all other similar infrastructures.
UBL – a common encoding
Fortunately, most of the work to come up with a global standard open form for the e-invoice, and over 60 other business documents, has been accomplished by OASIS. The Universal Business Language is flexible enough to include your own business objects and XML syntax as extensions. It is also structured in such a way that you can make your own business documents utilizing a common library of business objects. UBL has been adopted as a cornerstone for electronic commerce in many countries (not yet Canada). UBL 2.1 has just been approved as of November 4, 2013 adding 34 new document types, bring the total of document types supported to 65.
Now lets address the physical electronic exchange of these UBL documents.
Document exchange infrastructure
Many countries have now adopted UBL as their standard form for their e-invoices. It is reasonable for the construction of any document exchange infrastructure to be tackled at the country level, due to the project size and the implications for that country to remain competitive on the planet. There are two ways for a country to move forward on this document exchange infrastructure
- Build option – Design, build and implement an infrastructure
- Buy option  – Use a third party infrastructure
Build Option
Examples of the build option are found in Denmark and the EU where they built customized solutions:
Denmark constructed an infrastructure called Nemhandel (Easy Trade). Initiated in 2005 (based on UBL 0.7), it was initially implemented to allow all suppliers to invoice the government of Denmark using UBL (which they had to do by law). As the use of this system grew, suppliers found they could also invoice any business on that system. As of today some 175,000 private companies have used Nemhandel, and the government reports savings of €500M in just the first 5 years.
The EU constructed an infrastructure called PEPPOL (Pan-European Public Procurement Online). Initiated in 2008, this project has been developing and implementing the technology standards to align business processes for electronic procurement across all governments within Europe, aiming to expand market connectivity and interoperability between eProcurement communities.
The PEPPOL consortium was comprised of seventeen partners (mostly leading public eProcurement agencies) within 11 countries:  Austria, Denmark, Finland, France, Germany, Greece, Italy, Norway, Portugal, Sweden, and the United Kingdom. PEPPOL project activities were funded jointly by consortium members and the European Commission. The PEPPOL pilot ended and the technology lives on as an open-source implementation named OpenPEPPOL.
Just recently, Poland announced the connection to the OpenPEPPOL network as a cornerstone of the Polish national e-Invoicing implementation strategy.
Buy Option
As UBL becomes the de facto standard for electronic commerce, we will see a number of companies offering off the shelf platforms supporting UBL. We will take a look at one of the products first out of the gate – Tradeshift.
Many of the developers involved with the construction of Nemhandel and PEPPOL recognized an opportunity to build a common commercial platform, based on UBL.
They formed a company in Denmark called Tradeshift, now with world headquarters in San Francisco that supplies such an infrastructure for exchange of UBL documents, implemented as a SaaS in the Cloud. This cloud based infrastructure is now installed in over 190 countries (including Canada), and provides portals to existing custom infrastructures such as NemHandel and PEPPOL.
Such an infrastructure is a key requirement for the move to electronic invoicing. The challenges to implementing such a solution are:
- Technical changes to existing customer/supplier systems should be minimal – ideally zero
- Process changes to current workflows for both customer and supplier should be minimal – ideally zero
- Suppliers will not pay to send invoices. Cost should be minimal – ideally zero
Fortunately UBL is designed from scratch to plug into the back end of existing electronic systems dealing with the procurement cycle.
Example – Tradeshift
Tradeshift provides connectors that allows software providers (e.g. SAP, Peoplesoft, Intuit) to develop direct interfaces into their software that allow both importing and exporting of UBL e-invoices into their system. Providing this functionality can be basically invisible to the user of these system, hence, with minimal software changes, there appears to be no change to the current workflows for the users of the system. As an example, Intuit is proceeding with giving their 5 million+ users a backend interface to the Tradeshift business platform.
The value of this infrastructure is proportional to the total number of users. The more customers a supplier can reach, and the more suppliers a customer can reach, the more valuable the system becomes.
Tradeshift experience to date demonstrates a number of benefits for the small to medium size corporation. The following are some of the features that have been implemented on the Tradeshift platform with costs ranging from free (for e-invoicing) to fees for higher level functionality typically required by customers dealing with huge numbers of invoices.
- All e-invoicing is free for organizations of any size.
- Sending an invoice to a customer who is not on the infrastructure defaults to an email with a PDF attached. The key advantage here for the customer is that all invoices are then delivered in a standard layout.
- Social media functionality is built into the business platform allowing supplier and customer to carry out dialog around a single business document such as an invoice, credit memo, etc.
- Scanning/OCR functionality is available at no cost to the supplier – but the supplier, not the customer is responsible for quality control and error correction, prior to sending the UBL invoice
- Dynamic Discounting. A supplier can arrange with a customer to provide a % discount on an invoice, in exchange for immediate payment. Suppliers can improve their cash flow situation, while providing cash benefits for their customers.
- UBL is based on XML, and hence has a solid technical foundation. In particular, each UBL document is formally defined with a standard schema expressed in XSD (XML Schema Definition). This allows automatic validity checking using standard XML Processors on documents received.
- Since a UBL document is an XML document, standard XSLT and XSL-FO can be used to transform documents into any required form and produce paginated versions of the information.
- Code lists and Genericode. A supplier might want to enforce constraints on possible values for information entities. For example, they may want to check that the part number in these documents are valid codes from their parts catalog. Code lists can be controlled locally, and validated directly through a second stage of document validation.
- Apps Store. End users can use the Tradeshift API to implement new functionality which can be made available to other users.
- Master Vendor List. In many jurisdictions, it is mandatory to ensure your organization has an up to date master list of all their customers/suppliers. Typically this involves a lot of phoning and email to validate that the information on hand is correct and up to date. Since each tenant on the platform is responsible for maintaining their own information, this can be treated as a federated data base, the master list can be assembled by polling your list of suppliers/customers.
- Potential to expand the platform to handle all 65 document types defined in UBL 2.1.
- With a single standard exchange standard, a supplier needs only a single transform to convert their format to the standard, and a customer needs only a single transform to convert the standard to the needs of their proprietary application.
Thus, although a large customer might initially get a huge cost savings from the transition to e-invoicing, both customer and supplier can indeed benefit from an infrastructure supporting a single global standard, on interconnected exchange platforms.
Reference:
- OASIS (Organization for the Advancement of Structured Information Standards) is a non-profit consortium that drives the development, convergence and adoption of open standards for the global information society.
- OASIS UBL is an internationally-standardized specification for a suite of common business documents (invoices, purchase orders, waybills, etc.) and a concrete XML syntax (using XSD or RNC) for expressing those documents in a machine-readable format. It is flexible enough to include your own business objects and XML syntax as extensions. It is structured in such a way that you can make your own business documents utilizing a common library of business objects.
- More on UBL, e-invoicing and code lists:
- IBM developerWorks – Introduction to UBL
- What can we learn about e-invoicing from the telegraph?
- goUBL.com – a business ecosystem promoting the use of UBL in North America
