XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

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

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.
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).
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".