XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

I have received a number of questions about the [Table] in the US GAAP Taxonomy. What I want to do with this blog post is point out some big picture things which help you get a better understanding of what exactly a [Table] is, how to use them, and answer a the questions which I have received.

As can be seen by this analysis the [Table] is not well understood by SEC XBRL filers. The inconsistency of the SEC XBRL filings are a good indication of this lack of understanding.

But understanding and using the [Table] does not need to be complicated or hard to understand. You can make this vastly easier. When business users realize this, they will start to point software developers down the right path. I have not seen one software application which has used any creativity to make creating [Table]s intuitive for business users.

Further, the ideas which can make [Table]s easier to use and understand can also be applied to [Roll Forward] and other information modeling patterns within the US GAAP Taxonomy. I published a document called US GAAP Taxonomy - Tips, Tricks, and Traps in 2008. These sections of that document are very helpful in understanding [Table]s:

Section 2.2: Organization of the Taxonomy
Section 2.3: Understanding the Modeling Patterns Used Within the UGT
Section 2.4: Understanding the Tables and Dimensions
Section 2.5: Understanding Networks and Relations
Section 2.6: Modeling Options, Syntax and Consistency

The information is slightly dated, but the general concepts are still very much applicable. Eventually I will do a better job of organizing and explaining this information, but there are only so many hours in the day.

Further, if you really want a good understanding of the US GAAP Taxonomy, read through the information in Section 3: General Information (applicable to all networks) and Sections 4 through 60. These will be particularly helpful when you get into detailed tagging of the disclosures.

The Big Picture

Here is the big picture. The [Table] is really a hypercube. The US GAAP Taxonomy uses the term [Table] because the creators thought the term is easier for business users to relate to. However, what that term tends to do is cause confusion between the presentation of information and the modeling of information, which is unfortunate. Another term used to describe hypercube is simply cube or data cube. You may be familiar with this term from business intelligence (BI) software or corporate performance management (CPM) software.

To be precisely correct, the term you really want to understand is hypercube and here is why this is important to understand. Bear with me, you will realize that if you don't understand this you will never fully and properly understand the US GAAP Taxonomy.

Scalar: A scalar is data which has no dimensions. For example, the value for pi (which is 3.14) has no dimensions.
Table or matrix: A table (think a spreadsheet or a relational database table) or matrix has two dimensions. A table is basically a two dimensional hypercube. Think rows and columns, you basically have an "X" axis and a "Y" axis.
Cube: A cube has three dimensions. Think a third dimension, you have an "X" axis, a "Y" axis and a "Z" axis. Remember math class when they talked about that Z axis, turning a two dimensional graph into a three dimensional graph?
Hypercube: A hypercube has any number of dimensions, or "n" dimensions. Hypercubes are harder to express visually. To do this you have to lock a dimension like you do in an Excel pivot table or repeat headings like is done in printed reports. The term for this is slicer or looking at a "slice" of information.

If you are still reading, good job! This blog post is for you. A lot of people probably have already given up trying to understand this. But you want to keep going because this information is critical for you, it will exist in your future.

A hypercube is a notion of the multidimensional model. The multidimensional model is a flexible way of organizing information. The multidimensional model is gaining more and more popularity because of its utility in making information flexible. BI and CPM software use the multidimensional model because of this flexibility. You may be more familiar with the term "relational model". The relational model is used by relational databases. The relational model is great for transaction processing but it tends to be too restrictive for analysis. That is why the multidimensional model is used for analysis.

What does all this have to do with the US GAAP Taxonomy and the [Table]? A [Table] is really an XBRL Dimensions hypercube. It is expressed in the presentation relations in a certain way. That [Table] is also expressed in the definition relations in a specific way. The way hypercubes are expressed within the definition relations is dictated by the XBRL Dimensions specification and it MUST be the same for EVERY XBRL taxonomy.

The way a [Table] is expressed in the presentation relations in the US GAAP Taxonomy is dictated by the US GAAP Taxonomy architecture. It is consistent. That consistency allows for a computer application to auto-generate the definition relations based on the presentation relations. That is how the definition relations were created by the US GAAP Taxonomy, they were auto-generated.

How do you create your definition relations? Probably by hand. Why is that? Because your software vendor does not realize and leverage this fact. But they could.

Here is another thing relating to [Table]s. Per the US GAAP Taxonomy Architecture (see section 4.5, page 38 of this PDF), a [Table]:

MUST have at least on [Axis] but can have any number of axes
MUST have exactly one set of [Line Items]

So, why does your software allow you to put something other than an [Axis] or a [Line Items] concept as a child of a [Table] in your software application???

