Digital Financial Reporting

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.