XBRL - an XML description of descriptions

[Todd Boyle <tboyle@rosehill.net>]

XBRL may be describing the wrong thing.  XML is a system of notation 
for describing things.  But the XBRL application provides an XML 
description of descriptions.  It is a list of the financial reporting 
buckets which are themselves, adjectives. (www.xbrl.org)

Owners and creditors need, rather, XML descriptions of *transactions*, 
business dealings, assets and liabilities.

The problem is that CPAs exercise judgment in deciding what goes into 
the reporting lines of financial statements.  Some account totals in
the accounting system may be described in more than one way, and worse,
you can slice and dice the data into different aggregates (i.e. post
journal entries to the GL)

Because there is so much discretionary freedom at this point in 
history, there isn't any single, inherent GAAP classification 
underlying any given transaction.  You can perhaps name all GAAP 
classifications unambiguously, but the monetary amounts in the XBRL 
instance document are garbage.   If you want to find out what they 
contain, you have to call the CPA.   Accordingly, XBRL does not
fully exploit the power of XML.

The long term viability of XBRL may be improved by tying it more 
closely to the native character of the underlying transactions. Most 
constituencies for XBRL financial data might prefer more exact and 
granular details of transactions, which in future will be captured and 
recorded at time of handshake between adverse 3rd parties.  Those 
attributes will be captured in a variety of standard B2B XML 
vocabularies such as ebXML (www.ebxml.org), as well as tax XMLs, 
and proprietary XMLs such as xCBL, CBL2, SMBXML, and FastXML.

All of the XML vocabularies used for transactions have an advantage 
over XBRL in objectivity and in being legally binding terms, agreed in 
arms' length exchanges. 

Some day, as XBRL is improved and sharpened to provide more detailed
views of the enterprise, you are going to run into ebXML aggregates 
in the transaction database.  There can be a train wreck, or there
can be harmony, depending on your approach today.

Here are two suggestions:

1.  All XBRL instance documents should contain two components; a 
reporting section and transactions section.  The CPAs adjustments, and 
all other accruals and adjustments posted to the GL internally (not as 
arms' length transactions) might be presented in the GL-R section, and 
the transaction aggregates arising in arms' length exchanges might be 
presented in a GL-T section.   This approach has additional value in
that it can identify the parties responsible for adjusting entries, and
encourages different security models for the different GL databases.

2. CPAs should make a greater effort to influence other consortia and 
standards bodies who publish XML schemas for B2B commerce, to properly 
encode the attributes necessary for basic GAAP reporting.  I am 
suggesting that the XBRL consortium should publish uniform guidelines 
for transactions, and prepare to use them in our systems.

Without taking the time for a complete treatment, it seems to me that
unambiguous due dates or maturity attributes should accompany all 
monetary assets or liabilities (payable or receivable).  Terms such
as interest rates, payments, etc. should accompany installment debt
or assets.   Tax attributes should accompany transactions.  Capital 
equipment should contain default useful lives.  Transactions which 
are parts of other contracts, or accompanied by multiple asset or 
liability components, taxes, commissions, etc. should be completely 
tagged at creation.  Transactions with related parties should have
at least a boolean 'yes' for 'related party'.  A cluster of attributes
provide bases for valuation of non-arms-length transactions. 

Why do CPAs allow businesses to create great ambiguity in their 
accounting systems, telling conflicting stories to employees, 
creditors and stakeholders, and shift responsibility to CPAs, to 
recharacterize the historical record?  Every CPA in practice will 
understand instantly what I'm talking about and this applies in tax,
as well as attest services.  

Today's systems are worse than merely unintegrated-- there is a 
centripetal force causing them to be systematically wrong.  XBRL is a 
tool to finally constrain these systems, and disambiguate the historical
record of what has been transacted.

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