Dennis Howlett recently blogged here on how some of the newer entrants to the industry are collaborating on a new, Simple Universal Business Language (SUBL), initiative to send and receive orders and invoices electronically between heterogeneous applications.

This sounds highly desirable and will undoubtedly save users time and improve the accuracy of entering transactions into software.

The thing is, like many of today’s new innovations it isn’t new at all… this particular idea has been around for ten years, yes that’s right ten years.

Back in 2000, a recognised industry body called Business Application Software Developers Association (BASDA) developed a similar, if not more refined, schema called eBIS-XML, in collaboration with their members, who comprise most of the business software vendors in the UK.

The eBIS-XML schema http://www.basda.org/ebis-xml-35485.htm was created to cover the spectrum of large systems as well as small ones, it can be very easily applied, BASDA provide a toolkit to aid vendors in development, and it has additional validation built in to check the message hasn’t been tampered with during transport.

As someone who implemented the schema into a range of software products during 2002, I found it very easy to understand and easy to work with. However, creating and parsing XML is the easy bit. What also needs to be considered is the reliability, or not, of the transport mechanism, i.e. most people use email, but we need to remember it’s not guaranteed delivery, or receipt, and can be inadvertently deleted.

You must also trap spam, you must support a moderation process allowing the user to decide what’s sent and received, for larger systems you must support complex reconciliation rules to pair up an invoice with an order and a payment, known as “three way invoice matching”, unique supplier/customer identification can pose a problem (e.g. supplier reference numbers and transaction reference numbers can differ from what you hold in the system), there are multi part orders and invoices to cater for, and you need to be able to make adjustments when part of an order is cancelled or if the payment doesn’t match the invoice.

In addition, in the UK there are also standards that need to be met to adhere to HMRC rules on electronic invoicing http://www.hmrc.gov.uk/vat/managing/charging/e-invoices.htm you can’t just send XML from one app to another and that’s it… the process needs to conform with audit standards just as a paper invoice does today.

Now, all of that shouldn’t frighten anyone off, because all of these problems have been solved, it’s all been done before.

At this point it’s fair to say that whilst a good number of businesses in the UK are using eBIS-XML to transfer documents electronically, even after 8 years it hasn’t become a defacto standard. Technically it’s a proven solution, so you might look elsewhere for other reasons… was the concept ahead of its time? Is it more attractive to larger business that process more transactions? Are other methods such as PDF used instead? Are people more confident to key transactions? Or did the industry fail to articulate the benefits to users?

What puzzles me is why another schema is being proposed when a perfectly good one already exists and is pervasive across most software vendors… I can only think that the new entrants probably weren’t around in 2000, or that the SUBL initiative is originating from outside of the UK and they don’t have knowledge of the BASDA schema.

Circling back to the original blog from Dennis, he comments:

I really don’t get why eBIS-XML is being avoided. I hear something about paying for the documentation (is that right?) but given the relative size of the market and numbers of customer, is that such a big deal? Alternatively, it can’t take that much pressure to get BASDA (or whomever is the copyright owner) to release eBIS-XML as a freely available standard… Bottom line – I don’t really get why you all are re-inventing the wheel?

I have to agree with Dennis here, and in the pursuit of creating an industry standard, I would ask the new entrants, would it not be better to join with the other BASDA members and build on what they have already produced… that way we all have a better chance of delivering a defacto standard for our customers and for our industry?