Digital Financial Reporting

This document provides a reconciliation between the semantic objects of the Financial Report Semantics and Dynamics Theory, the model which I put together for implementing SEC XBRL financial filings, and the XBRL technical syntax. It helps make clear two areas of ambiguity of SEC XBRL financial filings:

1. When should a network be used and when should a [Table] be used. Said another way, what meaning exactly does a network have and what meaning does a [Table] have.
2. When should a characteristic which describes a financial fact be modeled as a concept and when should it be modeled as a [Member] of an [Axis].

These two issues are a bit of a big deal because having these choices makes it more difficult to create easy to use software and increases the complexity and therefore the cost of creating SEC XBRL financial filings.

Anyone who creates SEC XBRL financial filings probably understands these issues.  OK, so what do you do about this?  Well, for the first issue; many SEC filers are already doing a good thing which is to create a one-to-one correlation between networks and [Table]s.  This is a safe thing to do.  Some filers, and I know that 100% of Edgar Online filings are done this way (I used to work there), is to always use a [Table].

So basically, if there is a one-to-one correlation between networks and [Table]s then there is no ambiguity between what a network means and what a [Table] means because they mean the same thing. As such the first issues is not that hard to work around, although it does not fix the problem.

The second issues is somewhat trickier but there are some guidelines you can use.  First off, your choice of whether to model something as a concept or an [Axis] is many times determined by how something else has been modeled. 

For example, if you want to figure out how to model the components of "cash and cash equivalents" or "inventory" and you want them to show up correctly on your balance sheet and you want your balance sheet to foot correctly; you pretty much need to model the detailed components as concepts because everything else on the balance sheet is a concept. 

On the other hand, you could choose to disclose the details in the disclosures and therefore you would choose either approach; modeling those details as concepts or as [Member]s of an [Axis].  In this case, as long as there are no other areas which would be goofed up and not fit together properly; I personally would choose to model the information as [Member]s of an [Axis] in most cases.  The primary reason is that you can then connect things together better, for example the details and policies which might relate to those details.

The data point model tries to solve this issue of trying to figure out whether to model something as a concept or as the [Member] of an [Axis] (i.e. this issue is not unique to the US GAAP Taxonomy) by modeling a set of base items as concepts and all further details as [Member]s of an [Axis]. However, that might be a bit too radical of an approach to standardize on. But the data point model is additional justification to vier toward using [Member]s of an [Axis] if you have a choice between two options.