OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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 

 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC