Digital Financial Reporting

Many people tend to make the broad, sweeping statement that "extensions are bad" when it comes to SEC XBRL financial filings. Making such a statement is simply an indication that they don't really understand the moving pieces of SEC XBRL financial filings very well.  The perception that all extensions are bad shows that one just does not understand why XBRL is so useful. (For more information about extension, read these blog posts.)

For XBRL extensibility to work correctly it must be controlled. What can and cannot be extended, where an XBRL taxonomy can be extended, and when a taxonomy is extended by a filer it must be clear what that filer is communicating.

In order to understand and explain this, I took the fundamental accounting concepts that I identified and looked at them closely from the aspect of whether and how to extend them, this blog post summarizes that information.  This graphic below provides a summary of my initial analysis (click the image for a larger view).

(Click image for larger view)

The first thing I noticed is that there are a handful of categories which concepts fit into or rather a set of properties which a concept might have.  Concepts might have more than one of these properties  (And I am focused on concepts right now, not Axis or Members, etc.)

• Required, it would make no sense to extend concept: There are obvious examples of such concepts like dei:EntityRegistrantName and dei:DocumentFiscalYearFocus. It absolutely, 100% makes zero sense to allow extension of such concepts.
• Optional, it would make no sense to extend concept: This is similar to the category above, but the concept is NOT required to be reported, such as dei:TradingSymbol, or the concept would only be reported if the filer actually had the concept, such as us-gaap:InventoryNet.
• Allowed to add subclasses of concept, but not extend concept: For some concepts, it makes a lot of sense to allow a filer to add a subclass for that concept or as some people think about it, to add a "child".  But, it makes no sense to extend the concept. So again take the concept us-gaap:InventoryNet. It is hard to imagine the need to provide for some other concept "my:InventoryNet".
• Allowed to create extension concept: Suppose that some SEC filer wanted to disclose carbon credit information in their financial report but the US GAAP XBRL Taxonomy contained no such concepts.  Pretty clear than an extension concept could be created.  Likewise pretty clear that if a filer needs subclasses, children, or other stuff those should be allowed for also.  Basically, if something clearly does not exist and a filer needs it, creating an extension should be allowed in such cases.

So that seems to be the spectrum of options. 

Now let's look at a specific concept: us-gaap:Assets.  What category does us-gaap:Assets fit into? Well, given that I am considering only financial filings in this analysis (10-Q and 10-K financial reports), and given that 99.6% of SEC XBRL financial filings report us-gaap:Assets, and given that I looked at each of the .4% of filers who did NOT report that concept and determined that the extensions created were undoubtedly inappropriate; I would conclude that the concept is required and it makes zero sense to ever extend that concept.

What about adding a subclass or child to that concept?  The concept us-gaap:Assets has two subclasses or children: us-gaap:AssetsCurrent and us-gaap:AssetsNoncurrent.  What other classes would you ever need?  Also, given the high number of filers (97.7%) who used those concepts and more importantly who do not ever provide some other subclass of assets other than those two, it is fairly clear us-gaap:Assets should NOT allow child concepts or other subclasses to be added.

At the same time, it seems doubtful that extension of the concept us-gaap:AssetsCurrent or us-gaap:AssetsNoncurrent should be allowed. Again, use by SEC filers proves this.

What about extensions to the subclasses or children of us-gaap:AssetsCurrent or us-gaap:AssetsNoncurrent? Well, that seems perhaps reasonable.  Do you know that, say, the current assets of a reporting entity can fit into one of the existing subclasses such as cash and cash equivalents, trade receivables, inventories, or the catch all "other current assets"?  Well, most likely.  Particularly given that catch all category "other current assets".  But, do you REALLY want filers to put everything else into that category?  Perhaps not.

But this decision is a conscious choice.  It is that conscious choice about allowing a new subclass of current assets to be created or to allow additional subclasses (children) to be added to an existing class of current asset. What choice one makes is less relevant.  What is more relevant that you understand that you have a choice.

And so this same decision process exists for EVERY piece of the US GAAP XBRL Taxonomy.  Not all concepts are the same.  The choices which will be made for each concept and for each subclass of a concept depends upon the specific case. 

But the list of options you have is both clear and finite.  You cannot "sort of" extend something. Not understanding the different options or expressing the options within the US GAAP XBRL Taxonomy makes it seems that every concept acts randomly or uniquely.  But this is simply not the case.

You can take a look at my first cut at trying to group the fundamental accounting concepts into one of the above categories.  I have a lot of tuning to do, but this seems rather straightforward.