Digital Financial Reporting

Since about June 2010 I have been fiddling with, testing, tweaking and otherwise experimenting with a set of about 53 XBRL instances and XBRL taxonomies. The purpose of the experimentation was to figure out the best approach to using XBRL. As a result of this experimentation, I have reached a number of conclusions about using XBRL. They are summarized below.

This is the set of 53 XBRL instances organized within an RSS feed. Why the RSS feed? Because it provides both a quick way to access the XBRL instances and the related taxonomies manually and using a software application. You can find documentation for this set of XBRL instances and XBRL taxonomies here on my Learning about XBRL page of my blog. See the section Samples/Examples; you should be able to reconcile the RSS feed documents and the documentation. I will create easier to follow documentation at some point.

Two goals of the experimentation were to test the Business Reporting Logical Model / Financial Reporting Logical Model and figure out the best approach to creating SEC XBRL filings.

Conclusions

This is a summary of the conclusions which I have reached:

• XBRL has a logical semantic model. While that model is not well communicated or explicitly communicated, if you dig deeply enough, it is there. What makes it so confusing to see are the many different XBRL syntax options. If you look at the Fact Group and Measure Relations Info sets provided with the examples, you can see the logical semantic model.
• Inconsistency within an XBRL taxonomy causes confusion. If you create an XBRL taxonomy and the definition linkbase, presentation linkbase, and calculation linkbase are inconsistent; then you cannot expect a software application to correctly interpret the XBRL instance information. Said another way, consistent XBRL taxonomies enable clear XBRL instance information.
• Good semantic models can be reconciled to one another; bad semantic models cannot. Even if software vendors don't implement precisely the same semantic model within their software, if the models are good models you will be able to reconcile the models to one another.
• The Business Reporting Logical Model can be helpful in creating a consistent XBRL taxonomy and XBRL instances; but it is not required.  As I started this journey I had been told that there is a logical semantic model buried within XBRL but did not believe it. Now I do believe it. I thought that you needed to have something like the Business Reporting Logical Model to create a good taxonomy.  But that was a mistake.  It helps, but as long as you end up with a good XBRL taxonomy; you don't necessarily have a documented model. I don't think COREP and FINREP have a documented model, other than a good XBRL logical model.
• Consistent extensions lead to usable XBRL instances. There is no difference between a base XBRL taxonomy and an extension XBRL taxonomy. A taxonomy is a taxonomy. Inconsistency between a base and an extension causes precisely the same problems as inconsistencies within an XBRL taxonomy.
• Throwing away pieces of XBRL is not the solution to the inconsistency issues. I had erroneously thought that the path to XBRL nirvana was to get rid of typed members, tuples, custom segments and scenarios.  That is unnecessary.  Each of the different pieces provides a needed feature. If you understand what the different pieces of XBRL syntax provide and use them correctly and consistently things will work out fine.  That said, most people don't need every feature. The only thing I would get rid of in XBRL is the precision attribute, using only the decimals attribute on an XBRL instance fact.

The bottom line: be consistent and clear when you create an XBRL taxonomy. Work at the logical semantic level, not the syntax level. While agreeing on the logical semantic model makes cross XBRL taxonomy interoperability vastly more efficient; as long as you are consistent and clear in your XBRL taxonomy, then XBRL will work for you within your system.  Something like the Business Reporting Logical Model can help you achieve the needed consistency, it is not required and can be achieved using other means.

Here are collections of XBRL samples and examples which I have put together. Each set has different characteristics and utility:

• Hello World example: Very, very basic example of XBRL.
• Business reporting meta patterns: Five very small examples.
• US GAAP taxonomy, SEC XBRL filing meta patterns: Several small examples specific to SEC XBRL filings and the US GAAP taxonomy.
• US GAAP taxonomy, SEC XBRL filings basic example: A little bit bigger example, great for business users testing software to see how well the software works.
• Basic comparison, SEC XBRL filings: What amounts to three basic examples, great for testing analysis software and understanding what makes information comparable and what gets in the way of comparability.
• Business Reporting Use Cases: A set of about 30 specific business use cases showing how to model the specific information in XBRL. Has pretty good documentation for each of the use cases. This is great for business users trying to represent specific business use cases in XBRL accurately.
• Comprehensive example: Combines the 30 specific business use cases into one larger report allowing for testing the interaction between the specific business use cases. This is a very sophisticated example, but simple enough, reducing the amount of noise you have to endure to get to meaningful information about how to get XBRL to really work to meet your needs.
• Comparison example: This is three comprehensive examples which can be used to test the analytical capabilities of software.
• Creating an architecture: This has boatloads of information about one architecture or profile of XBRL and is helpful as (a) an architecture you can use or (b) an architecture you can leverage to create your own architecture.
• Other samples and examples: This is a collection accumulated over 10 years of creating XBRL taxonomies.  This example is great if you want to see the trends and ideas which help one figure out why we are where we are today.

For more information see the Learning about XBRL page.

The document Modeling Financial Information Using XBRL (DRAFT) is available on the index page of the samples and examples I have been creating. That document summarizes the many, many samples and examples which I have been putting together to help me see if the Business Information Logical Model works as I would like it to work.

Lots of people seem to be struggling with the symptoms of how XBRL is being used today. This material strives to solve the problems, not fight the symptoms.  The symptoms will go away once the problem is solved. Also, keep in mind that if you are trying to figure out how to get XBRL into your existing processes, realize that another way to approach things is to try and understand how XBRL can make your current processes more effective and effecient.

I wish I could say that this information is helpful to the average business user. It probably is not and most will not choose to make their way through it. I cannot write that material that I want to write until software applications change their approach to working with XBRL. The material is quite helpful to business users who are early adopters of XBRL and will endeavor to wade through the material.  The material will help these curious business users begin to ask good questions. Those good questions will begin to impact all the moving pieces which impact business reporting where XBRL is being used as an output.

For those leaders in the accounting profession who do have the intellectual curriousity to dig in and try and figure out how to best make XBRL serve financial reporting and other areas of accounting, I think there is a lot there to help you. For example, when having software vendors demo their analysis software, use the comparison example's three XBRL instances rather than the scripted demos of software vendors.  Understanding the material in that document will turn you into an educated, informed buyer.

Most accountants aren't really that up on the issues relating to working with XBRL. All that will change when legal liability associated with filed XBRL kicks in.  Further, the SEC has already said publicly that it's intension is to not continue to supplement the HTML or SGML filings with XBRL, but to make the HTML and SGML go away.  When this happens, accountants will look at the XBRL differently.

Do you really want to wait until the last minute, when legal liability kicks in and XBRL is the only document you are filing with the SEC?

There are more and more accountants realizing that financial reporting using XBRL is a foregone conclusion. We still have many, many details to work out; how to "tame the XBRL beast". The information in Modeling Financial Information Using XBRL can help us get the software tools, proper XBRL taxonomies, and other infrastructure we need and get to the point that we want to use XBRL because it actually makes the process of financial reporting more effective and efficient than the current process which has been with us for hundreds of years.

If you feel so inclined, roll up your sleeves and dig in.  If not, don't worry; your competitors are.