Digital Financial Reporting

This post begins a series of posts where I point out the benefits of the Business Reporting Logical Model.  If you are unfamiliar with the Business Reporting Logical Model, be sure to check out my straw man implementation of this model.

In my straw man implementation of the Business Reporting Logical Model, I created a prototype application in Excel called the "Hypercube Viewer" which allows you to extract and render XBRL instance information. The prototype application does not actually read XBRL, rather it reads an info set generated by an XBRL processor which supports the Business Reporting Logical Model.  The prototype starts by reading an RSS feed which contains links to XBRL instances.  My straw man implementation uses this RSS which points to two XBRL instances: ACME Company and Sample Company.  Here are the info sets for those two companies:

• ACME Company: Fact Groups, Measure Relations, XBRL instance
• Sample Company: Fact Groups, Measure Relations, XBRL instance

If you follow my blog, you may have heard about the State Fact Book prototype which I had created to test some things. I created this prior to the Business Reporting Logical Model being available. I did use XBRLS in creating the State Fact Book which has many characteristics of the Business Reporting Logical Model.

What I wanted to do is refactor my State Fact Book XBRL example to use the Business Reporting Logical Model. To do that, I made two changes to my State Fact Book XBRL implementation.  First, I corrected the data I was using to fix the error in the US Census Data which I had discovered and the Census Bureau subsequently adjusted. Second, I modified the State Fact Book taxonomy to use the Business Reporting Logical Model. I then generated the info sets for the three XBRL instances I was using which you can see here:

• Population Trends: Fact Groups, Measure Relations, XBRL instance
• General Information: Fact Groups, Measure Relations, XBRL instance
• Financial Information: Fact Groups, Measure Relations, XBRL instance

Next, I organized those three XBRL instances with the XBRL instances above into a new RSS feed which you can see here. This RSS contains all 5 XBRL instances, all created using the same Business Reporting Logical Model. I then pointed a new version of the Hypercube Viewer to that new RSS feed to see if the Excel application would read those new info set files generated by the XBRL processor.

After fixing a few bugs in the State Fact Book XBRL taxonomy and the application, my Excel application would read all five sets of information and render the sets consistently in the way I would have expected the information to be rendered.  You should consider trying this for yourself.

For the intellectually curious who understand a little about Excel, you may want to consider reverse engineering the Excel application to create something which reads those info sets.  In doing so you will realize the benefits of the consistency enabled by the Business Reporting Logical Model.

Even if the Business Reporting Logical Model never becomes an XBRL International standard, everyone creating an XBRL taxonomy will have to use something to ensure consistency in the XBRL taxonomies created. This is less important if you do not use taxonomy extensions, it is vital if you do allow extensions. Those creating extensions have to be guided to create extensions which are consistent with the taxonomy they are extending.

What I learned from this exercise is that some of the things I thought were important are not really important at all. I have always tried to keep taxonomies consistent by using the presentation linkbase.  It is clear to me now that that is the wrong approach.  I also thought that you would never get consistency unless you ditched a number of the pieces of XBRL such as typed members and tuples.  That really is not necessary. You do need to control those pieces and others, but you don't necessarily need to ditch them all together.

Consistency is key.  The Business Reporting Logical Model does allow for creating consistency.  There are certainly other alternatives. While smart software engineers can figure out all the ins and outs of XBRL and generate an info set with information similar to the ones generated for my straw man implementation of the Business Reporting Logical Model, the "channeling" of XBRL syntax which the model does makes it significantly easer to process the XBRL syntax to generate that info set. Once you have the right info set, you can convert that into whatever syntax you might like. The syntax is really unimportant.  It is the consistency of the business semantics which is important. The Business Reporting Logical Model is one way to achieve that consistently.  There are others.