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.  

1950-2000: 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 pairs of debits and credits reside on hosts where exchanges were mediated or transported, rather than inside the ledgers of the trading partners.
  
• those pairs of debits and credits are not the same ones that would have been recorded inside the company-centric ledgers. There is a debit from one party and a credit from the other.
  
• the pairs of debits and credits are resolved into a single event record.  The single record contains the parties' identity, date, amount, and the consideration, etc.  
  
• each party donated a debit or a credit-- they still need the other half of those CDEA entries.   Accordingly, STR is a triple-entry system providing a private stub for each party's balancing entry. Most businesses will continue to maintain classic double-entry ledgers as in the past.  But they don't have to: they can store those on the servers, too, explained below. 
  
  But first, let's take a break, and get beat up by the small business owner.

	"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".

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 

• they impose a number of unnecessary structures on the parties, and constrain their choice of software to a common platform.
  
• the "trusted third party" has way too much access to all of your data,
  
• the processing of external transactions is too tightly coupled, for example, requiring  locks on your tables when 3rd parties conduct business with you, and
  
• a classic multi-company ledger model maintains much more information than that data which is truly common to both trading partners.  Maintaining two CDEA ledgers goes far beyond what is strictly necessary to achieve the objective of the shared repository; for one example, every company has different charts of accounts and other attribute tables which don't need to be on a shared host.

• Business process is way too complex.  To create correct double-entry postings to every unrelated company requires knowledge that only exists inside the companies not on the ASP
  
• Computer processing for a whole midrange/ERP system is too great.  Doesn't scale due to hardware costs.

• It is far too difficult to add new companies, and each new company requires too much system resources.
  
• The model has no hope of widespread adoption.

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 GLschema1,  GLschema2).   The money movements of the entire economy are a single, multi-company ledger.