There is no other way to reach the efficiencies and process improvements needed, than some type of external interface with 3rd parties. I hope everybody gets that, by now. There is no way to put the genie back in the bottle, and build or sell completely isolated accounting systems--it's too expensive.  The rest of the world is moving forward on this. We need interparty integrations and the only way is forward. All of the intellectual vitality today is focused on B2B, B2C commerce. Witness ebXML as a defining forum for all these issues.

In future, a GLT might be architected along the triple-entry theme I have tried to express in http://www.gldialtone.com/str.htm. The STR is a design based on shared access to the record of arms-length exchange by those two parties.  In the long run it is inevitable there will be some kind of shared transaction table someplace behind any successful ecommerce for individuals and small business. 

Following 3 paragraphs are advocacy for shared transaction hosts: skip them if you're in a hurry.

In the short term, the fortune 500 is converging around Point-to-point architectures, based on middleware, as they redo EDI into XML. These battles of the titans are irrelevant to  small businesses who are never going to maintain complex multiple-step commerce on a point-to-point basis. That would require every party to maintain an online, realtime, 24x7 responsiveness and complex logic to implement. Almost a two-phase commit. Big business needs that. They need to click on things and get an answer from their supply chain, and will not delegate stewardship over data. They are willing to install MQSeries, Biztalk server or whatever it takes, to maintain their huge complex (and isolated!) data structures.  Small businesses cannot afford that. We need an asynch message forwarding hub like the STR which also serves as a persistent reference of every component in our mutual receivables and payables. 

The STR is a subset of the rootledgerXML schema.  It is a format for representing CDEA (classic double-entry accounting) transaction rows. Nobody is going to have any problem implementing GL interfaces to any legacy GL with the rootledgerXML schema. It is certainly backwards compatible, and it is fully forwards compatible because it is XML.

Triple entry accounting is this: You form a transaction in your GLT. Every GLT transaction requires naming an external party. You have a party table (or, a party service on an ASP, perhaps. Perhaps DUNS. Perhaps an ebXML registry, or an LDAP directory provider, or an authentication provider on the internet.)  Your party table contains a real customer or supplier ID which is publicly agreed, just as domain names or email addresses are part of  public namespaces.

When you POST, the entry is stored in your internal GL (i.e., your GLT, if you have split your ledger, which is my thinking) just like in the past. But it is also submitted to the triple-entry table in whatever STR system you choose. Perhaps your own STR server, such as the STR module of your GL.  Or perhaps it is a big STR server out at Exodus or your ISP or a BSP.  The same information you stored in your GLT entry suffices to complete the shared entry in the STR, and your private Stub.  If the entry is part of a pattern, you must provide the GroupID. Otherwise, the STR creates and assigns a GroupID in case you need it later. See #4 below.

The STR diligently forwards the entry to the reciprocal party. If the reciprocal party is interested in integration, they will reply to the transaction sent by the STR, and optionally, complete their private Stub. That is triple entry. STUB - SHARED ENTRY - STUB. This is a sub-ledger, folks. Your work is done, if you trust your STR's stewardship of data. Of course you will still need a rootledger for control totals of this STR, and other STRs, and for your GLR.

The GLR is not so different from the GLT except that the architecture is uncoupled from the GLR so that its designs can be optimized for different purposes (statutory adjustments and financial reporting) and so that it can evolve in a separate direction. 

1. the GLR is much more private, containing all the capital accounts, intangible assets, all the accruals and adjustments, the overall picture of the enterprise. This reduces risk and provides more granular security. 

2. the GLR is the component which supports financial reporting integration. Financial Reporting is obviously going to be subject to very demanding, ongoing technology challenges, for example requiring a full XML parser, and supporting very demanding tax and management reporting needs. Reporting is multidimensional and at the same time disorderly process.  These have manifestly become a separate problem domain, with separate requirements, from the processing of sales, purchases, B2B transactions, supply chain, demand signals, etc. required of the GLT transaction posting engine.

3. the GLT is something that is almost becoming a community asset. You just cannot get the kind of integrated economy we need, without some real consensus among practitioners, to move certain parts of the transaction to a shared place. I am not saying public; I am saying shared.  The amount, date and description of a deal are inherently shared between two parties and should be stored visible to those two parties alone, i.e. either protected by private system permissions or, encrypted visible to those two parties alone.

