This content originally appeared on DEV Community and was authored by Peter Harrison

Twenty Five Years ago I committed my own time toward delivering a method for transferring invoices and other business documents in a digital machine readable format. It would make commerce far easier and eliminate the need for complex manual processes to import and process invoices. With the early adoption of email, and the development of XML for digital documents, it was surely a simple matter of bringing these together with a common standard to deliver real systemic advantage.

Alas this would not be. Twenty five years later I am being paid to develop a solution which uses Optical Character Recognition and Artificial Intelligence to extract a machine readable standard invoice format. While I am glad for the income it is deeply ironic. We have in this time been able to develop artificial intelligence, but failed to adopt a consistent standard for digital business documents.

Developer aims to plug e-biz gap: Solution to be distributed free

https://web.archive.org/web/20010203201400/http://www.idg.net.nz/webhome.nsf/UNID/528640C4B77A00D0CC2569A00008D788!opendocument

Computerworld Friday, 24 November 2000. by Mark Broatch

An Auckland developer is promising to plug a crucial gap in e-commerce – the secure and seamless exchange of business documents.
The lack of standards for business-to-business communication between disparate accounting systems is crippling the take-off of e-commerce, says Peter Harrison, a security and encryption specialist.

Harrison, who works four days a week for local and US encryption company RPK, wants to give the business world a free, secure document exchange system that lets accounting systems communicate with each other. The project, dubbed Devcentre, will be based on open source software and the markup language of the moment, XML.

Harrison's not asking much in return. He wants to be paid a senior developer's salary for a year to finish the project. And he wouldn't object to having a few staff if the project takes off.

His interest has more a missionary zeal. "The problem is that most companies want to make serious amounts of money from their solutions. They are also aiming at large business, not small business. Solutions tend to be tens of thousands of dollars, and do not work with competitors' systems."

Wouldn't it be great...

The following was written in 2000, as part of the Internet Document Transfer project.
https://web.archive.org/web/20030204102103/http://www.devcentre.org/idtrans/index.htm

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.

Project Objectives

The DevCentre Project has some very specific objectives:

• Development of functionality to transmit an receive business documents.
• Development of security and authentication functionality of business documents.
• Development of a free public key infrastructure.
• Promote the use of the software in ALL accounting systems.

The project as a whole has the following principles:

• All source code in the project is freely available.
• All source code will be free of paid licence or patents.
• All major programming languages will be supported. The project is vendor impartial.

A Business Case

This project could have a far reaching positive effect on New Zealand business. It could enable a revolution in business communication similar to the effect email has had on personal communications. I have listed below some of the advantages this new technology will bring to companies.

Advantages for Business

• Reduces Stationary and Postage costs, as documents can be sent via Internet.
• Reduces cost of retyping data received in paper format from suppliers and customers.
• Reduces Customer Support costs by increasing accuracy of data in the transfer process.
• Reduces Customer Support costs by allowing customers to enquire into accounts electronically.
• Improves customer relations due to increases efficiency and information to the customer.
• Improves Debt Collection due to increased efficiency of document handling.

Advantages for Internet Service Providers

• Increases the number of business users using the Internet in general.
• Possibility of providing business services related to transfer of business documents.

Advantages for Accounting System Companies

• Adds Additional Functionality without the cost of developing the solution in house.
• Increases sales due to an increased use of accounting systems in general when standard business document transfers are common.
• No ongoing maintenance costs for the additional functionality.
• Increases the potential sale value of your product.
• Potential to provide business services related to the transfer of business documents.

Advantages for Accountants

• Reduces cost of retyping of paper documents.
• Reduces cost of communication between you and your clients.
• Reduces the number of different computer file formats required to support your clients.

Advantages for Banks

• Potential to earn revenue from payments conducted by the software.
• Reduces the number of cheque and cash transactions, and therefore the costs associated with them.
• Provides incentive to customers with the software to use Bank Accounts with access via the Standard.

Advantages for Government Departments

• Will make filing documents much easier.
• Will reduce cost of typing data.
• Will reduce the number of errors due to mistyping.
• Will decrease the processing time for incoming documents.
• Will reduce the number of inquiries and complaints due to typing errors.

Open Standards

Email is a great success. By using standard protocols, and connected in a standard way to a huge network, we are able to transfer information all over the world between organizations and computer systems that are very different in culture, location, and size. The Internet email system is based on simple, standard protocols. Email is a great model for developing further protocols for communication.

The one primary problem preventing communication of the basic business documents today is lack of a standard format for electronic data. Some standards, such as XML are being developed which may aid in developing some standard for transfer of invoices, but currently no specific standard has been implemented across a wide range of systems for basic business documents. I believe there needs to be an initiative to develop standard business document formats, based on XML. There should be standards for Invoices, Statements, and Orders etc.

Several projects are currently developing such standards, and it is my intention to follow and implement the standards as far as practical. There is a list of other B2B XML standards projects on my B2B page.

authors note: As of 2025 no digital invoice format has seen broad adoption. Neither have we seen the adoption of signed systems that would improve security and verify the sender of a document.

Real Working API

