Digital Financial Reporting

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.

The 2009 version of the US GAAP XBRL Taxonomy was released by XBRL US about a week ago.  That page has information helpful in the general use of the taxonomy:

• Home page of the taxonomy: http://xbrl.us/Pages/US-GAAP.aspx
• Viewing the taxonomy (the CI entry point which most companies will use): http://viewer.xbrl.us/yeti/resources/yeti-gwt/Yeti.jsp#tax~(id~6*v~31)!net~(a~78*l~25)!lang~(code~en-us)
• Preparer's guide: http://xbrl.us/Documents/PreparersGuide.pdf

For some reason, a pointer to the web version of the taxonomy (such as this for the PRIOR TAXONOMY http://xbrl.us/us-gaap/1.0/ WHICH POINTS TO THE PRIOR TAXONOMY or this one which points to the IFRS taxonomy http://xbrl.iasb.org/taxonomy/2009-04-01/) is NOT being made available.

Eventually, I am going to build some extension taxonomies which make working with the US GAAP Taxonomy easier.  Not sure when I will get around to it.

In 2004, Rene van Egmond and I wrote a white paper called Comparing XBRL and Native XML. That information made its way into the book I wrote, Financial Reporting Using XBRL, in 2006 (see section 4.11.2). Both iterations where very helpful trying to grasp what the differences between XML and XBRL were and explaining these differences to others. These comparisons pretty much had an "XML versus XBRL" bent. In retrospect, I have come to realize that the XML versus XBRL approach to comparing the two was not necessarily the best approach.

Here in we are in 2009 and I have an updated version of the analysis of XBRL as contrast to XML. XBRL is an approach to using XML and a layer on top of what most XML languages generally provide.

• XBRL is XML. XBRL uses the XML syntax. Therefore, XBRL can leverage the entire family of XML specifications.
• XBRL expresses semantics (meaning) in a standard format. XML only articulates syntax. For others to do what XBRL does with XML, you would basically have to reinvent what XBRL has already created.  Because these semantics care expressed in a standard format they can be exchanged.
• XBRL allows content validation against the expressed meaning. Because the meaning (semantics) are expressed, it is possible to validate XBRL instances against that meaning.  And XBRL has created standard mechanisms for performing this validation, such as calculations and XBRL Formulas.
• XBRL separates concept definitions from the content model. Typically with XML languages, the concept definitions and the content model are mixed together. Further, XML provides you with only one implicit set of relations (because it has only one content model) and the definition of those relations is mixed with the definition of elements and attributes. XBRL, on the other hand, uses an atomic approach (flat XML content model) in defining concepts and moves the expression of relations away from the XML schema. This separation of concept and relation definition leads to the next benefit of XBRL, you can express more than one set of relations and each of those sets of relations can be explicitly identified as being for a specific purpose.
• XBRL can express multiple hierarchies of explicit relations. Because XBRL separates concept and relation definitions, you can define more than one hierarchy of such relations. Further, the hierarchies of relations defined are explicit rather than XML's implicit content model.
• XBRL provides prescriptive extensibility. XML's greatest strength is also its greatest weakness. XML is extensible everywhere, in every direction. XBRL is extensible in a specific, prescriptive, and therefore predictable manner. As such, the extensibility is usable without modifying software for the extension. You can think of this as XBRL always having the same "shape".
• XBRL easily fits into relational databases. XML can be made to easily fit into a relational database. Because of XBRL's separation of concept definition and relations and because the extensibility is predictable giving XBRL a consistent shape, XBRL taxonomies and XBRL instances are significantly easier to model within a relational database as compared to more traditional approaches of using XML. This is particularly true if you use a well-thought-out strategy to create your XBRL architecture. Getting XBRL into and out of relational databases is important because there are a lot of relational databases that XBRL must interact with.
• XBRL provides a multidimensional models. The multidimensional model is being used by online analytical processing systems (OLAP) type systems, providing flexible presentation of information and the ability to "slice and dice" information. Business intelligence systems in particular is one big user of the multidimensional model. Although XML can be made to fit into a multidimensional model in many cases, doing so can be a struggle. XBRL can fits quite nicely into the existing applications, such as these business intelligence applications, which make use of the multidimensional models. Like with fitting into relational databases, this is particularly true if you use a well-thought-out strategy and create your XBRL architecture to do so. Alternatively, you could use an existing architecture and application profile that's specifically intended to fit into an application which makes use of the multidimensional model. Getting information into applications which make use of the multidimensional model is important because more and more applications, such as business intelligence applications, are leveraging the characteristics of the multidimensional model to provide flexible (think "interactive") presentation of information.
• XBRL enables "intelligent", metadata driven connections to information.With XBRL, connections to information can be created by business users adjusting metadata rather than by requiring technical people writing code. As such, rather than building multiple point solutions, XBRL enables the creation of effective and efficient solutions that allow extendibility and don't require programming modifications to connect to new information or new information models. Again, this is because of the prescriptive manner of XBRL's extensibility, the "shape" of XBRL is always the same. With XML, every new connection pretty much has to be enabled by a programmer writing code because XML only communicates technical syntax and does so at the data level, not the meaning level, of information and because the shape of different implementations of each XML implementation can be so varied.

It would be great to get the perspective of people from the XML community which have gained a good understanding of XBRL to hear their view of this comparison.

It seems to me that it should be possible to draw some "line" and better understand when XBRL is a better solution to a problem and when creating a specific XML language is a better approach.