Piecemeal solutions are emerging but there is no coherent, overall integration to get the bookkeeping done:

1. update our accounts receivable/payable for a sale or payment,
2. update our inventory counts for particular products,
3. update our book balances of cash in bank, etc.

The common belief and knee-jerk response in the ASP marketplace, is that this utopian business environment will happen soon, as XML is widely adopted, and standards emerge:

1. standard formats for invoices, orders and payments,
2. widely accepted protocols for computers to link and process these files, and
3. encryption and legal infrastructure making them reliable and nonrepudiable, etc.

The next morning after these standards exist, the market will wake up with a hangover, and realize we need a lot of global directories or cross-references, for

1. customer/vendor IDs,
2. product IDs, and
3. namespaces and market registries, etc.

To illustrate: what's the use of an invoice received through the Internet, having perfectly brilliant XML formatting, if the product IDs are not the same as my self-generated inventory IDs? And who is this vendor ID?

So they will fix that problem.

But ten years from now, after we get all this apparatus working it will still require just as much complicated manual bookkeeping to maintain, because everything being designed today based on multiple, redundant data stores. We are just re-creating in e-commerce, the same work processes we did manually.

Fact is, there are two owners to every transaction in the universe: the buyer and seller. The master, and only, record of that transaction should be stored in rows within a database on a secure host on the internet, visible to those two parties alone. Encrypted so that they can read it anytime.

Similarly, for every transaction, the parties have also agreed on the customerID, vendorID, and product IDs. Accordingly, the record of the customerID, vendorID, and product IDs they agreed upon at time of transaction, also belongs in encrypted rows, on the internet.

Accounting systems should consist only of indexes or pointers to all the encrypted rows we own, on diverse remote hosts and public transaction repositories and WebLedger sites on the internet, and the encryption keys to read them.

Yes, just indexes.

• Perhaps with additional value-added information, locally,
• Perhaps with replicated data locally, for faster reporting,
• Perhaps even with traditional paper hardcopies.

But the true, authentic data would be on the hosts.

This would not surrender one bit of privacy, but it would achieve a quantum leap in efficiency. The maintaining of double entry accounting in both buyer and seller locations is a redundant data structure. The mirror image of every sale recorded into receivables by a seller, is also recorded as a purchase, into accounts payable by a buyer.

That's quadruple entry. Since every transaction in the developed world also causes quadruple entries when it clears thru a bank eventually, that's octuple entry.

Whenever data is stored in more than one place, these consequences always result:

• The redundant data stores attract updates from different classes of users
• The data stores are updated at different times, and in different levels of aggregation.
• Neither data store is ever correct or timely.
• Time is wasted confirming and reconciling one against the other
• Costs arise due to business errors based on wrong information (overdrafts, credit/collection errors, etc.)
• Systems are developed to address the problems, by automating the checking and comparison of the two lists, or to post all changes to both lists, etc.
• Those secondary systems introduce rigidity and problems throughout the software environment.

These costs and consequences are geometric in nature, and are the root of our current employment of tens of millions of clerical workers, each operating completely isolated accounting systems. A WebLedger architecture can be implemented incrementally, running alongside existing software. It delivers its magical benefit of self-reconciliation, linearly, with each new use.

The consolidation of sub-ledgers of departments and subsidiaries is a conceptual model and methodology which is well-understood by millions of accountants and accounting software developers. Financial consolidation is a comprehensive, robust methodology that provides ready-made solutions for merging multiple transaction sets of arbitrary complexity.

Accordingly, WebLedger architectures based on single-entry hosted transaction tables would plug and play with existing LAN-bound software, if designed from the outset to deliver output in consolidation structures. Several families of XML schema already exist for General Ledger transactions and trial balances.

This article was first published December 1999 as a posting to the ASPnews.com discussion board. Other postings by Todd include:

• XML Schema for General Ledger (Jan 7th)
• Rolling thunder; living in a webledger universe (Jan 7th)
• Evaluating WebLedger ASPs solutions (Dec 4th)
• Accounting ASPs - key factors (Nov 9th)