Just having a set of standards is not sufficient to ensure that the standards are used. We must seek to develop implementations of a Internet Document Transfer API which will be open source and available on all major platforms. The purpose of the API will be send and receive Internet Documents.

It will allow software developers to easily incorporate the Internet Documents standard directly into their software. In this way all major accounting software houses will easily be able to support the new standards.

The Internet Document Transfer API will also incorporate encryption and authentication, which will ensure that documents are secure in transit, and are properly authenticated. The public key cryptography system protecting the data will take advantage of a Internet Document Authentication Server.

Real Software

The Internet Documents Client will use the Internet Document Transfer API to provide an application for consumers and businesses. It will act as a client for sending and receiving orders, invoices and statements. It will also be a standard email client similar in functionality to Outlook Express. It will be a free product, and its purpose will be to get as many people, business and consumers alike, using the new Internet Document standards.

In addition to protecting Internet Documents with strong public key encryption, it will protect emails as well between two Internet Document Clients. The protection will be automatic, not requiring complex manual processes to maintain your private and public keys.

Security and Authentication

The Internet Document Authentication Server will be a server application which stores the Public Keys of individuals. It will be similar to Verisign, but instead of a single company being at the top of a 'trust tree', there will be a network of Authentication Servers. The Authentication Server Application will be open source, and be able to be run by anyone. Its purpose is to have a publicly available store of public keys which you can trust to be correct.

This will allow Internet Documents to be protected by strong encryption, and it will allow Internet Documents to be signed by the sender to ensure authenticity. It means you will not need to pay a company such as verisign in order to achieve this security.

authors note: While the implementations described above were developed they were never adopted. This included Java and Delphi implementations at the time. It included a public key repository so that it was possible to verify senders. As of 2025 there is no public infrastructure available for public crypto keys that would enable signing.

XML Document Schemas

It is clear that the Internet Documents will be XML. Currently there are a number of Business Document XML projects underway. My desire is to use industry standard XML schemas in order to maintain compatibility with existing implementations, and to ensure the widest possible utilization of this project.

XML Schema Projects

There are many projects developing XML schemas for everything under the sun. However, there are some front runners I believe which I have detailed in my Business to Business Resources.

In addition IDTrans has developed its own XML source code. This is aimed at working with XML with a lightweight code base, rather than the heavyweight approach of Document Object Models. To date this approach has worked very well, although it will need continued work. While initially only available for Delphi, the XML code will be ported to Java and C.

The Role of XML within IDTrans

All Internet Documents will be XML documents. Furthermore those documents will conform to standard definitions that will be incorporated into the software for invoices, statements, orders and other business documents.

There will be minimum requirements for various documents. For example, a invoice will need to contain the sender and recipient data. It will need to include a Invoice Number, and Invoice Date etc. Every invoice will have common features.

This will ensure that you do not need to obtain a schema from your recipient before you can send them a document. If you send an invoice you know the recipient will be able to parse the invoice.

Children Schemas

My plan is to incorporate inheritance into schemas.
For example, I will distribute a standard Invoice, Statement, Order etc. People will be able to 'inherit' from the standard Invoice to add properties of their own, without redefining the whole invoice schema. If you write in Delphi or Java you will already be familar with the concept.

The advantage of this is that you can send a invoice created from a special invoice schema (ie the schema adds properties to the invoice not normally present in the standard), and the receiver will still be able to make sense of the invoice. They have the option of downloading your inherited schema if they want to parse the additional fields, but they don't need to in order to find the basic invoice data.

Furthermore, all the standard documents would inherit from a single top level document - and you would have a naming convension for people to add their own schemas.ie,

org.devcentre.Document -> (Base Document for all Internet Documents)

org.devcentre.Invoice -> (Base Document for all Internet Invoices)

com.sun.Invoice -> (Specialized Sun version of the Invoice)

com.ibm.Invoice -> (Specialized IBM version of the Invoice, inherited from Sun)

In other words all schemas become public, and can be used to inherit from in order to create more specialized schemas. Inheritance is not supported by other projects that I am aware of. As a result of this the Schemas can become bloated, as the default schema needs to have fields to support all the fields that may be required. I will probably initially start with simple schemas, and have advanced inherited schemas support the eBIS-XML and ebXML stanadrds.

Encryption Algorithms

Over the last few months the project has developed an implementation of IDTrans which depends on two encryption algorithms. Those are Rijndael (AES) and RSA. We may add other algorithms as required, such as a signing algorithm.

The reason we currently use only two algorithms is simplicity. Adding further algorithms would make the system more complex, but not add anything to the security. Also included on this page is a Specification, now in draft number 2.

This provides more detail about the specific implementation being used. This page also provides information about other algorithms under consideration.

Why do we need encryption?

• Prevent unauthorized interception of business documents.
• Prevent unauthorized alterations to business documents.
• Provide a means to ensure business documents are geniune.

Requirements

• Since the project will be Open Source, ideally the Encryption Algorithms used should not be patented.
• There should be existing libraries for working with the Algorithms, ideally Open Source libraries for the supported languages (Delphi, C, C++, Java).
• They should be crypto-graphically well known and trusted.

