Digital Financial Reporting

OK, so I cannot figure this out.

In their 2008 magic matrix for BI platforms, Gartner does not mention XBRL (Magic Quadrant for Business Intelligence Platforms, 2008).  This was published in February 2008.

In a research publication dated in April 2008, Gartner touts XBRL (XBRL Will Enhance Corporate Disclosure and Corporate Performance Management).  There are two particularly interesting statements in this publication, interesting to me at least:

By 2011, the use of XBRL to deliver real-time financial information to business managers will be cited by CEOs in management surveys as a Top 5 contributor to their organization's success in managing the business.

And:

Perhaps more importantly, the XBRL specifications (called "taxonomies") handle the complex financial semantics (such as assets, liabilities, income, expenses, debits and credits) that cause problems when reporting financial data using business intelligence (BI) reporting tools. This means that it is easier to build sophisticated financial reports, such as a profit and loss statement, using XBRL. For example, it is estimated that the average Fortune 1000 company used more than 800 spreadsheets to prepare its financial statements for regulatory reporting. XBRL offers a solution to significantly reduce this number and improve internal controls over financial reporting.

Now, I cannot figure out if Gartner is saying that in some cases XBRL is better than BI solutions.  I doubt that this is the case (that they are saying it, or that this is true).

If you search through that magic matrix, you see the term OLAP used all over the place.  OLAP is a major enabler for BI, seems to me.  I personally see a connection between OLAP and XBRL.  OLAP is a way of organizing data/information.  XBRL is a way of expressing and exchanging information.

So, there is some sort of connection between OLAP and XBRL.  There is a connection between OLAP and BI.  It seems to me that there is a connection between BI and XBRL.

What I am trying to figure out is two things:

1. The connection between BI and XBRL.
2. The connection between BI and financial information.

Be sure to check out this blog post:  XBRL and OLAP.

And this is somewhat interesting also.  I became aware of this blog a few weeks ago.  The author of the blog stated that he was changing his focus from BI to XBRL.  Maybe this is nothing, but it is a bit curious.

More to come...

I have been doing some thinking about what I am calling "XBRL repositories".  What is an XBRL repository?  Well, for example, the SEC's new IDEA system will be an XBRL repository.  Another SEC repository is the collection of XBRL instance documents which have been submitted as part of their Voluntary Filing Program for XBRL.  The RSS feed to these filings can be found here.

There are a number of these XBRL repositories and there will be additional such repositories as XBRL is used more.  An XBRL repository might be:

• A single XBRL instance document which contains information.
• A collection of one or more XBRL instance documents.
• A collection of one or more repositories.  For example, say 50 different state repositories all somehow weaved together into one collection of data.
• A collection of any number of XBRL instance documents which are contained in some sort of database (relational or XML or maybe even an XBRL specific database) which, when accessed LOOK like an XBRL instance document, but they are really dynamically created based on some set of parameters sent to the database.
• Something else which I have not thought of.

I even created a mini repository of XBRL information.  You can see an RSS feed which points to the information here.

What does a repository have in it?  Well, my repository has the RSS feed which points to the instance documents within the repository, the instance documents themselves (there are 5 in my repository), and the taxonomy which supports the information contained in the instance documents including business rules.

I created a little Excel application which grabs information from my little repository for the purpose of figuring out what one needs in order to use such information.  I discovered some interesting things.

First off, it is easy to grab one instance document.  You simply point your application to that instance document.  But what if you want to use more than one instance document.  Well, no big deal.  You just have to create something like the SEC RSS feed which points to the instance documents.  And this is a bit of an issue.  There is no real standard way of pointing to a set of instance documents.  The SEC used an RSS feed.  Even if someone else used an RSS feed to point to instance documents, there is nothing to help make sure that an off the shelf XBRL analysis tool can read and use two different RSS feeds implemented by different providers of XBRL data.  For example, can you access the SEC data and say the FDIC data with the same tool?  No, you cannot.

Second, let's imagine that the first problem was solved and you could access the SEC and FDIC data with the same tool.  Will the application be able to use the data?  I doubt it.  The SEC and the FDIC are both making use of the global standard XBRL, but they have architected their data in two totally different manners.  The profiles are different.

Third, consider notion of a "file" or "document".  Look at the SEC Voluntary Filing Program files.  Take a look at a company who has been filing for a number of years and you will notice that data is duplicated.  For example, "Net Income" for say 2006 is reported two times.  First, it is in the current period column of the 2006 income statement file or document; but it is also in the 2007 file or document in the prior period comparison information.  The information is duplicated using this "file" or "document" based approach to filing information.  As compared to filing information one time and then when rendering the information for use, pulling the information from the appropriate place and putting the rendering you desire together.  This is bound to cause problems (i.e. two versions of the same information) particularly when you consider restatements and reclassifications of the financial information.

