Digital Financial Reporting

I had a number of requests for XML Schemas which explained the XML Infoset files which I use to work with XBRL.  Well, here is a first cut.  Note that I have had two different versions of terminology which I was using, I am transitioning to a new third format which syncs a bunch of things together.

These are DRAFT versions of the XML Schemas (I hope to have the final version within one to two months along with RDF/OWL ontologies which explains these and some other things:

• Model structure: http://xbrlsite.com/DigitalFinancialReporting/Schemas/ModelStructure.xsd   (note that this was called the relations infoset)
• Fact table: http://xbrlsite.com/DigitalFinancialReporting/Schemas/FactTable.xsd
• Report elements: http://xbrlsite.com/DigitalFinancialReporting/Schemas/ReportElements.xsd
• Business rules: (to do)

If you want to understand this stuff more, please refer to the "Digital Financial Reporting" page of my blog.

While creating the disclosure templates I am putting together I noticed something and a question occurred to me.  How does someone creating an SEC XBRL financial report know which [Table] to use and which [Axis] to use when expressing their financial information and how is this "controlled" by the SEC?

This is what I mean.  Take a look at a rather straight forward disclosure, product warranty accrual. To create the product warranty accrual disclosure template, I started by looking at what other filers did.  I built a nifty application which helps me do this.  That application generates a nice little summary which shows the disclosure template and lets you look at the model structure of other SEC filers who modeled that same disclosure.  You can see this here.

If you go to the section "Similar SEC XBRL Filer Examples" you will see links to about 42 SEC filings which provided this disclosure.

Of those 42, the vast majority of filers modeled this disclosure without using any [Table] and therefore not providing any additional [Axis] beyond the reporting entity, period, and concept which they are required to provide for all facts provided. So here is one example of that approach.

Three of the filers added an additional characteristic, the "Legal Entity [Axis]".  Personally I prefer this approach because I prefer to (a) consistently use [Table]s for everything (as compared to using them for some things but not for others and (b) because it explicitly states that the legal entity characteristic is the consolidated entity (as opposed to having to imply this information).

However, of these three filings; two different [Table]s were used to disclose the product liability accrual roll forward:

• us-gaap:ScheduleOfGuaranteeObligationsTable
• us-gaap:ProductLiabilityContingencyTable
• us-gaap:ProductLiabilityContingencyTable

These two SEC XBRL financial filings used the Range [Axis].  That seems like it could be reasonable; however these two filers did not use any of the [Table]s above, rather they created their own [Table] and used that:

• flir:ScheduleOfAccruedLiabilitiesTable
• twi:ScheduleOfWarrantyTable

This filer used the Business Acquisition [Axis] and created their own [Table]:

• hlit:ScheduleOfProductWarrantyLiabilityTable

This filer used three different [Axis], two of which used the [Domain]:

• us-gaap:ProductLiabilityContingencyTable

This filer created its own [Table] and its own [Axis], whr:ProductWarrantyAndRecallAxis, and this does seem to make sense because they choose to break down the information into product recalls and normal product warranties; plus the do provide the total of these two categories which is comparable to all the other disclosures of this information:

• whr:ProductWarrantyAndRecallRollforwardTable:   

This SEC filer provides no explicit [Table] and packs the product warranty accrual together with a bunch of other disclosures as compared to focusing on that specific disclosure in this specific network.  (Approximately 50 percent of the total focus on one thing and the other 50 percent pack multiple pieces together):

• No table

Clearly this product warranty liability accrual roll forward is a rather basic and straight forward disclosure.  Consider these examples and consider the fact that there are I would guess perhaps approximately between say 1300 and maybe 3000 specific disclosure.

How do SEC XBRL financial report filers know

1. When two things should go into one network or be separated into two different networks,
2. What goes into a [Table] within a network or when separate [Table]s should be used,
3. Whether to use an existing [Table] or create their own explicit [Table],
4. And what [Axis] to put onto a [Table].

Here is another good example, document information.

Clearly it is highly unlikely that 8000 or so different SEC filers are going to figure this out themselves and consistently do the right thing without some sort of guidance.  SEC XBRL financial reports filed with the SEC bear this out.

The point here is that some sort of general guidance would be nice from the FASB, the SEC, and/or XBRL US.

The count of disclosure templates has now reached 50.  Also, I have provided a prototype software application which I build using Microsoft Excel which can be used both to explore the disclosure templates and to see how these templates can be integrated directly into a software application such as a business report creation application.

Screenshot of disclosure template explorer (prototype)

Pretty soon you won't need to use your imagination to see the utility of these disclosure templates in the process of creating a digital financial report such as an SEC XBRL financial report.

Again, thing of all those templates provided within Visio or PowerPoint.  For more information, see this blog post.

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.

XBRL US provides best practice guidance for the creation of SEC XBRL financial filings which can be found here.

An improvement on this would be for a set of overarching principles which can be used and applied generally.