The Trust Network - distribution of public keys

The Trust Network is an important part of the whole system. Its purpose is to store public keys so that they can be retrieved. The problem is that when you send an email to somebody, and if you are using public key crypto, you need to know their public key. Current client software requires you to obtain the public key by some means before encrypted communication can begin.

By having your Public Key stored on a server people can obtain your public key at any time. And because you can also interrogate your public key yourself at any time you can ensure the public key has not been replaced. Once someone has your public key it is stored on their machine, and verified against the public key server when used. This increases the chance that a man in the middle attack is detected.

An additional security feature may be signed keys. This is effectively a certificate. It means that the public key has been signed by the server as genuine. This means that any attempt to replace the key in transit will break the certificate.

Receiving Keys

The Server will receive keys by having the client connect to the server go through the following protocol :

• Client sends a Message with their public key and email address signed by their private key.
• Server confirms authenticity of public key by checking the signature. If authentic it will send a Confirm Message back to the client. It also sends a email message to the email address supplied informing the user that they have registered their public key.
• Client receives their email, and replies to the email to activiate the Public Key. If no response comes from the client the Server will not distribute the Public Key.

Obtaining / Verifying a Public Key

The Server will distribute a public key to any client which requests one using the following protocol: Client sends a message requesting the public key of a specific email address in the clear. This is not encrypted as there is no secret information to be protected. Server looks up email address and sends the Public Key signed by the Private Key of the owner of the Public Key. This protocol is the same weather requesting or verifying a Public Key.

The Trust Network

Public keys are used for both Encryption and Verification, so ensuring you have the correct public key is vitally important, otherwise your encrypted communications are vunrable, and you cannot be verify where messages come from.

The traditional way of ensuring distributing public keys was a trust tree, where some organization at the top of the tree signs certificates of organizations below. In turn those organizations might distribute certificates and so on down. The purpose of this is to provide some certainty that the public key you have obtained is really the public key of the intended receipient of a message, and not a spy in the middle.

The Trust Network is a set of Public Key Servers. Each server on the network has a full list of the other servers.When a new public key is received it sends the public key via secure channel to two servers on the list at random. These two servers will then periodically query the original server to ensure the Public Key has not been tampered with.

Should tampering be detected by a server, it will send out a message to all the servers on the server list to check the server under suspicion. Each server will then query the Public Keys it has stored against the suspect server.

Any Public Keys that have been tampered with will generate an additional message to the suspect server informing them of the mismatch, and what the correct key should be. If a server gets corrections from two servers for a Public Key it will change the Public Key stored to the one supplied, assuming the Public Keys from the other servers match.

If a suspect Public Key is not corrected even when these messages have been sent to a server, the entire server will be marked on the list as 'defective'. A new server will be chosen to host the keys that previously belonged to the defective server, and all Public Keys stored on other servers relating to the defective server will be transmitted to the new server. The new server will only accept Public Keys if it receives two copies from different servers.

The result of all this is that servers which have been hacked or modified in such a way to allow false Public Keys to be distributed will be discovered, and if the problem is not resolved, will be eliminated from the 'Trust Network'.

Lightweight Directory Access Protocol

The LightWeight Directory Access Protocol is already being used in a system much like that described above. In all probability we will end up using this protocol and the open source implementations of it to deliver Public Key Distribution. PGP uses LDAP to distribute keys. Like many of the other standards and protocols I have already found, I am investergating how this can be incorporated into the project.

authors note: This document refers to standards and technologies of the period. It was prior to Cloud technologies and the adoption of REST based web services using JSON. Use of XML and the security systems it used has waned as it was overty complex. Similarly attempts to create document standards were hijacked by large businesses who developed unweildy solutions not fit for general purpose use. This contributed to a tradegy of the commons where it was not in the interests of software providers to standardize on common formats. This led to a whole industry in the field of ‘integration’.

Summary

This brief discussion document is intended to provoke thought about how we can make the most of the Internet in business. By working together to create standards and Open Source tools based on those standards we can all integrate our financial systems better than ever before.

This document is simply a jumping off point. On this site you will find more detailed specifications and research. This includes Open Source resources which will make a major part of the project. Over the coming months you can also expect to see discussions, source code, and working product.

The goal we have set is not an easy one. We need help to achieve the goals. Our aim is to approach accounting system companies, banks, and other organizations who would benefit from this project in order to fund the project.

Fast Forward to 2025

I was recently engaged by a client to write a system that utilizes artificial intelligence systems to perform optical character recognition on PDF documents in order to extract the text, and then transform the information into a standard JSON format able to be ingested into their accounts payable systems.

We continue to lack a standard which New Zealand companies and organisations can use for business documents that would be universally accepted. We easily had the technology to achieve this twenty five years ago. Today we have developed amazing technology around artificial intelligence, but we have not standardized business documents.

This is certainly not the fault of any specific single entity, but rather a failure of governance at the highest levels. While I saw the need and had the technical skills to develop a solution more than twenty years ago what I didn’t have was the resourcing to promote it, nor the connections in Government to get a simple standard mandated.

This content originally appeared on DEV Community and was authored by Peter Harrison