BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries from June 12, 2011 - June 18, 2011

Sample Code for Generating XBRL Formulas from Info Set

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.

Posted on Tuesday, June 14, 2011 at 11:31AM by Registered CommenterCharlie | CommentsPost a Comment | EmailEmail | PrintPrint

Seeing the Value from Leveraging a Logical Model

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.

 

Posted on Monday, June 13, 2011 at 12:21PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint