Digital Financial Reporting

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 the first installment of a series of posts which I am going to make relating to rendering XBRL. When I say rendering, I am talking about both the output of XBRL and the input or the tool used to create the XBRL and the information the XBRL represents.

I have been fiddling with how to render XBRL information for years. It is actually quite easy to render XBRL. This was created by applying a style sheet to the XBRL instance which generated XSL-FO which was then sent to an FO processor which generated PDF.  You can see more information about this here.

The problems with that rendering are the following:

1. It is a "one off" rendering, meaning that the rendering process works only for that particular XBRL instance.  This is not a good thing for a number of reasons, keep reading.
2. The typical business user cannot create that rendering, at least not using the tools which exist today.
3. The rendering is not "interactive" in nature, meaning that you get ONE format, what you see.  The user cannot reconfigure the rendering if they desire to see the information formatted in a different way.
4. The rendering will not handle extensions.  If someone adds an extension, it will simply not show up in the rendering which is clearly not acceptable.  Rendering static forms is basically a cake walk.  It is the dynamic forms of information which make use of XBRL's extensibility which are the challenge.

So what is the answer?  Inline XBRL?  In my view, inline XBRL is little better than the PDF version above.  It has pretty much the same negative characteristics.

This is how I see things.

• The goal:  In my view, the PDF type rendering is a good starting point for communicating the goal.  Basically, if you want to replace what you have today with something else, you need to meet all the needs being met today, plus more.  So, this is what a business report commonly looks like today (I am using a financial statement).
• How to get there: If you take a look at the business report above you will notice that what it is, is lots of little tables of information strung together in the form of a report.  To show this, what I did was take the information and put it into Excel.  I then created an Excel pivot table for every piece of the report.  That spreadsheet can be found here.  There are two sheets for each table.  The first is the actual pivot table, the second is the data which drives the pivot table.
• Interactive information: This is a prototype of the theoretical goal in my mind.  All I did was to take the pivot tables from the bullet above, take a screen shot of each, and put them into a Word document and print the Word document to PDF.

Now, it would be nice if Excel pivot tables rendered the XBRL information better, but they don't for two reasons.  First, I am no expert in Excel.  You can probably get this better, but you will not be able to get it exactly how you want it because of the second reason. The second reason is that Excel pivot tables (as most of the multidimensional tools that I have seen) are optimized for (a) numbers and (b) aggregation of those numbers.  Maybe there are ways around this, but I have not been able to find them.

So, what is the answer?  Well, that is the $64,000 question.  This is what I am trying.  The first thing you need is use cases and I have been nurturing a set of use cases for a number of years.  I have broken these use cases into three sets:

• Metapatterns: This is the essence of what needs to be achieved.  This condenses the business use cases down to their essence.  You can distill all the business use cases into one of these metapatterns.  Here is this set of use cases: http://www.xbrlsite.com/Demos/Metapatterns/2009-03-14/
• Business use cases: These are actually the same thing as the metapatterns above, but packaged differently.  They are more along the lines of business use cases, easier for a business person to get their heads around.  But, there is nothing in this set which the meta patterns does not address.  Here is this set: http://www.xbrlsite.com/Patterns/2008-04-18/
• Comprehensive example: This is really the starting point from above, the goal.  This looks like a financial statement.  But what it really is, is the set of business use cases put into the form of a financial statement, again, so it is more understandable to business people. Here is this set: http://www.xbrlsite.com/examples/ComprehensiveExample/

(Keep in mind that these three sets of XBRL taxonomies and XBRL instances are about two years old and have helped me get to where I am today in terms of my thinking about rendering XBRL.  I need to make some adjustments and corrections to these files to better tune them to my existing ideas.)

This is a work in progress, but what I have tried to do is build a tool to render the XBRL information in a form which would be usable by humans.  This little Excel tool reads each of these sets of XBRL instances and XBRL taxonomies above.

Now, there are two important ideas to understand here.  The first is the notion of "shape".  The second is the notion of "flow".  Read the two links to blog entries which explain these two ideas.

For now let me summarize by saying this:  It is impossible to have a great rendering tool and a poorly constructed XBRL taxonomy and get what you will desire.  It is likewise impossible to take a well constructed XBRL taxonomy and use a poorly constructed or poorly designed rendering tool and get what you want.  It takes two things to enable what most business users will want:  a good XBRL taxonomy and a good tool which leverages the XBRL taxonomy information to render XBRL instance information. (I would love to be proven wrong.  If you have a tool which can render these small taxonomies in a manner that a business user will be happy with, please let me know.  Until that time, I will assume that I am correct.)

I am going to stop here for now.  If you want to follow this thread of thoughts relating to rendering XBRL, I encourage you to thoroughly examine the metapatterns, business use cases, and the comprehensive examples shown above.  Part of this is having a look at the sets of XBRL instances and XBRL taxonomies via the little Excel tool.