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.