One of the biggest strengths of Tradeshift is our unique App Framework that grants developers access to our powerful REST API. It allows ourselves and 3rd party developers to extend Tradeshift in different areas without cluttering the user experience for everyone. For instance – not everyone has a need to send purchase orders or quotes or connect their accounting package. The App Framework has made Tradeshift an extensible platform by giving developers the possibility to produce “Embedded Apps” that appears in the Tradeshift web application and functions as a natural extension of the existing web interface.
But computing is about both programs and data, and our choice of XML data format for the Apps Framework explains a lot about both the functionality we give to developers and our whole philosophical outlook.
Rather than develop our own proprietary message formats for invoices and orders, we adopted a standard set of XML document schemas called The Universal Business Language, or UBL for short. UBL represents more than 13 years of development by hundreds of ebusiness experts and is maintained by OASIS, the same XML standards group that developed the Open Document Format (ODF). UBL is the first and only business language to be based entirely on the ebXML Core Components Technical Specification, a semantic definition methodology that was developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and standardized as ISO 15000-5.
When first released in 2004, UBL provided a set of just eight standard message types for basic electronic business, including Order and Invoice. Then some government agencies, mostly in Europe, realized that UBL is the answer for putting government procurement online. In the past seven years, government agencies have contributed dozens of other UBL document types for all the processes of tendering, quotation, buying, shipping, and invoicing. UBL 2.1, currently in public review, contains more than 60 standard XML document types and defines more than two thousand business information items.
We think our choice of a truly open data standard says a lot about our approach as a company. But it also has a number of practical consequences for Tradeshift App developers.
- The creation and maintenance of UBL in an open, accountable, vendor-neutral standards process levels the playing field for software companies and individual app developers alike.
- UBL is already required by law for public-sector invoicing in Denmark (2005), Italy (2007), Turkey (2010), and Peru (2010), and it is also legally approved for this purpose in Sweden and the Netherlands. Public-sector invoicing is creating a huge installed UBL user base that will continue to grow as more governments mandate its use.
- Meeting the eprocurement requirements of multiple governments means that the same data format we use for trading partners in Tradeshift will work equally well for public-sector invoicing. It also means that the complex requirements of European taxation schemes are already taken care of and won’t require difficult modifications later on. The same applies to downstream financial processing in the payment phase; the data structures needed by banks and other financial authorities to create the message formats used in their domains are already part of UBL.
Because UBL must interface governments with millions of suppliers from multiple industries, it already supports the essential requirements of many industry-specific data formats and can therefore be used to interchange transactional business documents among different industries.
Obviously we’re taking all of these inherent advantages into consideration as we build Tradeshift!
In addition, a couple of specific design features of UBL have important technical implications for app developers.
First, UBL is document-oriented. While the capabilities of UBL messages go far beyond paper documents, they have been designed to make conversion to and from paper as straightforward as possible. This facilitates the transition from paper to electronic transactions with a minimum of disruption to existing business, legal, and records management practices. For example, the document orientation makes it easy for Tradeshift to generate PDF versions of your invoices. It also makes the data format agnostic to platform or transport mechanism and enables a very wide range of synchronous and asynchronous input and output capabilities to accommodate an equally wide range of users.
Second, all UBL document schemas are based on a single library of reusable XML components. This approach avoids the uncoordinated design of different documents, which is a major defect of traditional EDI (X12 and EDIFACT) message sets and many earlier XML efforts. Common components such as Address and LineItem are identical across all documents in the UBL set. This means maximum reuse of program code across all the UBL document types—and it’s what makes it easy for us to generate an invoice from a purchase order.
Probably the best way to understand the impact of UBL—and why we chose it for Tradeshift—is to think of the role that HTML played in the evolution of the web. Our adoption of UBL means that Tradeshift plugs right into a growing open ecosystem of standards-based business applications. For example, the Tradeshift infrastructure is already configured to participate directly in two EU-funded procurement networks currently under construction. And the fact that UBL supports a set of capabilities that go far beyond ordering and invoicing means that we—and you—are already poised to expand into a wide range of future cloud-based electronic business processes in a way that integrates seamlessly with whatever we’re building now.
We think so highly of UBL that we’ve hired Jon Bosak, chair of the UBL Technical Committee, as Tradeshift’s Director of Standards. We are proud to sponsor his work in directing the completion of UBL 2.1. It’s work that the entire world of ecommerce will benefit from, not just Tradeshift—and what could better represent our corporate commitment to standards-based interoperability than that?