« Reversing My Position: Calculation Inconsistencies Can Be Unavoidable | Main | Macro-based Financial Statement Creation »

Understanding the Moving Pieces of Dimensional Aggregation

Just like [Line Items] have patterns or information models such as [Roll Forward], [Roll Up], and [Hierarchy], the [Member]s of an [Axis] likewise have an information model. I have put together a document which summarizes these moving pieces which you can get here.

Here are some example financial reporting use cases which show different types of dimensional aggregation schemes which will give you an I deal of what I am talking about:

  • [Axis] with no aggregation: Subsequent events or property, plant, and equipment policies would be an example of where you would have an [Axis] with no aggregation. Subsequent events are rarely, if ever, added up to arrive at some total amount for subsequent events of an entity.  The same with PPE policies, they are not added up.
  • [Axis] with basic aggregation: Nonmonetary transactions are a good example of a basic aggregation. There is no real grouping of nonmonetary transactions, it is simply a flat list.  That list has an amount of for each nonmonetary transaction, and the total for nonmonetary transactions is commonly reported. That total does not tie to any other location in the financial report, it stands alone.
  • [Axis] with complex aggregation: Business segment reporting is a good example of potentially complex aggregation. You may have a Parent Holding Company [Domain], which has consolidation eliminations, and multiple business segments.  You may add to this a breakdown of continuing and discontinued segments. This could become even more complex with asset groups, reporting units, and disposal groups.

As the XBRL Dimensions Specification does not address dimensional aggregation, taxonomy creators are on their own to address this.  Fortunately, XBRL Formulas is available to articulate and validate against aggregation schemes.

In order to create these aggregations, a good understanding of what a domain is becomes important.

See the document for more information if you care to understand and eventually master this area.

Thank you to all the XBRL Dimensions heavy weights who contributed to my understanding of this important information.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (3)

Charlie,
My thoughts on your statements below regarding modeling dimensions: I agree there are several ways to create a dimensional model but there should be definable criteria to guide us in creating the most consistent models possible.

In the example of the breakdown of data into metadata using 'State' as the domain and 'Region' as the members is not as good a model as having 'State' as the domain with "Alabama, Arkansas, etc" as its members. I think there should be a clear explicit or implicit 'line' connecting a member to its domain. In the example of 'State' as the domain, it would only make sense that its members are actual states. To cut to the chase, my response to your question, "what criteria do you use..."? create more [as many as you feel are necessary] relation tables to model data but keep them as 'clean' and intuitive as possible with members that make sense 'belonging' to a domain.

PER CHARLIE BLOG:There really is no right or wrong answer here; how you would model your business use case depends on the dynamics of what it is you are modeling. The primary point I am making here is that if there are multiple ways to model the same information; then what criteria do you use to determine the most appropriate modeling approach?
March 3, 2011 | Unregistered CommenterJoe Ryba
I get frustrated that the US XBRL Mandate does not seem to discriminate between things that can be modeled (i.e. complex aggregation), and things that can't be modeled (i.e. no aggregation).

It seems to me that stuff that can be modeled, is more intuitive to describe, and more intuitive to use, and therefore easiest to standardize.

Level 4 doesn't discriminate between Business Segment reporting, and the (relatively) trivial details about (for example) the amendment to debt 20 days after filing.

Could the SEC's policy have been better-planned to encourage that kind of an understanding, that kind of coordination?
March 24, 2011 | Unregistered CommenterNate
To play devil's advocate to Joe's point, if Charlie had chosen to call it "Region [Axis]" in the first approach, would Joe change his answer? If so, why?

Is it overly simplistic to think that the first approach (single Axis, but deeper) is about aggregation (adding), maybe better purposed for checks and balances, while the second approach (two Axes, but shallower) is about dimensionalizing, better purposed for visualizing and understanding of the data?

My intuition says that overlapping Members (i.e. >1 Axis), are more powerful than Members in structure.

I wonder if >1 Axis could be adapted to provide the same checks that a single Axis could..., and I feel like a single Axis could not be adapted to provide the same richness as >1 Axis.

Thanks all!
March 24, 2011 | Unregistered CommenterNate

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.