Digital Financial Reporting

When creating a prototype I stumbled across something of interest which helps to show XBRL's ability to detect possible errors within a data set.  I am not saying that this is, or is not, an error.  But it does look like an error. I am trying to determine what is going on and am trying to find someone in the US Census Bureau who can help indicate what is going on.

So here is the deal.  The US Census Bureau makes summary financial information available for the US States. See the 2008 Annual Survey of State Government Finances here. More specifically, see under "Downloadable data" the summary table in Excel.  That is an Excel spreadsheet containing what amounts to an income statement for each US State, and an aggregation of the information for the total of the states in the column "United States".

I was using that data to create a demo and when I ran the XBRL validation against my data, I got some errors.  I will walk you through that in a moment.  But, here is an Excel spreadsheet which shows what could possibly be an error in the data.  If you don't have Excel, this graphic also shows the possible error.  What is going on is the line item "Insurance trust revenue" does not cross cast (i.e. the numbers for the individual states don't add up to the total in the United States column). That same discrepancy exists within Total revenue, of which "Insurance trust revenue" is part.

Now, I am not saying definitively that this is an error.  But, one of two things is going on.  (A) It could be an error or (B) the fact that the number does not add up like all the other columns is not documented within the data set.  It seems logical that others using this data might have the same question as I do given that all the other line items add up and given that it seems logical that everything should add up.

So why was I able to discover this?  Well, for my prototype, I was using that state financial information.  I created an XBRL taxonomy and in that XBRL taxonomy I created business rules which both document how things add up and allow me to verify that everything does in fact add up.  These business rules come in two forms. First, a set of XBRL calculations which show how the income statement adds up.  Here is a rendering which shows this.  Now, this is easier for a computer to read in the actual taxonomy. The result of running the XBRL instance information through the validation generates this report. That report shows first, how things add up and second the fact that the numbers do add up correctly in each of the 50 state income statements and in the total fur the United States as a whole.

The second test I ran is to use the fact that the 50 states do add up to the United States total, basically the relations shown here.  I created an XBRL Formula to express this relation, you can see that here but it looks rather ugly and I have not created a rendering of this. Computers can read business rules expressed in a global standard format and generate something like this, called a formula trace, this on generated by UBmatrix's XBRL processor.

This business rule generates this report which shows the descrepencies in the numbers. Now, you see four errors rather than two because I added two line items to the data set which calculated the net revenues over expenses and another concept showing the net Insurance trust activities.

Here is the bottom line.  I don't know if this is really an error or not, but the more important thing is that XBRL can document whether the numbers are supposed to add up and if the, in fact, do when the data is made available.  This report shows that the numbers foot. This report shows if the numbers crosscast (admittedly, this could be formatted nicer to make it more readable).  These reports are generated in off the shelf software.  The metadata communicating that the information adds up (or not) is made available with the information itself.  Here is the XBRL instance. Plug that into any off-the-shelf XBRL enabled tool and plug the XBRL formula in, and you will get the same result (the software does have to support XBRL Formula of course, many do).  That is right, not only can you validate the information, but the validation is portable between business software applications!

You can still get the data and read it, just like the US Census Bureau provides in in Excel.  This tool can be used to extract information using a very simple Excel macro. No XBRL processor was used, but that would make writing the already easy to write code (I wrote it, I am a CPA not a programmer) even easier.  (Note that there are a number of different formats you can extract the data from, find the tab "Financial - XBRL".)