Subject: XBRL object orientedness. multiple rollups.
XBRL defines a standard data format for transmitting financial statements, and subsets thereof, to downstream applications such as investment analysis. The vocabulary provided by XBRL is enormously valuable to practicing CPAs and software developers alike. Non-duespayers cannot attend meetings, and XBRL members generally don't post in public forums. But I seem to observe some consensus that there may be some structure problems with the current XBRL, or at least, the 7/31/2000 C&I taxonomy. I heard at least ten different people refer to either the "object oriented problem" or the "multiple rollups problem" during 16 hours of XBRL classes I attended last week. The instructor stated at one point, that the taxonomy will probably change to become more object oriented. In committee meetings, a sign-up sheet was passed around for those interested in working on more object oriented structure and it has filled up with dozens of names. Please, somebody correct me if any of this is wrong. Multiple rollups appears to be the classic problem of presentation of multi-dimensional data. One case was NFP (not for profit) accounting, which has lots more dimensions than typical businesses. You often see trial balances by Fund, by Grant, by Program, etc. These are true, independent dimensions which can only be presented in completely separate schedules. Commercial companies also have important dimensions-- by customer/market segment, by branch/region/country, by functional org. unit or budget units which span the branches, etc. But as you know the XBRL taxonomy for Commercial and Industrial companies is a single hierarchic structure, so that can be a problem. It is anyways NOT designed for reporting on multiple dimensions other than the statutory GAAP dimension, and it struggles whenever multiple rollups are required by GAAP. The guts of the C&I taxonomy are really the 240 elements in the balance sheet (elements 93 to 333) and 93 elements of the income statement (elements 334 to 426). So, it is not so difficult to understand. There is a tree-view viewer on the website, to surf the terminology and actually construct financial statements instance documents. Here are a bunch of the "XBRL types" in the C&I taxonomy: 156 noncurrentAssets.propertyPlantAndEquipmentNet 157 propertyPlantAndEquipmentNet.propertyPlantAndEquipmentGross 158 propertyPlantAndEquipmentGross.land 159 propertyPlantAndEquipmentGross.buildings 160 propertyPlantAndEquipmentGross.machineryAndEquipment 161 propertyPlantAndEquipmentGross.furnitureAndFixtures 162 propertyPlantAndEquipmentGross.computerEquipment 163 propertyPlantAndEquipmentGross.transportationEquipment 164 propertyPlantAndEquipmentGross.constructionInProgress 165 propertyPlantAndEquipmentGross.leaseholdImprovements 166 propertyPlantAndEquipmentGross.otherPropertyPlantAndEquipment 167 propertyPlantAndEquipmentNet.accumulatedDepreciationAndAmortization 168 propertyPlantAndEquipmentNet.capitalLeasedAssetsNet 169 capitalLeasedAssetsNet.capitalLeasedAssetsGross 170 capitalLeasedAssetsNet.accumulatedAmortizationCapitalLeasedAssets 171 noncurrentAssets.noncurrentAssetsFromDiscontinuedOperationsNet (and so forth) The US taxonomy declares these elements as a basic, reasonable, legal breakdown. and XBRL provides no other qualifiers. Give your CPA the numbers for this breakdown, on a historical cost basis, and it's sufficient for US GAAP reporting. You will also note the aggregation of depreciation into one line in the XBRL balance sheet. In effect you don't have a choice to provide a breakdown by asset type, unless you create your own naming in a whole new XML schema, i.e. a custom taxonomy with its own XML namespace. It is essential to note that the bottom 2/3s of the C&I Taxonomy provides another 1,171 elements (from 710-1880) for footnotes and disclosures and highlights (both strings and monetary amounts), for example, 1155 propertyPlantAndEquipmentNote.propertyPlantAndEquipmentNetNote 1156 propertyPlantAndEquipmentNetNote.propertyPlantAndEquipmentGrossNote 1157 propertyPlantAndEquipmentGrossNote.land 1158 propertyPlantAndEquipmentGrossNote.buildings 1159 buildings.depreciationMethod 1160 buildings.life 1161 propertyPlantAndEquipmentGrossNote.machineryAndEquipment 1162 machineryAndEquipment.depreciationMethod 1163 machineryAndEquipment.life 1164 propertyPlantAndEquipmentGrossNote.furnitureAndFixtures 1165 furnitureAndFixtures.depreciationMethod 1166 furnitureAndFixtures.life 1167 propertyPlantAndEquipmentGrossNote.computerEquipment 1168 computerEquipment.depreciationMethod 1169 computerEquipment.life (and so forth) Depreciation was cited by one observer as an example where an object-oriented approach should be applied, i.e., the XBRL schema should enable the user to apply contra-assets like amortization or depreciation to any asset account they might relate to, and all of the properties of a particular thing should be logically nested together in the same place. Perhaps depreciation data is split between several locations in the 7/31 C&I to make the schema easier for accountants to use. You can't foot a balance sheet if its all jammed up with supplementary tables and notes. But perhaps the reason is that the approach taken by XBRL was to explicitly name every allowable reporting item in GAAP as an XML element. If you then iterate thru every permissible usage of every desirable object property, you would quickly run the total schema up by thousands of elements. That is what always happens, mathematically, when you present something multidimensional as a flat list by repeating bands of compound values. But again, this is supposed to be a representation of what is required under the law, for U.S. GAAP and the number of required elements is an academic question. Perhaps the dissatisfaction or movement to make XBRL more object oriented is coming from the software developers side of the street. If they are annoyed now, imagine how annoyed they will become when they realize there is no logical structure to the underlying data itself. XBRL is an XML description of descriptions, or adjectives, which are applied by CPAs to the totals in the accounting system to massage them into amounts that you can't be sued for printing. The transactions in the general ledger do not have any inherent, unambiguous GAAP classifications-- the exact same fact pattern can be reported in financial statement in different ways, entirely lawfully. So, there is no "object model" that can be "discovered" or enumerated in XML, in the transactions or activities of a company. Call me a troublemaker, if you like, but I want all of the subjective adjustments made by CPAs and accountants isolated in a different sub-ledger from the real 3rd party transactions which contain the attributes agreed to in arms length exchanges. Then the C&I taxonomy will be MUCH smaller, and owners will gain a measure of control over the business problem of lawyers, accountants, and government regulators. The XBRL vocabulary is a hierarchic structure which encapsulates every attribute and dependency within a fixed set of names. Hmmmmm. And the XBRL has only provided a fixed set of attributes for each account. hmmmm. and those attributes are weight, order, and rollup-to. hmmm. You cannot attach additional attributes to the names within the ci: namespace. Hmmmm. and you cannot avoid these dependencies unless you create a whole new taxonomy and namespace, which no destination application or user would understand.... ummm, ok. And the taxonomy must change each month to reflect any legal activities such as FASB pronouncements. Otherwise, the taxonomy is wrong and it is impossible to deliver financial statements in lawful formats with it. hmmm. And the AICPA disclaims any warranties, most certainly disclaims any responsibility that would enable any reliance on this taxonomy as a clue to GAAP. sheesh. A leader and expert involved in the XBRL design at the class last week told me the FASB regards an authoritative XML ontology for GAAP as impossible. So, GAAP is really a huge set of terms offered by CPAs, with the only thing really unambiguous is the name for each "cell". When you want to put anything in the "cell" the CPA will say "OK, lets talk about it." Reminds you of EDI. They won't even publish the technical definitions for the cells unless you pay $500 or something, because the AICPA and FASB hold copyrights to all of it, and have been selling them for $20 per legal pronouncement. Yes, they are enforced by the police, but you have to buy them. So, it has been hilarious listening to software developers learning about XBRL, asking questions about the 'object hierarchy' of XBRL in the classes, as they one-by-one realize GAAP cannot be programmed, * Todd F. Boyle CPA http://www.GLDialtone.com/ * tboyle@rosehill.net Kirkland WA (425) 827-3107 * XML accounting, webledgers, BSPs, ASPs, whatever it takes
Powered by
eList eXpress LLC