Digital Financial Reporting

Here is a link to a web page provided by the state of Texas.  The web page contains links to the financial reports of a number of the larger cities in Texas.  You can go to this web page, click on a link, and go read a financial report in the form of a PDF file.

The financial report is called a CAFR (Comprehensive Annual Financial Report).  I don't know the exact rules, but I believe it is the case that the approximately 88,000 state and local governmental entities within the United States are required to file this report annually with the US Census Bureau.

The state of Oregon undertook a project to experiment with expressing this CAFR report in an XBRL format.  You can obtain a copy of that study here.

Try and do a comparison of, oh let's say three different Texas cities using those PDF files.  Can it be done?  Absolutely.  All one needs to do is rekey the information.

The web page has a title "Transparency by Texas Cities".  You can clearly see how XBRL can contribute to transparency by making it vastly easier to get at the information within these types of PDF based financial reports.

Imagine if the financial information of all 88,000 state and local governmental entities were put into the type of system the SEC has created for public company financial information, their new IDEA system.  Here is a prototype of how using this information could work.

That would dramatically increase transparency!  Imagine the analysis which could be done, how the information could be used by economists and academics for all sorts of things, and imagine the view voters could have into the governments which spend their money.

Financial information of the agencies and departments of the US Federal Government could also be made available in this manner.

An article published by Government Technology, XBRL Ends Spreadsheet Hell, explains how XBRL ended spreadsheet hell for a department within the state of Nevada.  Kim Wallin, Nevada's controller says:

 "The goals were timely and accurate data, stronger internal controls, reduced costs, a standardized system of seamless data exchange, business processes and data elements. XBRL met all of those goals."

The article discusses two projects where XBRL was used to supplement what had been done with spreadsheets alone.  One project related to the tracking of grants and the other relating to debt collection.

In addition, the article says XBRL would be an "excellent enhancement" to a SOA (service oriented architecture, basically web services) business portal Nevada is looking at developing.

Imagine if every US state created an SOA business portal, as well as the US federal government! Or heck, every country creates an SOA portal.  Imagine both the efficiency of such a system and the transparency which could be offered to the voters to keep tabs on government spending.  Imagine the data economists could have to populate their economic models.

Several different parties are dancing around the idea of what the killer application for XBRL might be.  Consider these three sources:

1. Neal Hannon and W. David Stephenson, in their article What Recovery.gov Could Learn from TurboTax,talk about an application as easy to use as TurboTax which is pre-formatted and has a strong set of business rules running behind the scenes.
2. Philip Elsas gave a presentationat the University of Kansas 2009 International Conference on XBRL.  He discussed the idea of a "smart XBRL application", gave some examples of a Deloitte smart audit support application, and discussed the idea of a killer application for XBRL assurance.  He discussed how business rules (formulas) could be used and an off-the-shelf "builder based" application (similar to template driven).
3. Thomas W. Malone, Kum-Yew Lai, and Christoper Fry discuss ideas behind what they call
   "a radically tailorable tool" for cooperative work in a paper unrelated to XBRL, but whose ideas, I belive, are quite applicable to XBRL. In the paper this radically tailorable tool is configured by modifying four different types of building blocks.  Now, I don't think the building blocks outlined there are the right building blocks for XBRL (but then again, who knows), however the idea of building blocks is a good one.

