Digital Financial Reporting

Imagine that you were using a software application to go grab information from an SEC XBRL filing.  What would you tell the software to go get?

The networks? Well, everyone of those is different for every single filer.

The [Text Block]s? Not everything is contained with a [Text Block].

The explicitly defined [Table]s? Not everything is defined within a [Table]. Further, explicitly defined [Table]s are also contained within implicitly defined tables which makes the structure confusing.

(Note that if you don't understand the terminology above, this blog post explains the logical model of SEC XBRL filings.)

Or would you need to grab some combination of the above? Well, what combination would that be?

No Good List

Basically, there is no way to understand what information to grab from an SEC XBRL filing. Sure, you can grab individual facts which have been reported but generally you want to work with sets of facts. The US GAAP taxonomy does not provide a means to know all the things which are being communicated by the taxonomy.  In fact, it actually gets in the way by nesting things within other things.  There is no good "list" of what you have to work with.

Prototype List

But what if there were a list of information which you could grab?  Here is one such list of things one might be interested in taking a look at within an SEC XBRL filing. Don't like my organization? There is a very high probability that you won't like it. In fact, anyone could reorganize what I created, creating their own organization of the information.

Prototype Reorganization 2011 US GAAP Taxonomy

How did I do that? How did I come up with a list and the organization of the components of that list? Well, I reorganized the 2011 US GAAP Taxonomy by doing the following:

• Everything is modeled within an explicit [Table]. In order to make the implicit tables more visible and make things consistent (and to avoid nesting things within other things), I explicitly defined everything which can be reported within a [Table].
• Every [Table] is unique.  I did not name things the same, for example "Statement [Table]" which is used for the balance sheet, income statement, statement of cash flows, etc. That way, I can work with [Table]s, not have to worry about the network which contains the [Table]. So, from a syntax perspective, I don't have to deal with the network and the [Table] to uniquely identify [Table]s.
• No [Table]s are nested in other explicitly defined or implicitly defined tables. XBRL syntax does not allow for a table to be nested within another table.

In order to create a more flexible, usable US GAAP Taxonomy; I prototyped what I am talking about by taking a select number of networks from the commercial and industrial companies entry point and I modeled them using the approach I mentioned above.  You can get to this prototype here.  I have completed about 25 of 50 networks which I want to eventually reorganize.  This is plenty to show what I am talking about.

There are two ways you can view the information. There is a "static" view which provides a flat list.  Here is an example of a static view. The other view is a "dynamic" view, and here is an example. In the dynamic list, clicking on the "+" or "-" signs allows you to expand or collapse the tree view which can help you see the many aspects of the taxonomy organization better.

Again, I modeled everything within a [Table], every [Table] is unique. [Text Block]s and [Table Text Block]s are also within [Table]s because a filer is allowed to (a) block tag things or (b) detail tag things; but the thing that they are tagging (i.e. the information communicated by the [Table]) is the same.

I did a couple of other things to make the information more readable in the taxonomy.  The marker [Abstract] is used in three ways in the US GAAP Taxonomy.  First, it is used for organization in the upper levels of the taxonomy.  Second, it is used to model what amounts to a "roll up" type computation, so I changed those to [Roll Up], similar to how the US GAAP Taxonomy uses the [Roll Forward].  The third way [Abstract] is used is to model relations where there are no numeric relations (i.e. not a [Roll Forward] and not a [Roll Up], but there is some sort of relation.  I call this a [Hierarchy] and I have explicitly defined those also.

Another thing I did was not intermingle the information models.  For example, the line items of a balance sheet are basically two big [Roll Up]s: one for Assets and the other for Liabilities and Equity.  The way the FASB modeled the balance sheet, multiple things were intermingled in the equity section of the taxonomy (see here).  Before "Temporary Equity" (ID 459), the taxonomy is quite easy to understand.  After that point it gets rather confusing.  See my remolded version here.

Lastly, I modeled the data, not how someone thought the information would be presented by someone. I don't want to get into that discussion here but I will raise one question in your mind about this.  Why is it that the concept "Cash and Cash Equivalents, at Carrying Value" which is used on the balance sheet, on the cash flow statement, and the disclosures have no [Axis] in some places, one set of [Axis] which includes a "Class of Stock [Axis]" on the balance sheet, and yet a different set of [Axis] on the cash flow statement.  Ask yourself that question. This makes no sense from a business semantics perspective.

Existing 2011 US GAAP Taxonomy

As a point of reference, you can see the existing 2011 US GAAP Taxonomy here in a viewer I created. Look at that taxonomy modeling, look at my modeling, which do you prefer?

Have it Your Way

This is not to say that any one specific approach is absolutely correct. Every user should have an ability to get at the pieces of the US GAAP Taxonomy using their preferred approach. That is why I believe the US GAAP taxonomy should be constucted to be reorganized.

To do this you need both a "list" of stuff and an organization that does not get in the way of you reorganizing the taxonomy.  This is not to say that everyone can model all the details as they see fit, clearly that will not work. The model needs to make sense from a financial reporting perspective, that is the detail information model within the [Table], not the list of [Table]s.

And clearly there needs to be agreement on which [Table]s exist, which are required, which are optional.  And SEC filers should be able to create their own [Table]s. The financial reporting supply chain will sort this out. Clearly there are some things which are, today, required.  SEC filers provide balance sheets, cash flow statements, income statements. A balance sheet always has "Assets" and "Liabilities and Stockholders' Equity" or "Liabilities and Partners' Capital".  That is financial integrity. That will make the details both comparable and give SEC filers flexibility to tell their story their way.