Ten years ago I was promoting a mechanism of transmitting standard invoices. I had realized that having a standard for invoices would enable more efficient business transactions much like SMTP has enabled global communication. Despite there being various attempts at such standards we have not seen widespread adoption in the banking and supplier community. The failure of standardization is exemplified in the following video which ironically shows how open source can mitigate the issue through products like Mule.

So what is the vision for standard business documents? Imagine the day when your electricity supplier, phone provider and pay television company all gave you the option of sending their invoices directly to your bank. Then, when you log on to you online bank service you could view the invoices and choose which ones to pay, and when.

Rather than direct debit, where organisations simply take money from your account without express permission you now have control over payment timing. All the invoices are kept online in one place. Once the invoice is paid it is linked to the payment record so that at any time you can go back and view all the details of the invoice related to the payment.

Of course a bank will not keep your data online indefinitely, so you will be able to download your transactions. The related invoices will be provided with the transactions, which will allow budgeting applications to be far more useful, in that they will be able to break up single transactions into multiple classes.

In fact you could take this one step further, and have credit card and eftpos transactions transmit the details of a transaction, including the individual products purchased to the bank. Imagine the ability to get detailed electronic records of your grocery shopping.

Wouldn't it be great...

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.

The IDTrans project primary goal was 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.

What went wrong?

IDTrans was established ten years ago as a one man project. I attempted to work with various accounting system companies, but did not receive any financial support. I committed one day a week to this effort, primarily to the development of the software. This included a client application for creating invoices, and a server application to handle key storage.

The key store actually was an early example of a distributed database similar to the databases now used by Google. It was a distributed database that synchronizes data across geographically disparate data centres. Unlike SSL certificates there was no central authority, but rather depends on a trust network.

The project was naive in the sense that I believed that by writing open source software I would be able to encourage organic adoption. I depended on accounting system companies adopting it for altruistic reasons rather than good business reasons. I now understand that I did a few things wrong.

My primary focus should have been on development of standards and protocols needed to support the system. While an example open source implementation might be useful, I made the mistake of creating a application that was tightly coupled with Windows and a specific user interface.

The producers of invoices, such as various service providers, will not be using such an application. They will want descriptions of the standards. If they did want an application it would look more like a integration engine that would allow them to connect their existing systems to a system that would produce the electronic documents. Another advantage would have been to provide translations from other common EDI documents to the new format.

I also approached the wrong organisations. The people I should have approached are those who would benefit most; those creating the invoices. The reality is that large companies tend to produce the invoices, and consumers tend to receive them. The real benefit of electronic invoices for companies will be better cash flow, as invoices automatically loaded into banking systems will enable payments to be made easier.

I might have also approached the banks who would have been able to provide a additional service which would differentiate them from the competition. Ultimately of course I would see most banks adopting these standards and providing services to their customers.

Future of Business Documents

We have at least seen the development of some sensible standard formats for business documents in the form of "Universal Business Language 2", or UBL2. This is a standard on which we can begin to build the kinds of system envisioned above.

I believe that the adoption of these standards will need to be driven by the suppliers. They will see that in providing billing information in electronic format means customers pay more promptly, and thus benefit their cash flow. Customers benefit by having invoices linked to their bank transactions. Banks that implement services to enable this interaction will benefit from the competitive advantage it brings.