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.

I have noticed that more and more people are using the term "structured data" to refer to XBRL-based financial reports.  I certainly buy into that term.  However, I tend to prefer the term XBRL-based digital financial reporting.  Same idea though.

The "structure of the data" is a representation of the information. Far too many people make what I consider to be a mistake of using the term "tag" to describe the stuff within an SEC XBRL financial filing.  I consider this to be a mistake for two reasons.

First, "tag" is too general a term.  What many people refer to as a "tag" could be a Table, an Axis, a Member, a LineItems, a Concept or an Abstract.  For example, if you go to the US GAAP XBRL Taxonomy (2014 version) schema and you query that schema using your favorite XML parser and the following XPath expression: //xs:element[@substitutionGroup='xbrldt:hypercubeItem'].  You get exactly 301 hits, each which represents an XBRL hypercube or what the US GAAP XBRL Taxonomy calls a [Table].  Do the same thing with this XPath //xs:element[@substitutionGroup='xbrldt:dimensionItem'], and you get 327 hits, each representing an XBRL dimension or what the US GAAP XBRL Taxonomy refers to as an [Axis]. Do the same thing with the XPath //xs:element[@type='nonnum:domainItemType'] and you get 1802 [Member]s.

It starts to get a little trickier because of how the pieces are structured to get the [Line Items], the [Abstract]s and the Concepts.  The point is, the 17,433 individual elements (this XPath //xs:element) can be grouped into specific categories.

Those categories of things play different roles in representing the structure of an XBRL-based digital financial report.  In another blog post I pointed out that SEC XBRL financial filings use these structures very consistently. That is to be expected, because XBRL enforces many of these constraints as to how the pieces which make up the structure can be used.  The XBRL definition relations have to be created very precisely and if you make a mistake, XBRL validation will point out that mistake.

Representing these structures using XBRL presentation relations is a little different.  There are no real rules enforced by XBRL as how to represent information using XBRL presentation relations other than you have to follow a very general "parent-child" type hierarchy.  Some SEC EFM rules apply additional constraints to the presentation relations saying that the presentation, calculation, and definition relations need to be consistent.

But the rules are still not strong enough to keep things consistent and therefore can cause potentially confusing representations of the information.

The matrix below summarizes relations which make sense and are "OK", relations which don't make sense and are therefore "Disallowed", and for relations which don't really hurt anything but really don't make sense are "Not advised". Also, note that 99.99% of all relations in SEC XBRL financial filings follow this pattern.

(Click image for larger view)

The way to read the matrix is that the columns contain the parent structure category, the rows contain the child structure category, and the intersection cell specifies whether the relation is allowed or OK. For example, a Table can have exactly two types of children: Axis or LineItems.

This screen shot shows a more restrictive matrix. This causes even less potential for ambiguity and would still meet all the SEC EFM rules:

(Click image for larger view)

Here is an example of a more restrictive rule: What would you ever represent which would call for an [Abstract] to be the child of a Concept? Personally I cannot think of any reason.  In fact, of 3,165,249 parent concepts in the a set of 6,674 SEC XBRL financial filings, only in 546, which is .000172% of the time, did someone feel the need to express this sort of relation.  That fact alone is ample evidence that my reasoning is correct.

Why is all this important?  Why are you telling me the obvious, the following categories of report elements exist in SEC XBRL financial filings: Network, Table, Axis, Member, LineItems, Abstract, Concept?  If 99.99% of people already follow these rules, why is this important?

The answer, which I will build on in subsequent posts, is that this is just the beginning and there are way, way more structures.  Member arrangement patterns and concept arrangement patterns are two other examples.