Systems which maintain shared transaction repositories will experience security lapses. That is what happens. When the automobile was invented the first thing everybody did was kill themselves in head-on collisions. Airplanes. same deal. But if you want to save 10 million person-years of work every year, it is well worth the price of a certain messiness.  If you split the GL into a GLT and GLR, the severity of losses may be much reduced.  For example you may have multiple GLTs, and, none of them need contain treasury accounts, capital accounts, or any of the non-external accounts needed for a financial statement.

4. The GLT must be evolved to support patterns. ebXML is calling these "Commercial Transactions". These are exceedingly important.

A particular transaction in business almost never stands alone. They come in patterns. For example offers/acceptances form a transaction but seldom encapsulate the entire fulfillment and payment cycle. Even if there has been a payment accompanying a PO message, the customer is now waiting for fulfillment. There is a whole science and literature built around this, and adopted by Business Process workgroup of ebXML. REA talks about this, in their dualities.  These theories have fundamental merit.  Double-entry accounting does not work as a transactional framework in business automation involving multiple parties.  It is broken and much of the software industry has recognized that, and moved on. 

Patterns are not the same thing as XML "conversations" such as RosettaNet "PIPs" or OAG "scenarios" which are more like 

hello are you there, send me your price for a widget model 234
yes, I'm here, widget model 234 costs $45.33.
ok here is my PO for 12 widgets model 234. please confirm
no, you don't have credit. give me a credit card.
ok my credit card is 0000-000-000-000
Ok order accepted. 

These words of course do not exist in the XML messages--but the XML messages are very similar, and human readable.  The above is a real-life PO submission. This will happen, in some automated XML PO submissions between two computers. 

The point of this exercise is that a PO is part of a larger pattern because delivery has not happened yet, and the credit card payment has not been received, either. A pattern might include the PO and also, a later delivery, or settlement of accounts thru an OFX transfer etc. A GroupID is needed to associate all the dealings surrounding a particular "Commercial Transaction" pattern.  ebXML will come with these patterns baked in. There will be registries of standard commercial patterns, and XML repositories containing the schemas that define them.  ebXML mailing lists contain draft documentation of these patterns.

The GLT, freed to optimize for all the transaction oriented operations, can evolve to satisfy things like ebXML patterns, and will be a better animal. This partitioning also allows developers of GLT accounting systems to specialize, in ways that do not have many dependencies on the GLR team.

For example you would never have two GLRs. But you might have numerous GLTs which could be managed as subledgers in consolidations. I don't know.  Perhaps GLTs will not always be CDEA, classic double-entry.  They might be single-entry tables. 

Or, perhaps your rootledger GLT would only contain summary entries, like control accounts, pointing to STRs. That would be elegant; you would eliminate redundancy in detail rows..... in any case, the principle is that the GLT developer can ponder those things without getting sucked into the whole XBRL, XML parsers, and years of disruptive changes in requirements in reporting technology. You almost get a sense that the GLR might reside at a BSP, or be administered by a CPA firm perhaps. That is yet another reason to split the GL into two components.

The GLR may be driven by its needs to deliver financial reporting information in XBRL format.  CPAs have a major need for better tools for audits and compilation of financial statements.  It is not entirely clear how far back into accounting systems XBRL will ultimately extend its influence, or, how broadly it will support the "information supply chain" outside of the publicly listed companies of the NYSE and NASDAQ.  It is inherently impossible to define a single hierarchy even within the Commercial and Industrial companies due to permissible alternative presentations  For example income statements may be presented in natural accounts or in functional aggregates.  In any case there will be quite enough challenges in design of the GLR to tear it away from the GLTs.

A final thought is that the separation of GLT and GLR may be a completion of the process underway for decades which has been called the "cash flow statement", "funds flow statement" etc.  But rather than saying "those cash flows are important by gosh", the GLR takes everything which is in the nature of an adjustment or accrual, and considers all of those, explicitly, the problem and moves them into another database.  What is left behind are the objective truth of 3rd party exchanges: the GLT.  In other words if you sum up the GLT you might get all the components of the Cash Flow statement. 


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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Quiz

1.  What are some irreducible minimum data elements in any e-commerce exchange? 

2.  What are the four clusters of information that 3rd parties always share, in any transaction and might as well be on a shared host?  

3.  What are the five data elements that are the minimum facts necessary for individual personal finance programs, record keeping for income tax deductions, and small business general ledgers?  

4.  What organization is working to establish standard names for all the data elements defining  "Who, What and How" classifications in e-commerce?  

5.  You can buy and sell, pay and receive, and conduct business successfully using several unrelated BSPs (business svc. providers)  What are the seven things you cannot get from multiple BSPs? 

6.  If conducting business over the internet is this simple, why is it taking so long?