XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

There is some phenomenon which I am observing. It seems to me that this is not something unique to financial reporting but rather it is likely common to many different domains. I first articulated this observation in this blog post. The observation relates to why automated processes cannot make use of information reported in SEC XBRL financial filings. I repeat the four reasons which I observed as part of my testing:

Missing totals/subtotals: Missing fundamental accounting concept totals/subtotals. For example, most filers do report key totals such as "Assets", "Equity", "Revenues", Net Income (Loss)" and so forth. If filers don't report such totals/subtotals, it can cause problems with reading the information.
Crossing categories: Filers moving a fundamental accounting concept to be part of some other fundamental accounting concept. A common situation is where a filer moves the concept "Interest and Debt Expense" to be included as part of "Nonoperating Income (Expenses)".
Extension category unknowable: No machine readable information which relates an extension concept to some existing US GAAP XBRL Taxonomy concept or concept category. For example, if a filer reports the concept "my:SomeTypeOfOperatingExpense" and they intended that to be an operating expense, while a human can figure out that the concept is an operating expense, a computer cannot.
Missing US GAAP XBRL Taxonomy concept: If a high-level concept is missing from the US GAAP XBRL Taxonomy, it can cause the filing to not be decipherable by automated processes.

I mentioned this observation to someone that I know who has an information technology background. He summarized his observation about this in the following statement: "...there is a boundaries problem...". That term "boundaries" seemed to totally fit. Mapping that term to my observations, I get the following:

Missing totals/subtotals = Missing boundaries
Crossing categories = Crossing boundaries
Extension category unknowable = Not explicitly indicating what category or boundary an extension goes into
Missing US GAAP XBRL Taxonomy concept = US GAAP XBRL Taxonomy not properly defining all concepts, articulating all boundaries, or providing an explicit means for indicating the concept or category a filer is extending

Like I mentioned above, this seems like a general or common sort of problem. It seems to me that there should be some sort of observation about this sort of situation in something like network theory or graph theory.

It seems to me that what is missing is a global standard way to define or establish a "class" such as the way RDF can define a class. Also missing is the ability to articulate that something is a subclass or equivalent class and so on. Probably one of the biggest clues that this is true is that RDF has the notion of a class and RDF is pretty much doing the same sort of thing XBRL is trying to do.

So, to summarize these issues again using the notion of "class", I would do it like this:

Not defining classes (Missing totals/subtotals = Missing boundaries)
Not associating concepts with classes (Neither the US GAAP nor IFRS XBRL taxonomies do this)
Defining something implicitly as one class, but using it as if it were another class (Crossing categories = Crossing boundaries)
Extensions not associated with a class (Extension category unknowable = Not explicitly indicating what category or boundary an extension goes into)
Missing concepts (US GAAP XBRL Taxonomy not properly defining all concepts, articulating all boundaries, or providing an explicit means for indicating the concept or category a filer is extending)

Further, classes and subclasses have additional utility beyond basic needs of ensuring data quality and consistenty. Several months ago in this blog post I pointed out that different concepts in the US GAAP XBRL Taxonomy act differently. That is what classes and subclasses do, they differentiate things for machines. This is an improved version of that categorization to help you understand how classes and subclasses can be used:

Concept required: it would make no sense to extend concept. For example, 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 concept: 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 what I am pointing out, I believe, is that there are specific classes of things in something like the US GAAP XBRL Taxonomy that act in specific and important ways.

Now, XBRL has no problem articulating this sort of information. XBRL definition relations can be used to define this information. What is missing though is a global standard XBRL arcrole for describing these classes and subclasses and/or the US GAAP XBRL Taxonomy making use of those global standard arcroles if they existed, or defining the arcroles themselves if the do not exist.

XBRL definition relations does have the arcrole http://www.xbrl.org/2003/arcrole/general-special which is explained as follows in the XBRL technical specification:

A generalisation item is an occurrence of a generalisation concept in an XBRL instance. A specialisation item is an occurrence of a specialisation concept in an XBRL Instance.

So, the XBRL "general-special" arcrole provides some functionallity, but I don't know if it provides enough functionallity. RDF schema defines two things: rdfs:Class, rdfs:subClassOf. The definition of the "general-special" arcrole also refers to "in an XBRL instance". That does not sound right because referenced concepts might never appear in the XBRL instance. Not sure what an XBRL processor, particularly considering the requirement of the relations to be "C-equal" and "U-equal". Also, the defintion never refers to the terms "class" and "subclass" which are more commonly used.

Bottom line: XBRL is missing the ability to define a "class" and the notion of a "subclass" and/or taxonomy creators are not making use of what does exist to express such relations. Easy enough to fix, simply add the needed arcroles in the XBRL Link Role Registry. The fact that RDF defines the notion of a "class" and "subclass" is ample evidence that this is a problem. Data quality issues of SEC XBRL financial filings only confirms this fact.