End data duplication

EXECUTIVE SUMMARY: All of today's accounting and business systems are based on duplication of balance and transaction information from the viewpoint of each participant, maintained in every business location, within private accounting systems. These are inherently expensive to update and maintain.  Internet enables a completely new and better approach.   

The question is whether to improve the communication between accounting systems to keep their redundant data in agreement, or eliminate certain aspects of the duplication by using a master record in a shared location. 

Business transactions are always owned by two parties.  Either party may store these data in encrypted rows within a database on secure hosts on the internet, visible to the two parties to the transaction.   Accounting systems should consist primarily of indexes or pointers to all the encrypted rows we own, on various hosts, and the encryption keys to read them. The elimination of data duplication would achieve billions in cost savings, surrendering nothing in privacy.


The internet economy being designed and built today is based on redundant storage of data in multiple locations. Web developers are needlessly re-creating the same accounting problems as LAN-bound systems, and paper systems before them.

The availability of ubiquitous networking enables a fresh look at the designs underlying all accounting, sales, and settlement systems in use today.

Start with the basics: all businesses (and consumers) need the following obvious capabilities;

  • to send and receive payments over the internet,
  • to send, and receive, orders for products and services,  and,
  • to send and receive invoices.

Solutions are emerging for all of these, but there is no coherent, overall integration to get the bookkeeping done:

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

The common belief, and knee-jerk reaction, among e-commerce developers is that a nearly-utopian business environment will happen soon, as XML is widely adopted, and standards emerge:

  • standard XML formats for invoices, orders and payments,
  • widely accepted protocols for computers to link and process these files, and
  • 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

  • customer/vendor IDs,
  • product IDs,
  • namespaces, industry markets, market segments, etc.

For example, what's the use of an invoice received thru the internet, having perfectly brilliant XML formatting, if the product IDs are not the same as my self-generated inventory IDs and vendor IDs?

Today's vertical portals and lock-in vendors are not exactly working overtime to fix these problems. Instead, they are building "communities" - with themselves as rent collectors. But eventually, horizontal integration will fix this problem. For five years we'll be mapping our codes against master codes, then we will use the same native codes.

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 data architecture we had in EDI, LANs, and manually before that.

That's sad, and unnecessary.

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 securely on the internet, where those two parties can always reach it.

For those transactions, both 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 replicated data locally, for faster reporting,
  • Perhaps with additional value-added information, locally,
  • 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.

Maintaining double entry accounting in both buyer and seller locations is a redundant data structure, if viewed globally. 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,  that's octuple entry. For a graphic tutorial of this, see http://www.gldialtone.com/exploration.htm

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.

Webledgers deliver their magical benefit of self-reconciliation, linearly, with each new use-- they don't require an impossible leap to universal adoption, to begin yielding benefits, especially within  existing trading relationships such as 

  • internet marketplaces
  • portals and purchasing dashboards and aggregation models
  • supply chain

Webledger architecture can be implemented incrementally, running alongside existing accounting software. Some approaches to "merging" multiple transaction sets are

  • Tightly coupled interfaces DCOM, CORBA, or RMI (including database replication)
  • Loosely coupled document interfaces such as XML and EDI, and
  • Accounting consolidation models, e.g. summary journal entries

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. E-commerce designers are only beginning an integration journey which will include many challenges in fractional shares, eliminations, and reconciliations of all kinds of intercompany balances.

Sooner or later, all these systems will come home to daddy: consolidation accounting.  Subledgers will consolidate into the root ledger of the enterprise.

Webledger architectures based on single-entry hosted transaction tables will 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.

Let's build something worthwhile. Let's fix the problem, this time around.

Here are some architecture ideas to play with, for moving the G/Ls and transaction journals to shared hosts on internet. A shared transaction repository and some simple choreography, http://www.GLDialtone.com/STR.htm
http://www.GLDialtone.com/PTRForum.htm

It is my belief that a public transaction repository could also be built, today, running wholly on the basis of existing XML schema, with the context, negotiation, and choreography of eCo framework or draft ebXML registry/repository models.

* Todd F. Boyle CPA http://www.GLDialtone.com/
* tboyle@rosehill.net Kirkland WA(425) 827-3107
* XML accounting, Webledgers, ASPs, GL dialtone, whatever it takes