Digital Financial Reporting

Here are some nuances that most people don't really understand when it comes to modeling XBRL.  This is one example of a theme.  The theme relates to consistent meaning within an XBRL taxonomy.

The Detail

Consider the following SEC XBRL filing taxonomies.  These are renderings which I generated. Here, we will be looking at the networks (i.e. extended links with the same role) and hypercubes. This is more about providing you with some detailed information to look through should you find the need.

• Ebay: This balance sheet is within a network, it has a [Table], that table has [Axis] and line items.
• All these are the same: You can look through all these and they are all the same as Ebay.  All these filings were created by Edgar Online.
• Another way to look at the same thing: You can look at the same thing in yet another way.  Each extended link has a hypercube called "Statement [Table]", each hypercube has at least one [Axis] and exactly one set of [Line Items].
• More Inconsistent: This set of SEC XBRL filings is more inconsistent. Some have [Table]s within the networks, some don't, some use [Axis] and [Line Items] on the [Table]s, some don't.

The Summary

So what is going on here and what is the point? The big picture is that XBRL and the SEC allow you to model an XBRL taxonomy with the following options:

1. Within a Network (i.e. an extended link of a specific role) which contains no hypercube. (Qwest does this.)
2. Within a Network which does contain a hypercube but each hypercube has the same name. In the examples above you see the hypercube "Statement [Table]" being used over and over. (Citigroup does this, 34 networks, "Statement [Table]" used 34 times.)
3. Within a Network which does contain a hypercube and each hypercube has a different name. (Carnival is the closest to this, but many of the hypercubes don't have [Axis] and/or [Line Items].) 

The Analysis

What is going on? What do these different options or varieties actually mean? What is the difference between one or the other? The answer is no one really can know because it is not documented.  Are these wrong? No, none is wrong as they all pass SEC XBRL validation.  Are these right? Sure, they pass validation, but they may not be the best of practices.

Basically, these are possible ways to construct an XBRL taxonomy:

• Network alone.
• Network with one hypercube (and therefore they can have the same name).
• Network with multiple hypercubes (this required different hypercube names).

How will each of these be rendered by the SEC XBRL rendering engine?  Where does the network show up in the rendering engine and where does the hypercube show up?

Why can't these be consistent?  What possible downside could result?

Important Characteristic of Hypercubes

Hypercubes do something useful that not using hypercubes can never achieve.  You have to articulate the [Axis] and the allowed values for each [Axis] which are called [Member]s or [Domain]s in the taxonomy.  Further, you can only use what has been specified in the taxonomy.  Whereas, there are no constrains on things like the entity identifier and period portion of context; they are unconstrained by the hypercube.  This has two affects.  First, users have no real idea of what you want reported unless you document it somewhere else because it is not documented in the taxonomy.  Second, you get stray fact values showing up in things like calculations because the hypercube cannot constrain entity identifier and period.  Or, another way of looking at it is that the more you use hypercubes the more control you have over what facts are used by the hypercube...that is what the hypercube does is constrain the concepts, [Axis], and [Member]s.

Bottom Line

Properly build hypercubes are easy to render because you can use the [Axis], the concepts, the [Domain]s, and the [Member]s to help in the rendering process.  Frankly, there is really little need (i.e. no need) for both networks and hypercubes to have semantics.  Hypercubes are better than networks because hypercubes provide more useful features/characteristics.