Digital Financial Reporting

There is this feature of XBRL which I refer to as "hypercube jumping". You can experience hypercube jumping, at least an initial instantiation of it, by using a software application which supports this feature such as the Firefox XBRL viewer add on, a properly created XBRL instance, and a properly modeled XBRL taxonomy. If you want to actually walk through this, this blog post will help you do that.

What I am starting to recognize that the term hypercube jumping is likely not the right term. Hypercubes are only a piece of the puzzle and in fact, you really don't even need explicit hypercubes at all but this works with the implied structures within XBRL as long as you model your meta data correctly.

Are you lost already?  Well, I probably won't help you grasp all this; the fact is I am trying to figure it all out myself.  A lot of people refer to the things I am talking about as "drill down" or "aggregation" of information.  But it seem to me that it goes way, way beyond that.

To help you visualize, consider the graphic below.  This is a tesseract. Look at this graphic and think about Excel pivot tables.

3D rotating tesseract (from Wikipedia)

Paper has only two dimensions, rows and columns. Add a third dimension to that and you get a cube. You can only view a three dimensional cube on a two dimensional surface by holding one of the dimensions static like what a slicer does in say an Excel pivot table or by repeating sets of rows and columns multiple times within a paper report. Now a computer screen is not limited to two dimensions so it can display three dimensions with no problem.

But what if you have four dimensions? Or heck, what about ten dimensions?

What does all this have to do with hypercube jumping or drilling down into data? Well, I am not totally sure but what I seem to see is this.  If you look at the graphic above, you will note that the object fits together, you don't have stray lines ending nowhere in space and things like that. What I am seeing more and more is that it is all about the data model.  If you get the data model correct, you can do all sorts of interesting things.

Imagine having a financial report which "looks" like the graphic above.  (Work with me here and use your imagination.) Imagine being able to pivot, slice, dice, drill down, drill across, drill side-to-side from one place in a financial report to another place in a report.  Imagine that your "report" is actually a set of financial reports for an entire industry sector and you can cross the bounds of the report or the entity because you are not limited by the physical bounds of paper or the limit of two dimensions which limits what paper can express.

Syntax is really not that important, as long as you can easily convert and move form one syntax to another. There have been never ending debates about things like the pros and cons of things like tuples and dimensions. During those debates a minority of people say that those things don't matter.  I am starting to grasp what they were talking about.

Any accountant or financial analyst can tell you that there is a rich set of relations contained within and between the many pieces which make up a financial report. Leveraging these relations will change the way we interact with this information.  The first step is articulating the many relations in a way that a computer can easily and properly grasp.  XBRL is one syntax for doing this. Proper data models is what enables things like hypercube jumping.

All this will be easier to grasp when more software exists to see these ideas in action.

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.

I have had several posts relating to what I call the "interactive information hypercube": here, here, here. The idea of interactive information hypercube grew from prototyping I was doing while testing ideas which I wanted to get into the US GAAP Taxonomy Architecture.  I was successful with many, not as successful with others. Frankly, I learned a great deal from the experience of working on the US GAAP Taxonomy Architecture group. (Go look at the authors of the document, those are XBRL heavyweights!)

I took what I learned from helping to create the US GAAP Taxonomy Architecture and took that to the next level and created what I called XBRLS with another XBRL heavyweight. Those ideas where summarized in the document XBRLS: How a simpler XBRL can be a better XBRL. In that document I called what evolved into the interactive information hypercube idea "neutral format tables".  These have also been referred to as "generic tables" and "general table format" among other things.

For my State Fact Book Prototype I created yet another iteration. This one actually works to a degree. You can get to that prototype from that State Fact Book Prototype link or this is a direct link to the prototype created in Excel. Here is documentation which walks you through the prototype.

Two other influences on this interactive information hypercube is the Interoperable Taxonomy Architecture (ITA) work I am doing with the XBRL International Taxonomy Architecture Working Group toward expressing a logical model for financial reporting. This UML model and mind map of the financial reporting domain are my input to that group.

I came up with the term interactive information hypercube in the following way:

• Interactive came from the SEC. I admit I stole that idea, it is a good one.  The SEC coined the term "interactive data". Heck, like Picasso said, "Good artists copy, great artists steal." But I did not agree with their use of the term data.
• I chose to use the term information rather than data because the hypercube are really about information, not data.  See this white paper Data, Information, Knowledge, and Wisdom to understand the difference.
• The term "cube" is used by the OLAP people, but hypercube is really a better term. A cube is three dimensional whereas a hypercube is n-dimensinal (any number of dimensions). Fundamentally, the flexibility of multidimensional model is what is important.  The ADAPT model and the OLAP Council White Paper. OLAP gets in the way as its focus is on aggregating numbers.  The interactive information hypercube can aggregate, but it does not have to.  Also, the interactive information hypercube handles text.  Most OLAP applications have a very difficult time handing text. In my view this is a limitation of business intelligence tools.

Keep all this in the back of your mind and use your imagination when you have a look at the prototype/demo. This is not a truly functional application, I took some short cuts which are explained in the documentation. I get more and more convinced that this is a good idea the more I fiddle with it.

If you look at a business report, such as a financial report, they are really a bunch of hypercubes strung together.  Here is an example of that I put together in 2007, stringing pivot tables together: PDF of a financial, same financial as Excel pivot tables.

You can achieve this today give the right XBRL taxonomy architecture.  The US GAAP Taxonomy is a big step in that direction but is still a little too inconsistent in the way it is built.  XBRLS provides better discipline in terms of how to structure your XBRL taxonomy.  Given the right architecture, rending seems both easy and it provides the "interactive information", the ability for the consumer to reconfigure the information and have it their way.

This is a nice little OLAP cube tutorial.  Remember though!!!  XBRL wants the "multidimensional model" part of business intelligence, it does not want the "OLAP" piece which focuses only on numeric content (because XBRL also deals with text) or the aggregation part (because not everything needs to be aggregated, it already could have been aggregated.

For more information, see the OLAP Council White Paper.