Digital Financial Reporting

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.