US GAAP Taxonomy and Dimensions
I am getting a lot of questions related to the US GAAP Taxonomy and dimensions. I am also getting requests for training materials in that area. Currently, if you are a bit technical there is some pretty good information in the FRUX book (Financial Reporting Using XBRL), chapter 14 "Understanding and Using XBRL Dimensions."
But WARNING! That material was written almost two years ago when I had a far, far less understanding of XBRL Dimensions. I also gave a class at the XBRL International Conference in Munich (June 2007) on the very basics of XBRL Dimensions. Since that time we went through the process of trying to decide if and how to use XBRL Dimensions in the US GAAP Taxonomy and I have learned a boatload more about XBRL Dimensions, how they work, etc.
Yesterday a group of us has a little mini symposium on instance document creation here in Tacoma and I learned something else about XBRL Dimensions that I did not know. Basically we realized that as the public taxonomy stands it is possible to create two valid versions of the same instance document, which is a bad thing in my mind. I remembered that the COREP taxonomy was doing some funky stuff with empty hypercubes, and now I know why...to solve the issue we ran across yesterday.
The taxonomy can be constructed to hide literally all of what appears to business users as complexity relating to XBRL Dimensions. There has been, and still is, a lot of misunderstanding about what is trying to be achieved with XBRL Dimensions. The key here is to minimize the burden on business users for reporting using XBRL. The way to do this is to not use XBRL Dimensions less, it is to use it correctly and typically more as the dimensional information is something that a computer software application can use to make the business user's life easier, not harder. The thing is that most software developers are not implmenting their software (at least what I have seen) appropriately. Appropriately is not defined as following the XBRL Dimensions specification to the letter...it is about using the dimensional meta data to help the user out. I am not really seeing that in software.
On my list of things to provide is information which will help business users understand what they need to understand about the use of XBRL Dimensions within the US GAAP Taxonomy. My goal is to never use the term XBRL Dimensions. The problem is that it is hard to do that with the current state of software. I will figure something out.
Charlie
1 Comment
View Printer Friendly Version
Email Article to Friend
Reader Comments (1)
My understanding of dimensions is that it allows users to see different views of the data. Whilst it is possible to do this with a large number of elements, it is easier to create them using XBRL dimensions as a single dimension can be used with a number of primary items rather than having to create a large number of elements (primary items).
I guess the opposing viewpoint is that whilst there are less elements there are more contexts in the related instance documents and the calcuation linkbase cannot calculate across contexts to verify totals. I know that this problem will be fixed with the Formula Specfication, but then formulas will initially be complex and reduce in complexity as software applications create better interfaces to create them.
Hopefully the same will occur for dimensions. At the moment the process to create them is not that easy. However, I think that software that creates instance documents using dimensions is more important than software applications used to build taxonomies. Those building taxonomies need to have the XBRL knowledge to create the dimensions meta data correctly. Those creating instance documents based on those dimensions will probably not have the same level of XBRL knowledge as the taxonomy authors.
My concern with the UGT is when less informed users are required to create extensions where dimensions are involved and they do not have sufficient understanding of the underlying XBRL knowledge. I have read most of the Preparers' Guide and I am not convinced there is really enough information in that for preparers who might need to create an extension taxonomy. I might need to read it again several times in detail to reach a final conclusion on this topic. There are many mentions of (needing) to create extensions but the detail on how to go about it seems to be lacking detail.