Digital Financial Reporting

Yesterday I posted this blog entry which explained how a logical model can be leveraged in working with XBRL.

Here is sample code(an Excel VBA module) which generates the XBRL Formula file from the business rules info set. After you download and run the VBA code which generates the XBRL Formula file, you can run that formula file against this XBRL instanceto run the XBRL Formulas to see that it does, in fact, work. Of course, you will need an XBRL processor which supports XBRL Formula.

I have been a proponent of using a logical model to hide the XBRL technical syntax for quite some time. It can be hard to communicate the value of such a logical model.  But, I believe that I have two things which clearly show the value of a logical model.

First, I build two prototypes using this logical model: the the reorganized US GAAP taxonomy and exemplars and the evaluation utility.  You can see the info sets I worked with here(i.e. I was not working at the XBRL syntax level). This is a more general example.

Second, a much more specific example, is the business rules I created associated with the model/reference implementation of an SEC XBRL financial filing. When I first created the business rules for this model/reference SEC XBRL filings, this is what I was editing. That is an XBRL Formulas file which I created to validate that filing. (You can see the valiation results here and here which will give you an idea of why these XBRL Formulas are needed.) It was a painful process to create those XBRL Formulas to say the least.

But after I had all the XBRL Formulas created, I realize that there were patterns within those XBRL Formulas or categories that the formulas fit into.  These are the categories:

• Roll forward (beginning balance + set of changes = ending balance where only the period axis changes)
• Dimensional aggregation (flat set of members)
• Exists of a fact
• Equality of two facts
• Adjustment (originally stated balance + set of adjustments = restated balance where the report period axis changes)
• Roll up (similar to an XBRL calculation)
• Fact greater than another fact
• Fact greater than zero
• Dimensional aggregation (nested set of members)
• Variance between two reporting scenarios

So that is about 10 categories.  I probably don't have all of them yet, but for all the XBRL Formulas I created, they fit into one of those categories.

Next, I distilled down the relevant things from the XBRL Formulas, basically the parameters of each category of XBRL Formula.  Then, I expressed those moving pieces in the form of, you guessed it, an info set.  Here is that info set. So, which of those files is easier to read, the info set or the raw XBRL Formulas? Hands down, it is the info set.

Finally, I wrote a little VBA application which read the info set and generated the XBRL Formulas from the information in the info set.  Took me about 4 hours to do that.

And so now if I want to create any XBRL Formulas, all I have to do is provide the information in the info set format and then run that info set through my VBA code (I could have used XSLT, but my VBA skills are better so that was easier for me)  (Here is the generated version and the HTML.

Want to estimate the value of a logical model? Go look at the complexity of the XBRL Formula file.  Then go look at the complexity of the business rules info set file.  Calculate in your head how much effort it would take to teach someone to create that XBRL Formulas file.  Then, think about how long it might take to explain how to create that business rules info set file.  Bingo.  Apply that to the fact tables, the relations, the report elements, etc.

Take a good, hard look at those info set files.  That will show you the value of a logical model.

Now, imagine having to use a software application to create those XBRL Formulas which is intended to be used by business users.  Which interface is likely easier to use:

• One that lets you edit the XBRL Formulas technical syntax
• One that lets you edit the business rules info set information

Basically, you can look at the business rules info set categories as a category of functions.  Provide the information required by that category, then generate the XBRL Formulas.

As part of a discussion thread on XBRL-Public, I learned something which I sort of knew but never really heard this articulation or explanation of semantic models before. It seems to make things clearer for me.

Wikipedia defines semantic models as:

Terms such as "semantic network" and "semantic data model" are used to describe particular types of data models characterized by the use of directed graphs in which the vertices denote concepts or entities in the world, and the arcs denote relationships between them.

That describes what XBRL does.

If you work with XBRL and you don't understand graph theory, you need to study up if you REALLY want to understand XBRL.

I took the information about the SEC XBRL financial filing logical model and populated a wiki, creating a glossary of important SEC XBRL financial filing terminology.

I then used that glossary as somewhat of a "help" system in the report element report and the extension element report of the SEC Examination Utility tool.

The AICPA Assurance Services Executive Committee, XBRL Assurance Task Force has issued an exposure draft: Proposed Principles and Criteria for XBRL-Formatted Information. Comments are requested by July 15, 2011.

I encourage Accountants to first understand and then comment. These resources will help you get your head around things:

• Characteristics of a quality SEC XBRL Financial Filing
• Properly Differentiating Important Key Terms
• Understanding SEC XBRL Financial Filings

On my first scan of the document I see a mixing of terminology relating to the XBRL technical syntax and financial reporting business semantics, which is unfortunate.