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

One of the most misunderstood aspects of the US GAAP Taxonomy and in SEC XBRL Filings is the [Table]. This blog post is a step toward de-mystifying the [Table] and showing that it is the solution to making the US GAAP Taxonomy and SEC XBRL Filings easier, not the cause of complexity. One major cause of complexity of SEC XBRL filings is the inconsistent use of [Table]s. This inconsistency is caused by a lack of understanding of the multidimensional model by most business users. Further, the multidimensional model is used by business intelligence systems (BI) and performance management systems (PM) which are becoming increasingly popular. BI and PM are part of a larger trend toward model-based business reporting. It is increasingly important that business professionals understand the multidimensional model if only to help software vendors appropriately hide that model from business users in their software applications.

Here are two resources which can be used to further study this topic. This PDF provides more details for the information summarized by this blog post. This basic example of an SEC XBRL filingcan be used by those who have the intellectual curiosity to dig into the details and further explore this material.

As Ralph Kimball states, the principle attraction of the multidimensional model is its simplicity:

The central attraction of the dimensional model of a business is its simplicity.... that simplicity is the fundamental key that allows users to understand databases, and allows software to navigate databases efficiently

So if the attraction of the multidimensional model is so simple, then why is the [Table] of the US GAAP Taxonomy and SEC XBRL filings so complicated? The US GAAP Taxonomy Architecture, section 4.5, states how a [Table] is implemented. That is not very helpful to business users creating SEC XBRL filing. It is not intended to be helpful to those business users, it is intended to be helpful to software vendors building software which is used by business users.

Here is why [Table]s are so complicated and how to get rid of the complexity:

Inconsistent use of [Table]s: The first question one might ask is, "When should I use a [Table] and when should I not use a [Table]." The US GAAP Taxonomy sometimes uses [Table]s and other times does not. Yet everything is in essense a [Table], be the [Table] explicitly constructed as a [Table] or be the [Table] implied. Every piece of information articulated in an SEC XBRL filing has at least two dimensions: the entity identifier and the period. A [Table] does nothing more than add one or more additional dimensions. If everything in the US GAAP Taxonomy where either modeled explicitly as a [Table] or if the taxonomy was better organized so that people could realize that all the things which are not modeled as [Table]s really are [Table]s anyway, then the [Table] would disappear into the background within software applications. Focusing on the XBRL Dimensions syntax is noise and distracts one from seeing the real opportunity to make things easier for business users.
Software not leveraging the US GAAP Taxonomy's consistency: Current software applications for SEC XBRL filings don't leverage the consistency of the US GAAP taxonomy and expose [Table]s to business users at the XBRL syntax level, rather than hiding XBRL. This is do, in part, to the US GAAP Taxonomies inconsistent use of [Table]s. Another reason for this is that structure of the US GAAP Taxonomy and documentation does not help see the consistency. If you don't understand the leverage, wait until you see software that does leverage the consistency. Then you will get it.
Few large general [Table]s rather than many specific [Table]s: Many of the [Table]s in the US GAAP Taxonomy are huge. Take the Derivative [Table] as an example. Many specific use [Table]s would be easier to use than the fewer general and larger [Table]s.
Mixing presentation characteristics and business semantics: The best example of this is the Statement of Changes in Equity.
Improper [Axis]: The Statement of Changes in Equity is likewise a good example of improper [Axis] used on [Table]s. The balance sheet is another. This blog post discusses the balance sheet [Axis]. (Or simply look at this image and this imagewhich shows what [Axis] SEC filers are actually putting on their balance sheets.) The balance sheet in the US GAAP Taxonomy says, by having a Class of Common Stock [Axis] , that every balance sheet line item is associates with a class of common stock which is simply not the case.
Confusion caused by default dimensions: What default dimensions actually does is confused by two things. First, the mix of concepts being used in [Table]s and not in [Table]s. This is not only a very bad idea but there are known bugs in XBRL which can surface as a result of this. The clearest example of why this is a problem is the fact the XBRL Formulas has two explicit models: dimensional and non dimensional. What is the US GAAP Taxonomy? It mixes the two. Second, there was a lot of pressure to make the use of XBRL Dimensions and the definition linkbase optional to "make things easier for business users". This thinking is misguided. This Excel spreadsheet shows the dimensions information for this Basic Example of an SEC XBRL filing. Compare the Excel spreadsheet to the XBRL instance. The Fact Table shows the same thing.
General confusion, misinterpretation, and erroneous "projection" as to how [Table]s actualy work: It may be the case that one wishes that [Table]s worked in a certain way. Or, one may believe or project into [Table]s how they might work. It is really not that hard to understand how they actually do work: testing. For example, this Comprehensive Example and this Comparison Exampleshow quite clearly how XBRL actually works. If different software applications reacted to XBRL [Table]s in different ways, we have bigger problems. But, that is not the case. The examples respond the same in the four different software applications I tested the examples against. XBRL is consistent. Users, who generally don't bother to test, reach conclusions as to how XBRL works without the benefit of actually testing. How does one solve that problem? Test.

You can already see that SEC XBRL filers are solving the problems of [Table]s. As you can see on this blog post back in March 2010, one filing agent is putting everything in the taxonomy into [Table]s. This viewer toolhelps you see that the company extensions are modeling everything as a [Table] and consistently with the US GAAP Taxonomy architecture. I disagree with the use of the "Statement [Table]" as the actual hypercube for every [Table]; I personally believe that each hypercube should be unique and have a unique name. But, the approach of making everything a [Table] with one hypercube is better than mixing the dimensional and non dimensional models.

This can be hard to explain at this point, one has to dig into the details to see that what I am seeing is true. But this will become easier and easier to see as more and more software vendors do what the software vendor on the link above did. Once that happens, and it will, things will become easier for business users and understanding the [Table] will be significantly easier.