Wouldn't it be great...

The following is the introduction I wrote to the Internet Document Transfer project I published online in June 2001.

Wouldn't it be great if you could receive your phone bill, electricity bill, bank statement, and any other kind of invoice or statement, by email. Wouldn't it be great if once you receive your invoice you could transfer it to your accounting system.

Wouldn't it be great if you could send your customers your invoice, and they could pay it electronically once they receive it. I see a future where most paper documentation is replaced by Internet Standard Documents, and we can all send business documents as easily as we do with email today.

With the rise of the Internet email has now become a required part of business. A vast majority of businesses, and a huge number of consumers have access to email and the Internet. What is surprising is that despite this revolution in communication a vast majority of companies still send physical invoices and bills to each other and to their customers.

This projects primary goal is to introduce a method of transmitting business documents between different organizations without a requirement to coordinate the format of documents prior to transmission. In other words, you can send an invoice without the worry of the recipient not being able to import the invoice.

Not only did I write about the possibility of electronic invoicing, but I developed software to prove the implementations. In 2001 the technology to implement electronic invoices already existed.

My purpose in this submission is to discuss the non technical factors which have prevented widespread adoption of electronic business documents and their flow on benefits. I will also be addressing the question of governance.

A Cautionary Tale

By establishing a proof of concept and promoting electronic invoicing and business documents I believed I would be able to secure the funding required from accounting system providers to continue implementation and promotion electronic invoices. In order to achieve this I committed a day a week working on an open source implementation in 2001. The technical aspects of the project were achieved, with a proof of concept end user application and the secure key servers required to mediate secure communication completed.

Over a six month period I was able to meet with a number of accounting software vendors to pitch the project. While one company extended limited support no organisation was willing to commit funds or resources towards the continuation of the project.

The benefits are clear to users of this technology but there are barriers within the software vendors space which were not at all technological. In addition another project was to start, ebXML, with the express aim of developing electronic invoicing and business document transfer. Since this project ended I have had time to reflect on what went wrong.

Vendors do not like Interoperability

While open standard protocols like TCP/IP, HTTP, SMTP and POP totally changed the world in terms of being able to connect computers prior to this software vendors simply would not collaborate to develop a common protocol. Each networking vendor had it’s own products and the commercial world meant they were competing with one another. This was far from ideal for customers.

Only after open protocols and the rise of the Internet did software providers like Microsoft embraced these open protocols. But even then Microsoft attempted to embrace, extend and extinguish the open protocols, resulting in the Browser Wars.

From 2005 I was involved with efforts to challenge Microsoft’s patent applications for using XML for word processing files. The purpose of XML was to enable transfer of structured data.

In order to shut down interoperability Microsoft attempted to patent how they used XML to store word processing documents. This would make it impossible for other software companies to interoperate with Microsoft XML documents. Interoperability is actually bad for software vendors who want to keep their customers locked into their product.

The same forces which conspire to prevent interoperation in networking and word processing were also at work in the accounting software field. By supporting proprietary formats a software provider can leverage their customers who wish to interoperate into applying pressure on their suppliers and customers to adopt their technology.

This was one of the main reasons I met resistance with software vendors. While there were clear benefits to customers, businesses and government in having a single universal standard for business documents the software vendors had little reason to give it to them and a big reason not to.

The mess of different communication mechanisms means that unlike SMTP where people can sent messages around the world to any recipient no similar system has been adopted. Major integration system companies make a good deal of revenue from this situation.

Currently Xero offers an easy to use system where you can directly send invoices to your customers via Xero if they also use Xero. Xero does not support open standards based invoices such as ebXML. While financial self interest is not the only barrier to software vendors adopting open standards for business documents it is a major influence.

The Tragedy of ebXML and UBL

My efforts on Internet Document Transfer ended once I realised there was an international standards effort being made with ebXML and UBL. My assumption was that the standard would be published and then adopted by accounting system vendors universally. As a strong supporter of open standards I strongly supported this effort in principle. I assumed that it would only be a matter of a year or two before we would see widespread adoption.

Almost twenty years later and we have not seen adoption. Invoices are usually sent to consumers in PDF format, forcing them to manually enter the invoice details into internet banking systems. So why did ebXML and UBL fail to achieve adoption?

We have already discussed the problem of commercial incentives for software vendors above, but this was far from the only reason. The other major contributing factor was complexity resulting from trying to address use cases being driven by large corporations.

The ebXML and UBL standard came out of a process dominated by corporations. The focus was on replacing the existing EDIFACT standards and catering to use cases specified by corporations with a focus on business to business communications rather than business to consumer.

The ebXML and UBL standard came out of a process dominated by corporations. The focus was on replacing the existing EDIFACT standards and catering to use cases specified by corporations with a focus on business to business communications rather than business to consumer. They imagined that solutions would involve a complex chain of negotiation and system setup for each user.

At the time my own approach was to develop a very simple schema to handle the most common use cases. My design principle was that any software implementing the standard would at least be able to understand the basic information in the invoice. Each company could extend the invoice schema to include more information if required by partners, but such information would not be included in the standard invoice schema.

This minimalist approach was not taken by the OASIS standards group, and so we ended up with schema which were bloated and difficult to implement. Invoice document format was only the start however. In order to transfer invoices or other business documents requires security, including signing and encryption. The ebXML system addressed the larger issue of discovery by introducing a system for discovery.

Again the focus for the solution was focused on large corporations rather than consumers or small businesses without committed IT human resources. The needs of large businesses involved larger issues around process management.

In summary, the complexity of message formats and transmission systems made implementation expensive. Rather than being adopted universally it was seen as just another format for integration specialists to connect to. Those required to use it in order to communicate with large corporations who had adopted it were usually forced to purchase integration software.

What we did not see from these standards was a focus on delivering a system which would be similar to email, where the standard would be pervasive and broadly implemented. While it would be good for EDI implementation specialists it would do nothing to actually deliver on the real vision.

Where to now?

The discussion document published by NZBN has a focus on proposing the establishment of long-term operational governance for electronic invoicing. The real question here is how should Australia and New Zealand go about establishing a robust standard for electronic documents?

The answer I believe is to give this governance responsibility to an existing organisation that has a long history of promoting open standards and involvement with electronic communication. My concern is that establishing a group of vendors and large businesses with a motive to profit from the standard will only end up with the same outcome as ebXML, a system used only by a minority of corporations.

The logical organisation to front this effort in New Zealand would be InternetNZ.

They have a long history of dealing with communication related open standards. They have access to an existing network of technical professionals in this field. They are committed to an open Internet. They are not owned or controlled by any commercial software vendor and would represent not only the interests of organisations but of the public at large. Putting governance in the hands of an organisation that has a profit motive and without any representation for consumers in New Zealand would be a mistake.