« Disclosure Template Count now 50, Prototype Implementation Provided | Main | XBRL US Best Practice Guidance for Creating SEC XBRL Financial Filing »

Differentiating Wrong, Technically Correct but Sloppy, and Elegant SEC XBRL Financial Filing Models

During the process of creating the disclosure templates which I am putting together something which had not occurred to be before became clear. Have you ever wondered why messy renderings such as the one below occur?

Messy rendering

A modeling is flat out wrong if you use the wrong concept for a fact or if you use the wrong [Axis] on a fact.  A model is elegant if you can look at the model and comprehend what is going on; not to mention that it is a correct modeling (i.e. not wrong).  The model shown above could actually be technically correct.  I don't know if it is technically correct, I did not look at this specific situation.  What I can tell you is that I have seen renderings which look like the one above which are technically correct. But I would also consider that modeling sloppy and frankly unnecessary.

And so, while I would not consider that rendering of a component within an SEC XBRL financial report "elegant", it actually is not "wrong" either.  Technically, it is correct per the rules of how XBRL work. But how can this be?

To explain what is going on here, I modeled the document information section of an SEC XBRL financial report four times using four different approaches.  You can see that information here.  The bottom line here is that the problem is caused by cramming too much information together as opposed to organizing the information in your model correctly and logically.

The facts within each XBRL instance are exactly the same for the four example modelings I created. The business rules for each of these models is identical also.

So what is going on? How could the models be so different, the renderings be so different, but the information be exactly the same?

The short answer to the question, but a little technical, is a rule which was created to get XBRL Dimensions to work correctly with XBRL 2.1 which does not know about XBRL Dimensions because it was created prior to XBRL Dimensions.

Now first of, there is not a problem if you are using XBRL 2.1 without using XBRL Dimensions. There is likewise not a problem when you stick to XBRL Dimensions, making sure everything in your taxonomy is modeled within a [Table] or more appropriately called a hypercube per the XBRL Dimensions specification.  And if you seek out advice from those who understand XBRL well, pretty much everyone would tell you to avoid mixing XBRL Dimensions with XBRL which does not use XBRL Dimensions (i.e. all concepts are modeled in your taxonomy participate within at least one hypercube/[Table] and therefore follow the rules of XBRL Dimensions).

The US GAAP Taxonomy and SEC XBRL financial filings allow you to break this rule.  You are not required to use XBRL Dimensions.  You can use XBRL Dimensions and therefore you can follow a pure dimensional model; I do and a number of others who create XBRL filings such as Edgar Online do.  (Note that they used this approach prior to merging with UBmatrix, I had nothing to do with Edgar Online reaching this conclusion, they did because they understand the issues.)

However, there are times in pretty much every SEC XBRL financial report where you MUST use XBRL Dimensions to properly articulate your filing information; and therefore arises the possibility of mixing your modeling approach if you do not use XBRL Dimensions throughout your taxonomy.

Because models can be mixed, a rule was created that in essence says that every context is assumed to have each and every dimension or [Axis] which exists within an XBRL taxonomy for which a dimension default exists.  Now, dimension defaults are required on EVERY dimension or [Axis] per SEC filing rules and therefore every context is considered to carry the value of the [Domain]. And therefore, every fact in an XBRL instance actually, per XBRL Dimensions rules to overcome this mixing of XBRL Dimensions and pure XBRL 2.1, has every dimension and if there is no other [Member] specified carries the value of that default dimension or [Domain].

Now, there is not one rendering engine which shows you all these dimensions or [Axis] on every fact. The SEC interactive data viewer does not.  The FireFox XBRL viewer does not. The XBRL Cloud viewer does not. The Magnify viewer does not show all these dimensions or [Axis] in the nice rendering they provide, but they do allow you to view them but they are grayed out.

But, this is the reason that each of the four different looking modelings are semantically identical even though the models are different.  You can look at this as either a "feature" or a "bug".  Personally, I think this is a hack.  The mixing of pure XBRL 2.1 and XBRL Dimensions was done to appease people who did not want to use XBRL Dimensions at all.  They considered XBRL Dimensions too complex.  From where I sit what I see is that they made things more complicated by not using only XBRL Dimensions (i.e. everything exists within a hypercube or [Table]).  This may not be apparent today because this also confused many software vendors.

I predict that more and more people will understand how to use XBRL Dimensions correctly and will eventually realize that mixing models is what is confusing.  Time will tell.

Posted on Wednesday, May 23, 2012 at 08:12AM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.