The Shared Transaction Repository (STR)  Accountant's explanation


Below is tutorial aimed at accountants and bookkeepers, showing how shared data on the Internet can improve accounting processes.   This is not an automatic reconciliation or replication scheme.   The STR is a true shared database.  It is a true shift from company-centric to a single, shared, network-centric storage and transaction execution.  


Debits equal Credits in my ledger.

  • CDEA -classic double entry accounting
  • benefits internal bookkeeping
  • administering external balances requires continual work.


Web applications - more of the same:

Debits equal Credits in my ledger.

  • more CDEA.
  • same benefits in internal bookkeeping
  • no benefits in administering external balances.



Future, abstract:

Debits equal Credits within each trade,  globally, among trading partners.

  • external balances are kept in balance
  • the root ledger of the enterprise is not defined or constrained (legacy system can continue.)

 (This model is nuts because the debits and credits that have floated up, are equal. See the next frame.)


Single record of each trade, meeting the needs of both trading partners symmetrically

  • single entry accounting
  • works fine for consumers.
  • general ledger is not provided yet.
  • but we have accomplished a good thing: we have converged the AR and AP amount and date, and  description.



Future, STR model:

  • ASPs and BSPs begin to provide persistent storage
  • You might call this NSEA - Network single entry accounting.  Only records of transaction events  are stored.
  • general ledgers may be maintained locally or on hosts or ASPs.
  • combining of general ledgers follows conventional consolidation methods. 
  • general ledgers may contain replicas of STR entries, or just pointers.



Future Scenario:
triple entry accounting

  • ASPs and BSPs provide persistent STR structures
  • Triple entry accounting. Records of transaction events  are stored, with private stub space, for party's use
  • The host is your general ledger, or sub-ledger.
  • Your root ledger can contain replicas of every transaction, or summary entries with pointers and indexes. 


Note that in network-centric accounting, 

  "The objective of this architecture is to achieve the simplest possible scheme for shared storage of transactions that eliminates redundant storage, and eliminates any possibility of inconsistency between the parties' records. "
"Yeah right.   I am going to store my general ledger on your computer, on the internet? "  
  "No.  You are going to store only the date, amount,  and description of your transaction events on the internet, encrypted so that only you and your trading partner can ever read them. "
"Why that's ridiculous.  Why should I share any of my data with my customer or supplier? "  
  "You already do.  A snapshot of whatever you bought or sold, or agreed upon, will be stored.  Your customer or supplier already stores the exact same information, internally.  Whatever you agreed upon is exactly the same information. "

Alternatives to consider:

A shared transaction repository could be achieved using any high-end multi-company accounting system.   You could record classic, double-entry accounting (CDEA) transactions  within such a ledger for each party, just as intercompany transactions have been formed within controlled groups, for the last 100 years.  Consider this example where Subsidiary A pays an expense for Subsidiary B thru "the intercompany account".

 General Ledger - Subsidiary A                            July 2000
 JournalNo.  Date    LineNo.   Account                       Amount

   4441   22/7/2000    531     10100  Cash in Bank        Cr  -400
   4441   22/7/2000    532     19000  Interco Receivable  Dr   400
 General Ledger - Subsidiary B                            July 2000
 JournalNo.  Date    LineNo.   Account                       Amount

   73821  2000/7/31   2355     525300  Vehicle Maint-NY    Dr   400
   73821  2000/7/31   2355     250000  Interco Payable-NY  Cr  -400

This is classic intercompany accounting.  It could be done today. Setup any big midrange accounting package that has a browser interface such as Great Plains or Lawson.  Sell subscriptions to a bunch of companies.  Establish a separate company in the system for each subscriber.   Then, create business objects to post each transaction event that happens between subscriber companies to the appropriate ledgers.  The intercompany payables and receivables would always agree, whenever both parties to any transaction happen to be your subscribers.  Perhaps some companies having strong integration needs might subscribe to your service, such as supply chain partners. 

Multi-company CDEA ledgers don't work out of the box, however, because 

Accordingly, the design for this STR is simpler --it models only the event of the completion, or execution, of a transaction.  This model stores the amount and other attributes as they were agreed by two parties, and of course, stores them only once rather than in two ledgers as would be done in a multi-company ledger.  

Theoretical basis for an STR model:

Classic double entry accounting (CDEA) is an ingenious modeling language, having template or solution for any possible transaction.  All accounting systems in use today are CDEA --even the list-oriented personal finance programs have "splits" in which you classify your cash or investment movements into income, expense, transfers, etc.

CDEA entries for external transactions (i.e. involving other parties) are the focus of the STR.  Half of the any bookkeeping entry for purchases or sales represents the money exchange versus the  reciprocal party.  The other half of the entry, generally, represents your internal classification as income, expense, inventory, or other asset or liability.  STR is not concerned with these classifications other than to support them, and recommend they be classified with XBRL types. 

The external date and amount agreed with trading partner, owner, debtor or creditor with whom the business transaction was concluded, has always been recorded identically in the other party's books.   This will be shared in the STR.  We are not breaking any new ground in law or business culture.

Any modernization of CDEA for the web must provide data structures that serve the needs of both parties to the transaction.  Existing B2B XML messages contain such structures--they are event-oriented, single entry accounting entries which identify both parties, and contain a transaction date, amount, and list the products or services.  

The global economy may be viewed as a 3-dimensional cube containing sheets for every party in the universe, summing to zero. (More discussion at GLschema1GLschema2).   The money movements of the entire economy are a single, multi-company ledger.