I will come back to this later, but for now, these observations might help people think about what a repository of XBRL data needs to be able to deal with.

I have been doing some reflecting on what XBRL really is.  I summarized this on the page What is XBRL? on this blog.  I won't get into that definition here, you can go read that page.  I will just tell you what I think XBRL is and then pick up from there.  If you don't agree with the definition of XBRL, I would encourage you to point me to a better definition/explanation or to create a better one yourself (and then point me to it).  I am simply trying to understand and help others understand.

So in summary, the best definition of XBRL in my view is the following from Wikipedia:

XBRL (eXtensible Business Reporting Language) is an open standard which supports information modeling and the expression of semantic meaning commonly required in business reporting.

It is unfortunate that I cannot point you to a better explanation of XBRL on the XBRL.ORG web site, but I really cannot.  Here is what XBRL International says XBRL is.

So, XBRL is about information modeling and exchanging information as opposed to data.  XBRL is about business information exchange.  It is not about only financial reporting, which is what a lot of people think because much of the early work relating to XBRL taxonomies had to do with financial reporting taxonomies.  People also think XBRL is about only financial reporting because XBRL was started by the American Institute of Certified Public Accountants (AICPA).  But, it is not about just financial reporting.

Well, so is XBRL even limited to business reporting?  It seems to solve a lot of problems relating to general problems of exchanging information (as opposed to data).  XBRL can help turn data into information in a global standard way.  It does this by adding context to data.

Let's take a step back here:  data, information; what is the difference?  Let's add two other terms here to round this out:  data, information, knowledge, wisdom.  Some definitions from various sources:

• http://www.systems-thinking.org/dikw/dikw.htm
• http://otec.uoregon.edu/data-wisdom.htm
• http://knowmgt.blogspot.com/2007/07/difference-between-data-information.html
• http://en.wikipedia.org/wiki/DIKW

Again, Wikipedia offers a nice concise definition of these terms, the DIKW model:

Data is the most basic level;
Information adds context;
Knowledge adds how to use it; and
Wisdom adds when to use it.

You can think of the difference between information and data as you read about these for terms, but let's move on.

So, what is XBRL, really?  Is this something that is meant for technical people or for business users?  Well, personally, I have always been into all this for the business user.  Right now, technical people can make use of XBRL well.  This can be seen with the successful implementations of XBRL by the US Federal Deposit Insurance Corporation (FDIC), the Committee of European Banking Supervisors (CEBS), Japan FSA, the upcoming use of XBRL (interactive data) by the US Securities and Exchange Commission (SEC), the Dutch Government, the Australian Government, and so forth.  Technically, all this works and it can be made to work, if you are a technical person.

But what about a business person?  Can one business person exchange information with another business person using XBRL?  At the XBRL International Conference in Washington, DC a few weeks ago I ask the question if that is considered a use case for XBRL and I received a definitive "yes" which was very encouraging.  However, for the life of me I see no real tools for doing that today.

Also, if you look at the list of who is implementing XBRL (two paragraphs up) you will notice that the list is all regulators.  Is XBRL a tool for everyone or is it a tool for regulators?  Seems like regulators are getting a lot of really good technology for some fairly good prices. 

But what about the business user?  Well, I guess business users will get to file with the regulators.  I guess what is business users making use of XBRL.  But, that is not what I personally want to get out of XBRL.

So what is XBRL, really?  Are the issues pointed out above due to the point XBRL is within its life cycle?  Clearly we are pretty early, even though XBRL is almost 10 years old.  Maybe it will be this use by regulators which eventually pulls in the business users because they will be able to better see what XBRL can be used for by having to file with regulators.  It is certainly the case that the US SEC's potential use of XBRL has provided motivation to experiment with XBRL, thus seeing how it may be useful for other things internal to a company, rather than simply a required format required by regulators.  This was certainly the case for United Technologies.  UTC started experimenting with XBRL because they saw a potential mandate from the SEC, but they discovered benefits for their internal reporting.  That is business users being assisted by technical people to meet the needs of the business user.

For me though, I am still looking for the ability of one business user to exchange information with another business user, internally or externally to their organization.  It needs to be with minimal help from technology people (other than buying software) because having to go through a technology person adds additional time and cost to the equation.  I mean, that is why the PC and a spreadsheet was so great; no more going to the "glass room" to get that report you needed.  You just did it yourself.

For me, that is what XBRL is, or needs to be.  It is not there yet.  It does seem to be moving in that direction.

What do you think XBRL really is?