There are many other rules relating to [Table]s, [Axis]s, [Domain]s, [Member]s, [Line Items]s, and so forth. There are other information modeling patterns such as a [Roll Forward] which have other rules. Software can, and likely eventually will, leverage these relations. Doing so will make it easier for business users to understand and use [Table]s and other such relations.

Issues with [Table]s

The first problem with [Table]s is that if you DON'T build your [Table]s consistently (i.e. you do this) you CAN'T use this leverage.

But there are other issues which you may, or may not, be thinking about. But the issues do exist:

[Table] express business semantics: A [Table] expresses business semantics, or is supposed to. For example, this [Table] says the following: A balance sheet has two [Axis], a "Scenario" and a "Class of Stock". Those two [Axis] apply to every concept within [Line Items] of that [Table]. Opps! The concept "Cash and Cash Equivalents" has a class of stock [Axis]. Yes, that is what the [Table] says. More on this in a moment.
[Table]s are connected to other [Table]s: For example, summary information is connected to detailed information such as this line item from the balance sheet which also exists within the disclosures. This is a business semantics, not a technical idea. The disclosures provides details of the summary item which appears on the balance sheet. Yet, in the example shown, the concept inventory is shown in a [Table] on the balance sheet, but it is not in a [Table] in the disclosures. This brings us to another issue, which we will cover next. But, in many cases different concepts are used to express exactly the same business concept used within the summary information and as the total of the detailed information and no real connection understandable by a computer exists.
Some things are [Table]s, other things are not: Basically a multidimensional model is mixed with a non-dimensional model, not a good idea. In the case of inventory above the same concept is used in both the summary balance sheet and in the detailed disclosures and the connection is clear. One reason this is bad is that XBRL Formula works either with a dimensional model or with a non-dimensional model. Mixing the two causes serious issues. To work around this to a degree XBRL Dimensions "default dimensions" was used to hack a connection and to try and get this to work correctly. Another way of looking at this is what if everything were a [Table]? One could be explicit about [Axis] (rather than implicit) and there would be now issues relating to mixing a dimensional model and a non-dimensional model.
Sometimes dimensions are an [Axis] other times dimensions are items: Here on the balance sheet, Property, Plant and Equipment is an item, as is Land and the other classes of PP&E. But here in the disclosures, Land and other classes of PPE are members of an [Axis]. Why the difference?

This is only a taste of some of the issues relating to [Table]s. These will become more clear as detailed tagging of the disclosures begins to take place.

So now we circle back to the beginning of our discussion of hypercubes (i.e. [Table]s). An understanding of the multidimensional model, an understanding of how XBRL Dimensions works, an understanding if data modeling, and an understanding of the financial reporting concepts being modeled are necessary to model the US GAAP Taxonomy correctly. Likewise, an understanding is also necessary to build SEC XBRL filer extension taxonomies correctly.

In some areas the US GAAP Taxonomy is well modeled and a good example of how [Table]s should be constructed. In other areas, [Table]s are not modeled well. There are many reasons for this that I will not get into. Three big contributors to the issues of the US GAAP Taxonomy are:

An inapproprate obsession on presentation of information rather than modeling the data correctly. What does not seem to be relized is that if the data model is correct the presentation is easy to model. But if the data model is incorrect, one may be able to present the information correctly but you cannot model the data correctly.
Mixing a dimensional model and non-dimensional information. This leads to having to be implicit about certain information such as belonging to the consolidate entity. It also leads to misuse of default dimensions in the US GAAP Taxonomy and to issues making XBRL Formula work correctly (because XBRL Formula supports either the dimensional or non-dimensional taxonomies, not a mixture of the two)
Insufficient understanding of how hypercubes work and of the multidimensional model by the majority of business users modeling the US GAAP Taxonomy.

All of these issues can be addressed and corrected. The first step to doing this is for more business users who understand the domain of financial reporting and what the semantics of the US GAAP Taxonomy SHOULD be saying to see what it is currently saying. This will be seen within the SEC XBRL filings. The next step is adjusting the taxonomy to say what the domain users really want it to say.

These [Table]s, hypercubes, the multidimensional model and such may be challenging to understand and it may take an investment in time. I know that this was very challenging to me and it took a while to grasp and I am not saying that I grasp everything perfectly; I still have a lot to learn. However, you have to admit that there are pretty good questions and observations.

The payback for business people understanding this is easier to use software. Once business users realize that is going on here, they will be far better equiped to tell software developers what they need from software applications.

The really good news is that the US GAAP Taxonomy is not as complicated as string theory where their are somewhere between 11 and 14 dimensions one needs to wrap their heads around.