A couple of things and then let me summarize my view of the characteristics of the XBRL killer application.  First, the idea of building blocks has been of interest to me and seemed to be the right idea for quite some time.  If you look at the XBRLS architecture document and the XBRLS Business Use Cases (see http://xbrl.squarespace.com/xbrls) you will see the notion of building blocks used there.  Part of these building blocks are the XBRLS meta patterns and the neutral format tables.  Another thing that really got me interested in building blocks was an application I saw during a parent/teacher's conference at my daughter's school of all places.  They used an application called Scratch (see http://scratch.mit.edu/).  The application lets its users use what remind me of Legos to construct programs.

Now, if you take all of this information from the wrong perspective, you will not see how all of these ideas combined to paint a picture of what really could be an interesting way to create business reports.  Another way to miss the point here is to be fixated on XBRL's physical model and not realize that the thing which could (a) make this work and (b) help realize the potential of XBRL and allow for the creation of a logical model which is a missing piece of the puzzle here.

This is what I think:

• TurboTax is the right target in terms of "ease of use".  Frankly, I think there are more elegant interfaces (such as Microsoft Money or Microsoft TaxSaver) but TurboTax is better known.
• But when you think of TurboTax, you need to think of the piece that you DO NOT see.  How do you think the folks at Intuit modify that application, adjusting it for changes to the tax code from year to year?  They either (a) have an application which allows them to adjust the forms and rules or (b) they have a whole lot of programmers working at really low levels, changing the application at the code level. I speculate they have an application which they use to make modifications and then they "compile" the application providing the updated forms for the new year.
• That piece you don't see is the "radically tailorable tool" piece of this puzzle.  You can look at this as pre-formatted templates which users can adjust, allowing them for DYNAMIC business reports, not the STATIC forms of TurboTax.  Users can change the templates.
• But the templates are not infinitely flexible in all directions.  That would make the application so hard to use that it would be useless.  The application highly flexible, within a very rigid framework.  The user does NOT work at the XBRL level, they work at the logical model level, using a fairly small number of building blocks to configure the application.  Again, users do NOT work at the XBRL physical level, they work at the logical level.  That is why a logical model is needed, because XBRL needs ONE logical model, not one logical model per software vendor which would hinder interoperability between software applications which is sort of the entire point of XBRL in the first place.  It is this logical model which hides the physical model of XBRL.
• Part of these building blocks is a set of rules which makes errors literally impossible.  This is done by writing rules to say what is RIGHT, not to try and detect everything which can go wrong.  This is a HUGE difference.
• Users only interact with building blocks.  All the complex stuff is dealt with below the building block level.  This is created by really smart programmers who specialize in this sort of thing.
• The application is integrated with the internal audit process.  How could you possibly create a correct report if you cannot prove to yourself that the report you are created is correct?  Now, there may be additional internal audit functionality and even external audit functionality.  The application is integrated with that also, using XBRL.  External audit processes audit the same data as the internal audit processes.  The only real difference is that external auditors are "arms length" and perform work that helps ensure that no fraudulent activities are occurring, checking to be sure that policies and procedures were actually followed, etc.

Well, that is what I think.  Maybe I am right, maybe I am wrong.  Do you have any better ideas?  If you do, please comment to this post.

Perhaps a nice white paper to write might be something like "Blueprint for the XBRL Killer App".

Someone pointed me to Yahoo Pipes which is one of the most clever and interesting things I have seen in a while.  The general overview is that you can use pre-built widgets to string together sets of data, do things like filter the data, and end up with some resulting output set.  There is a bit of an explanation on Wikipedia.  But, the best way to understand it is to watch this video which shows you how to build a pipe, or go grab an existing pipe and reverse engineer it to see what it is doing.

It would be great if there were an XBRL widget so you can easily add XBRL instances and XBRL taxonomies to your data sets.

I have been creating XBRL taxonomies for quite a few years.  I was on the team that created the very first US GAAP Taxonomy which was released in 2000 (I even created my own taxonomy creation tool using Microsoft Access), I spent about three years creating several different iterations of the IFRS-GP taxonomy, I participated in the meeting to determine the architecture for the COREP taxonomy, I was on the team which created the 2008 edition of the US GAAP Taxonomy which the SEC paid for, and there were lots of other taxonomy projects in between where I participated either directly or indirectly (i.e. comparing notes with others in order to learn as much as I could about creating taxonomies).

In creating taxonomies, I have probably made every mistake there is to make.  Some of the things we did not even realize were mistakes when we were building taxonomies, eventually revealed themselves as mistakes.  Very good information about this journey can be found here.  Information about some of the conclusions reached can be found here.

During this process I have accumulated a list of the ten most common mistakes in creating taxonomies.  I have been guilty of many of these mistakes myself in the past.  I try and avoid these today when I build an XBRL taxonomy.

1. Mixing dimensional (using XBRL Dimensions) and nondimensional (not using XBRL Dimensions) in the same taxonomy. The clearest evidence that this is a really bad thing (not bad, really bad) is that XBRL Formulas partitians it's world as "dimensional" (i.e. with XBRL Dimensions) and "nondimensional" (i.e. without XBRL Dimensions).  Mixing these two will cause lots of problems.
2. Looking at pieces of an XBRL taxonomy in isolation.  Taxonomies are not used in isolation, they are used in XBRL instances along with other parts of the taxonomy.  The next two items also relate to this point.
3. Not creating ways to be sure that the same things are expressed in the same ways in different areas of the taxonomy.  This is both about inconsistency and being clear to the users of the taxonomy.  If you are not doing things to help you be consistent, there is 100% probability that you are being inconsistent.  If you are inconsistent, try and write documentation and explain to someone how to use the taxonomy.  Further, inconsistencies will be confusing to users of the taxonomy.
4. Not verifying that an XBRL taxonomy works by creating XBRL instances.  It makes sense to be sure you are getting what you expect from your taxonomy.  The only way to do this is to create XBRL instances to be sure you are getting what you expect.
5. Modeling a taxonomy based only presentation. So this problem typically results from a number of things.  The first is a lack of a data modeler on the team (see the next point).  Another is business people making decisions which technical people should be making.
6. Having no one on the taxonomy creation team which has data modeling expertise.  Taxonomies are data models.  Not having a data modeler involved would be like having a business person create the database schema for an applicaiton you are building.
7. Using tuples if you need extensibility.  I have see-sawed on tuples, and to some degree still cannot figure out if they are evil or helpful.  One thing is very clear.  If you need extensibility and you use tuples, you will run into problems.
8. Not controlling how users of the taxonomy can extend the taxonomy.  If you don't control how a user of the taxonomy extends the taxonomy, you are pretty much guaranteed to have a free-for-all when users do extend the taxonomy.
9. Not using a style guide. The style guide created for the US GAAP Taxonomy was one of the most painful things I have ever participated in creating, but also one of the most helpful.
10. Not documenting the taxonomy architecture. There are two problems with not documenting a taxonomy's architecture.  First, the team creating the taxonomy does not understand the architecture.  Second, users of the taxonomy don't understand the architecture.  What both of these mean is that "anything goes".  You are generally bounded by what XBRL allows, but then again I see people proposing to add attributes which are not in the XBRL specification and otherwise do things which move away from the standard.  Documenting a taxonomy's architecture eliminates this problem.