Auto-reconciliation - the killer app - go for it!

["Todd Boyle" <tboyle@rosehill.net>]

Businesses would derive great value from ebXML if it enabled
systems which automatically identify differences between their
accounting detail and banks, customers, and vendors.  

There are two broad choices: systems where you send a CC: of each
transaction for reference, but continue with redundant tables in 
each trading partner, and, systems intended to replace those 
redundant local tables with centrally stored tables.  Internet enables 
a real breakthru on this problem, in either case.  Your system
should be designed to deliver incremental benefits immediately to
trading partners who implement it, without requiring an impossible 
leap to universal adoption.

Business transactions are always owned by two parties.  They should be 
stored in encrypted rows within a database on secure hosts on the 
internet, visible to the two parties to the transaction.  Accounting 
systems could continue to maintain detail, or they could consist 
only 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 will achieve billions in cost savings, 
surrendering nothing in privacy.

Here is a conceptual approach you might find useful. 

You need functionality that enables unrelated companies to form shared 
accounting entries.  Let's call this a "Public Transaction 
Repository".  The PTR server manages two tables to provide an 
"Offer/Acceptance" process: open items, and completed transaction
or "PTR" table.

Offers received from users in valid ebXML are filed in the Offers 
table,  and copies are simply forwarded to recipients. 

If the recipient agrees, they simply fill in and sign their fields of 
the row, and re-submit the transaction.  The server validates  these 
"acceptance" messages, and stores the resulting "Contracts" in the 
permanent PTR table with encrypted, unforgeable timestamps.   

The PTR table is almost a read-only table. It provides a true, 
unforgeable record of a variety of reciprocal relationships such as 
Payor/Recipient, Accounts Receivable/Accounts Payable, and so forth, 
described in its XML field and limited only by the users' imagination.

For example, the PTR would enable wholesale, ubiquitous supply chain.

By maintaining indexes, the PTR would respond to queries. The user 
could obtain sets of rows necessary for reports such as aged 
receivables/payables by customer or vendor, or cash balances, etc. 
which are automatically reconciled with  the records of their trading 
partners.   

Here is an open source discussion and project outline if interested.
http://www.gldialtone.com/ptr.htm

Here is why you must do something about the redundancy mess.
http://www.gldialtone.com/endredundancy.htm

If you're going to have this big, fancy Registry /repository scheme, 
why not enable it to do something *really* useful, at least 
on an optional basis.


* Todd F. Boyle CPA    http://www.GLDialtone.com/
* 9745-128th Av NE, Kirkland WA 98033       (425) 827-3107