Digital Financial Reporting

You can break down the information contained within a digital financial report such as an SEC XBRL financial filing in many helpful ways. Here are some helpful breakdowns of the report elements and report components which make up SEC XBRL financial filings.

For my set of 7160 SEC XBRL financial filings (all 10-K filings), the following summarizes the report elements of those filings, averages per filing, average per report component, and extension rate percentages for each report element category:

(Click on the image for a larger view)

Some items of interest.

• Categories of report elements: The first thing to note is that the pieces of a digital financial report are identifiable and fit into categories.  It is not really appropriate call any piece of a report by the term "tag" or "element" because no one knows if you mean report element, concept, axis, member, table, line items, abstracts or reported facts.  Using the more specific term conveys more meaning.
• Lots of small pieces: The average report component has 6.7 concepts.

The following breakdown is even more insightful in my opinion. Here is information about concepts and extension concepts grouped by report component category:

(Click to view larger image)

Understand is that a third of all report components are text blocks. So we should look at text blocks and detail components separately.  We should also look at statements and disclosures separately.

And so in tuning this you can see that the average report component which is a statement has 20 concepts and the average disclosure has 7.

You can break this down even further, by disclosure.  Here is a summary of concept usage for a select number of report components:

(Click to view larger image)

What will really be interesting is when you can analyze the information communicated within the disclosures themselves!  I am working on that.  Computational linguistics seems to be useful for that.  More to come.

Many people tend to have the perception that all filer extensions to the US GAAP Taxonomy used by SEC XBRL financial filers is always bad.  That is simply not the case, a misperception.

Consider this example: (SEC Interactive Data Viewer, see the Commitments and Contingencies disclosure; XBRL Cloud Viewer; XBRL Instance)

In the report component above, 50% of the reported facts are extension concepts added by the filer.  However, those extensions are not bad; they are actually good.  The filer is (a) disclosing information in addition to what is generally required by US GAAP and (b) they have added information which the reporting entity believes is important to properly understand their financial position and financial condition.

SEC filers should not be punished for this sort of extension, it should be encouraged.

What many people do is talk about extensions in general terms because they simply have not rolled up their sleeves and got into the details.  They talk in general terms because that is all they understand.  If you look deeper, as I have, you begin to understand that extensions can be categorized something like this:

• Unjustifiable extensions: Are there bad extensions?  Absolutely.  There are many cases where it is 100% clear that extensions are absolutely not appropriate.  For example, creating an extension  concept "my:Assets" with the label "Total assets" and documentation "Total assets" is highly-likely to fit into this category.  If a filer cannot or does not justify why they created an extensionwithin the documentation for that extension, then they probably should not have created the extension. Writing a justification for the extension adds discipline and rigor to this process. Reading the justification in the documentation of a concept helps users understand the justification.
• US GAAP Taxonomy Errors: The US GAAP XBRL taxonomy contains errors.  There are some cases where a filer can justifiably create an extension to overcome the error.  There are some cases where filers get confused because of concept definitions and feels that they may need to create an extension concept.  For example, the concept "us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease" was in that category.  There was an issue with the definition related to discontinued operations.  That issue has now been fixed within the 2013 US GAAP Taxonomy.  Filers, justifiably, created an extension.  In my view they should provide that justification within the documentation for the extension concept which they created.  Also, many filers in this situation did NOT create an extension.  The point here is that in come cases tuning of definitions of concepts are needed and error corrections are necessary to eliminate the need for filer extensions.
• Additional information, Entity specific information, Industry specific information: As in the example above, in many cases filers disclose additional information which is not necessarily required under US GAAP. Or, filers justifiably create extensions because they have information that they feel is unique to their entity and is necessary to properly understand their financial information.  In other cases information which is generally reported by filers within a certain industry is not provided and therefore is missing from the US GAAP XBRL Taxonomy.  These extensions should be encouraged, not discouraged.  At some point missing industry information common to many filers can, and likely will, be added to the US GAAP taxonomy.  The extensions help discover what needs to be added to the US GAAP XBRL Taxonomy. Concept documentation can be used to help readers understand why the information is relevant.
• Gray area: There are "gray areas" where rules are not clear, differences of opinion exist, GAAP may not be clear, or maybe filers are perhaps sloppy or lazy.  A "jury of peers" might look at all the moving pieces and decide if an extension concept is or may not be justifiable.  That jury of peers could go either way, but what could help decide if something is or is not justifiable is adding that justification to the documentation for the extension concept or other report element added by a reporting entity.

There may be other categories, but that is what I have come up with.  The point here is that there are many reasons filers create extension concepts and other report elements.  It all boils down to justification.

All things considered, filer extensions are not a "bug", they are a feature.  Sure, extensions need to be used appropriately. One of the beneficial features of financial reporting under US GAAP is the latitude for a reporting entity to tell their story, their way.  Do reporting entities need to justify what they did?  You bet.  Should reporting entities need to explain why their peers used some existing concept and they chose to create an extension concept?  Yes they should.  Then regulators, analysts, and investors can reach their own conclusions as to the appropriateness of that extension.

The better a reporting entity justifies their extensions, the more likely that a filer actually put some thought into whether they should have created an extension concept.