Digital Financial Reporting

This is yet another iteration of the interactive information hypercube viewer that I keep fiddling with.  See this blog post for information on prior iterations.

This version is a major step forward because it actually works!  You can grab information about this prototype here. Read that overview document to understand what is going on.

Note that this version implements the financial reporting logical model (draft) that the XBRL International Taxonomy Architecture Working Group is working on.  The point of the prototype is to test that logical model so that I can provide input to that group.

I would encourage you to grab the Excel prototype application and check it out.  See that overview page for a link to a ZIP file which contains the prototype. If you fiddle with the application what I am hoping that you see is that the XBRL instance information renders quite nicely and is definitely very readable by humans. The rendering is driven by two things: the XBRL instance/XBRL taxonomy DTS (discoverable taxonomy set) information and logic in the Excel application which takes advantage of the financial reporting logical model.

This works even better than I had anticipated. I always thought the rendering would be 98% of what one might want, the user would have to do 2% of the work to adjust the slicers, rows, and columns.  But, I was able to get 100% of what I wanted automatically.  The roll forward is not quite what I desire but I know how to fix that without too much effort.

Don't be fooled by what might appear as the simplicity of what you see.  This is not a simplistic implementation of XBRL. In fact, it is quite robust. The US GAAP Taxonomy and SEC XBRL reporting can follow this model. The model is simple, not simplistic.  That is the idea: make it simple and easy to use.

I am getting more and more evidence and insight into what an XBRL application for financial reporting can and should look like. I am seeing that it is very possible to hide XBRL in the background.

The XBRL International Taxonomy Architecture Working Group is looking for software vendors to experiment with the financial reporting logical model.  If you are interested, send me an email or contact XBRL International for more information.  This is a great opportunity to not only experiment and learn more about XBRL.

Well, it seems that there was in fact an error in the Census data set which I thought might have existed as I mentioned in this blog post.

You can see the Census Bureau's revised Excel data set here.  (Or you can grab it from the State Government Finances page here. See the "Summary Table" [Excel, 43KB] link on that page.)

So let me summarize the chain of events:

1. I was creating an XBRL prototype I called the State Fact Book. The primary purpose of the prototype was to test the differences between XML, XHTML, XBRL and RDF.  See this blog post for more information. Here is the actual analysis.
2. This spreadsheet shows the error. This screen shot also shows the error.
3. For this prototype I used some publicly available data.  Part of that happened to be some data from the US Census Bureau (the link above).
4. In creating the XBRL, of course I wanted to make sure I was doing everything correctly, so I created several XBRL formulas to verify that I was not making any mistakes.  Here is the XBRL Formula file.  Here are the human readable rendering of the validation results. This was generated by the UBmatrix XBRL processor which supports XBRL Formula. Note the "notSatisfied" results.
5. Someone in government read my blog post and decided to investigate if this was in fact an error.  They wrote a letter to the Census Bureau.  Here is the letter.
6. The letter and this story was reported in NextGov.
7. This revised data set clearly shows the revision to the US Census data.

Could have this error been discovered using Excel formulas?  Sure it could have been discovered.  But, there are no formulas in that spreadsheet data set.  A business rule in a global standard format could have been created which is useable by both the creator of the data (here the Census Bureau) and the consumer of the data (in this case myself or anyone else using that data).  The business rules in a global standard format does not limit your use of those rules should you not use Excel.

The points here are as follows: (a) if you publish information and that information has numeric relations, it is important to publish business rules that both document how the information adds up and proves that the information adds up; (b) this is what XBRL Formula is for and as you can see it does work; (c) the key advantage of the global standard XBRL Formula is that the business rules are not application dependent, but rather can be exchanged between business systems independent of the system.

There is no intent here to beat up on the U.S. Census Bureau.  It just so happened that I stumbled upon this error because I wanted to be sure my system was not reporting incorrect information.  In my years of creating XBRL demos, I have run across this type of error before in SEC filings.  These information sets are complex. Other errors exist in publish information sets, you can count on that.  XBRL and XBRL Formula when properly used can improve data integrity.

In a blog post a few weeks ago I pointed out how I discoved a possible error in some U.S. Census data.  An update.

A letter was sent to the Census Bureau pointing out this possible error. Also, NextGov picked up on this in a story.

No word from the Census Bureau as of yet but the story says they acknowledge receiving the letter and is looking into this matter.