Digital Financial Reporting

This is my next iteration of what I have been calling an interactive information viewer:  Interactive Information Viewer.

(Here are blog posts which discuss and can take you to prior versions of this prototype:  First version, Second version.)

In this most current version I have incorporated many, but not all ideas yet, from this blog post relating to the best ideas for getting the most out of your XBRL architecture.  I guess I started on this idea of what I am now calling an interactive information viewer when I was working on the US GAAP Taxonomy.  I took what I learned from that process, took it further, and came up with XBRLS which is basically a profile of XBRL. Additional ideas came from the COREP taxonomy and from the FINREP taxonomy.  What I called a "neutral format table" had evolved into "interactive information viewer".

Fundamentally, I am stil pursuing the goal of a business user defining a data model (dynamic model where extension is an option, not a static form), articulating information based on that data model, exchanging that information with another business user within an automated process.  There can be zero ambiguity, the semantics need to be understood the same by both those creating and consuming the information, the information needs to be readable by a human and by a computer AND all this needs to be done by business users...no IT department assistance at all.  Clearly this cannot be done unless there is off-the-shelf software on both ends of this exchange and that software needs to be operated by a business user.  But before that software can be built, we need to know what is needed to make all these moving parts work together effectively in order to achieve this goal.

The SEC implementation of XBRL offers a lot of clues as to how to make this work.  It seems to me if the SEC can make this work (i.e. business users filing financial information with the SEC) then I should also be able to get this to work.

The term "interactive information viewer" comes from the following.  First, the SEC used a term "interactive data".  I borrowed from the SEC but changed the use of data to information because XBRL is really more concerned with information than data. (See this blog post for more information on that difference.)  The "viewer" part comes from the notion of the way you look at business information is more how a Microsoft Excel pivot table might work or how a business intelligence tool works.  Basically, there are two things that you gain.  First, the information on the report is not fixed, the user can move it or reconfigure it.  Second, you loose the two dimensional nature of paper meaning that a computer can present things in more than two dimensions.

So in this prototype, imagine you could reconfigure the columns and rows or take a column or row and move it to the "Slice" section in the upper left hand corner.  Again, much like an Excel pivot table or business intelligence application.  There are three things which make Excel pivot tables and current BI applications not do the job here: (1) They don't understand XBRL, (2) They like the aggregate things (i.e. the OLAP piece), (3) They don't handle text well (i.e. they are optimized for numbers, not numbers and text).  These things will be worked out I am pretty sure.

So, an interactive information viewer is configurable in that the consumer of the information can "pivot" things to see them how they desire to see them.  This blog post discusses more of the characteristics of such an application.  Here is a demo/tutorials of one software application which shows you some of the basic ideas here (see the "The Basics of Quantrix Modeler" or the video tutorial on the left side).  Remember, here they are only dealing with numbers; but imagine if you could use numbers or text in the models.

The key here is the XBRL taxonomy.  All this is very, very possible today...but the problem is that every solution is proprietary in that you have to use the data format of those applications.  So, you cannot exchange the data between applications.  If business users can agree on one way to create a taxonomy and if ever software application supported that format, then we would have what we need.  XBRL is capable of doing this, but XBRL "out of the box" is just too flexible, there are too many options. So, we just need to agree on a subset, a profile, of XBRL which is 100% compliant to the XBRL specification.  Then enough software needs to support that profile.