UBL: Key features of the design

February 2, 2016 Jon Bosak


This is the third in a series of articles by Jon Bosak, a member of the Tradeshift Technical Advisory Board, reviewing the newly published International Standard ISO/IEC 19845, also known as the Universal Business Language (UBL). UBL is the standard data format used by Tradeshift.

In previous articles in this series (here) I gave a brief overview of UBL’s development and a quick guided tour of the release package. In this installment, I’d like to point out some key features of its design.

By far the most important thing to know about UBL’s design is that every one of the 65 XML document schemas defined by the standard is assembled from a single library of reusable XML components. (If you have the release package in front of you, this component library can be found in the files linked from Section 3.2.1 of the UBL specification.) This library-based design has a couple of profound practical implications.

First, it means that common data structures such as Address and Line Item are implemented with exactly the same XML structures in every document type that uses them. The implications of this for code reuse (and by extension, the cost of processing software) should be obvious. Less obvious, but equally important, is the fact that complex documents such as Order that are received early in a transactional sequence can easily be “flipped” to generate corresponding documents such as Invoice later in the sequence, since much of the original document can be reused in the subsequent ones.

A less technical but still important consequence of the use of common XML data structures across the entire set of schemas is the reduction in training required to understand the format; once you’re familiar with Address or Party, you know it across all the documents in which these basic data structures are found. Ease of training is one of the most overlooked but essential factors in the successful adoption of a data format.

Another important design feature of UBL is its thoroughgoing document orientation. UBL document types have been very deliberately designed as supersets of traditional paper documents. That is, they provide much richer data structures than traditional paper documents, but it is transparently easy to map paper documents into them, and equally easy to print out paper versions of the electronic ones (following, for example, standard representations such as the UN Layout Key). In this regard, UBL differs radically from the “application-to-application” or dedicated API approach of some other transactional data formats that are oriented more toward machine capabilities than human capabilities.

UBL’s document orientation was necessitated by the requirement to fit seamlessly into existing paper-based business practices so that real-world business partners could easily be onboarded into electronic supply chains following existing patterns of business behaviour. For example, it is commonly the case that small suppliers must initially be brought into electronic invoicing by scanning paper invoices and using OCR conversion to produce an electronic deliverable. Conversely, it is also a common real-world requirement to convert invoices generated by ERP systems into PDF versions suitable for archiving by government agencies.

UBL is XML, so like all XML, it’s just text, in this case very straightforwardly and verbosely labeled text that uses terms that are familiar to any business analyst and easily interpreted in legal proceedings. As an International Standard, UBL truly is “disruptive” to current proprietary systems, but it is minimally disruptive to existing social, legal, auditing, and record-keeping practices.

Furthermore, the open, human-oriented quality of UBL makes it usable at very different levels of technical capability. In the extreme case, a UBL Invoice written by hand in a text editor (like many of the example document instances included in the UBL distribution) could be consumed by the most sophisticated ERP system without the recipient even being aware of how the Invoice originated. This example is unrealistic, but there is in fact at least one existing initiative sponsored by a third-world government that has developed and implemented a system in which small farmers use Excel macros to generate UBL Invoices to a large supermarket chain. Purchase orders and shipping notices could easily be generated the same way.

The document orientation of UBL also makes trading systems based on it more resilient, capable of functioning well at different levels of connectivity. For example, while currently emerging models of UBL use are either high-speed automated exchanges between data centers or portal-based interactions with a provider of services such as Tradeshift, UBL-based transactions can take place using modes of transmission as primitive as FTP or even store-and-forward email. Thus, systems built around a document-oriented syntax like UBL can continue to function in the face of service interruptions that would make synchronous data exchange impossible.

This resilience does not come at the cost of functionality, however. One reason that UBL interfaces easily with existing ERP systems is that it began as the union set of their capabilities. After 13 years of continuous use, development, and refinement, UBL is second to none in its ability to support real-world business requirements.

Another critically important aspect of UBL design is its support for customization to meet the needs of individual organizations while maintaining complete interoperability within the standard framework. To suit the requirements of specific trading relationships, data structures of arbitrary complexity can be added (by mutual agreement) to UBL documents without breaking XML validation against the standard schemas. This customization capability is detailed in a separate Committee Specification linked from Section A.5 of the standard.

UBL has also finally solved the related problem of code list management. A full set of standard code lists is included in the release package, and they are accompanied by a powerful verification methodology that allows virtually unlimited code list customization without breaking standardization. This approach also allows different versions of the same code list to be used in different document contexts and can be extended to offload a large proportion of input filtering from the back-end business application to a simpler input processing area. Details can be found in Appendix E of the standard.

In the first three articles in this series, I have briefly covered the history, scope, and key features of UBL. In the final instalment, I’ll look at some wider implications of this new standard for the future of electronic commerce.

Related reading: 

Part IV