[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: XBRL - an XML description of descriptions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC