Digital Financial Reporting

I mentioned how interesting and useful what I called "hypercube jumping" is, which the Firefox XBRL Viewer add on provides, in a prior post on my blog. In another blog post I pointed you to a sample XBRL business report which is well modeled so you can experience this for yourself. Just in case you don't want to install the Firefox XBRL add on but you do want to see what I am talking about, here is a one minute video screen capture which shows this "hypercube jumping" in action.

Many SEC XBRL filings are also worth trying out. Here are two which I have played with: Apple and Carnival. Try right clicking on the balance sheet line items and see which networks you can jump to. Or try net income on the income statement, that usually has a number of places which it is linked to.

And don't forget about the ability to reconfigure the information. Experiment with that, notice what is going on. (Here are some small samples which you can use to experiment with. Although, the hypercube jumping won't be that great because these isolated examples.)

While both the "hypercube jumping" and reconfiguring the information leaves a lot to be desired, if you really think about what it going on it is pretty useful.

But "hypercube jumping" is not the right term to describe what is going on. I don't know what to call it yet, but here are some clues that some other term is more appropriate to describe what is going on. (If you wanted to follow along, I am using this sample SEC XBRL filing to experiment with, grab the XBRL instance and try these for yourself):

• Dimensions or [Axis] jumping. If you go to the balance sheet and right click on the "Report Date [Axis]" or the "Legal Entity [Axis]" (on the top part of the rendering) you see a list of all the networks which contain hypercubes (SEC XBRL filings call these [Table]s) which use those [Axis].  So, it seems you can also jump from place to place in the report using [Axis]. (Now, what is a bit confusing is that you cannot do the same thing for "Entity Identifier" or "Date", but it seems to me that you should be able to do that, they are dimensions also.)
• Concept or [Line Items] jumping. Try jumping from the balance sheet to the detailed disclosures for "Inventory, Net" and "Property, Plant and Equipment, Net". Now, it is hard to tell this from the viewer but if you look closely you will notice that the inventory details are modeled as concepts and the property, plant and equipment details are modeled as [Member]s of an [Axis] or dimension. Both get you where you want to go, from the summary on the balance sheet to the details or from the details back to the balance sheet. But I am not sure that "concept jumping" is right really because the concept is really nothing more than a special type of [Axis] or dimension.
• [Member] jumping. OK, looking back at the first bullet point, what you are actually clicking on is the [Member] and not the [Axis]. Perhaps it is the values of the [Axis], which I am calling [Member]s, which is what enables the transition from summary to detail.
• [Table] or hypercube jumping. To round out this list, let be both point out that all the [Axis], [Member]s, [Line Items], are all tied together with either explicit [Table]s or implicit tables. So, you really don't even need a physical hypercube to "jump" from place to place in a report.

(NOTE: If you are confused by the terminology I am using, see the SEC XBRL Primer here on this blog post.)

Are you confused? Yeah, so am I.  But this is what I think I am seeing. What I call "hypercube jumping" appears to be simply leveraging the meta data relationships within an XBRL taxonomy and XBRL instance. The Firefox XBRL viewer appears to be hung up on the XBRL syntax.  It leverages explicit XBRL Dimensions information, leverages the implicit XBRL information such as entity identifier and period for rendering the business report, but it does not appear to be leveraging that "quasi" dimensional information (it is NOT XBRL Dimensions meta data but it is dimensional information).

Another thing which the Firefox viewer add on does not seem to be leveraging is the information models. If you notice how poorly a [Roll Forward] renders in the Firefox viewer add on, but then you go look at a [Roll Forward] rendered by the SEC Interactive Data viewer, you can try any [Roll Forward] such as the cash flow statement or the disclosure changes in warranty accrual in this SEC XBRL interactive data for Apple, the SEC Interactive Data viewer renders [Roll Forward]s quite nicely.

What I think I am seeing is "metadata leveraging". The Firefox viewer add on is leveraging meta data to jump from place to place in the report.  It is also using metadata to render the information and allow you to pivot the report on its [Axis] or dimensions. This is pretty slick! Don't get confused by the limitations of the Firefox XBRL viewer add on.

(This blog post is perhaps even more stream of consciousness than normal, sorry.  I am still trying to figure this out.)

What started, I guess, back in 2007 when we started to create the US GAAP Taxonomy Architecture has finally arrived where I have been trying to get it since that time. Intermediate steps in the process were XBRLS which Rene van Egmond and I created and the Business Reporting Logical Model which was created by the XBRL International Taxonomy Architecture Working Group.

SEC XBRL Filing Logical Model

I have condensed the US GAAP Taxonomy and SEC XBRL filings into what I believe is a simple, easy to understand and easy to implement logical model. I believe that this logical model, once implemented within software applications, will shield business users from the significantly more technical XBRL syntax. It will also contribute to more consistency in SEC XBRL filings.

Here are things which help to explain this logical model.

• SEC XBRL Filing Primer (Draft). This PDF file provides an overview of the model as well as details. In addition, a number of appendices at the end help to understand certain more detailed aspects of XBRL, should one be interested.
• Logical Model Mind Map. This PDF file provides a visual representation of the components and relations between components which make up the logical model.
• Reorganization of Select 2011 US GAAP Taxonomy Networks. This link is to a viewer which lets you look at a reorganized version of select networks of the US GAAP taxonomy to help you see what the taxonomy would look like if it were remolded to adhere to this logical model. The two primary things done by this reorganization are: (a) model all taxonomy components as explicit [Table]s and (b) consistently model the [Line Items] of each [Table] to conform to a specific set of information models articulated by the logical model. For more information about this reorganized version see here and here.
• Reference Implementation. This link takes you to a reference implementation of an SEC XBRL filing instance and supporting taxonomy which complies with this logical model.
• Comparison test. This link takes you to three XBRL instances which allow for testing comparability between the filings.  This is the reference implementation (above) plus two additional copies. Many of the components are comparable, others are not. This shows what contributes to comparability and what takes away from comparability.
• Relations and Table Info Sets. These two XML files instantiate the relations and tables of the reference implementation above into info sets which use the terminology of the logical model. These info sets help one better understand the components of the logical model. (Note that these are best viewed using Microsoft Internet Explorer.  If you don't see the XML, view the source within you browser.)
• Set of US GAAP Taxonomy Tables. This RSS feed provides a list of the [Table]s in the reorganized US GAAP taxonomy networks.  This helps one see that the elephant can be broken down into bite size chunks. In is my belief that many of these tables need to be further reduced.
• Information Models (A.K.A. Meta patterns, DRAFT). This explains the notion of an information model. (Note that I used to call these meta patterns. This needs to be updated, but it will work in the interim to help you understand what an information model is.

Additional useful examples, business use cases, and other samples can be found here.

Over the past several weeks I have reorganized approximately 57 networks in the US GAAP Taxonomy for a number of purposes. I want to explain what I have discovered.

Official modeling

As a reference point, let me point you to the a rendering of the official modeling of the US GAAP Taxonomy which you can get to here. This is a collection of the networks from most of the commercial and industrial companies entry point. I left a few out.

Reorganized version

You can get to my reorganized version of the US GAAP Taxonomy here. The reorganized version is a select number of networks from the commercial and industrial companies entry point, about 57 networks. If you go through the taxonomy you will see:

• Everything is within an explicit table.  Everything is modeled within an explicit [Table]. This does a number of things.  First, in order to get the pieces to integrate correctly, you need to do that anyway.  More on this in later blog posts. Second, it allows you to "eat the elephant in bite sized chunks." Basically, to me this seems far more manageable.  Third, it give you "a list" of the things in the taxonomy.  In fact, here is that list of [Table]s.
• Consistent, explicit information models. Everything within a [Table]'s set of [Line Items] is is modeled consistently and explicitly.  In the official version, the [Roll Forward] is well identified.  But, the use of [Abstract] is overloaded and could mean three things: [Hierarchy] to indicate a hierarchy with no numeric relations, [Roll Up] to indicate XBRL calculations, and [Abstract] to indicate that is simply upper level organization of the taxonomy. All the information models in the reorganized version are explicitly identified and consistently modeled.

Benefits seen

Here are the benefits that I have observed;

• "The list". You have a list of things which you can easily pull from the taxonomy. Don't get confused here.  Could you easily pull all the [Table]s from the US GAAP taxonomy in its original form?  Sure you could.  The point is you could not pull out everything else in a meaningful organization.
• Reorganize "the list". This list is fine, but this list is better. And this RSS feed is even better. I reorganized my own list easily, because all I had to do is put the tables inside some sort of organization. Besides, I have some list of things I can point to.
• Easier to read the taxonomy. The taxonomy is way, way easier to read and comprehend.
• Eat the elephant in bite size chunks. Because you have identifiable pieces, it is easier to manage the smaller pieces individually.
• Fit into one logical model. Because the taxonomy is consistent, It all fits into one logical model.  Rather than having to deal with XBRL syntax, users can deal with logical model semantics.  More on this later.
• Easy to see semantic flaws. It is easy to see some pretty easy to recognize semantic flaws. See this blog post and this document for more information. For example, why would balance sheet line items and things which could be balance sheet line items have different [Axis]?  From a business semantics point of view this makes no sense.

Still to do

There is still a lot to do really.  This was my first pass. I did not remodel everything, I only moved everything into [Table]s and made the [Line Items] consistent. It is my view that many of the [Table]s are still to big to be optimal for SEC XBRL filing creation or for analysis of the information, they could stand to be smaller.  From what I am seeing there should be more like 750 [Table]s than the 244 that I have.

Also, I need to create the XBRL Formulas which express the financial integrity (i.e. business rules) within each [Table] and between the [Table]s.

Also, I have to totally remodel the Statement of Changes in Equity [Table]. That simply will not work. Not that hard, it is not a [Grid], it is simply a [Roll Forward] like all the other [Roll Forward]s.

And I need to synchronize my reference implementation to the reorganized taxonomy.  I created this to prove what I thought would work would, in fact, work. I have to circle back on a few things.

As a by-product of something else I was working on I have some observations relating to the use of [Axis] in the US GAAP Taxonomy. You can grab the information I summarize here.  The following is a summary of some observations/questions which I have:

• Three different sets of [Axis] for Other Comprehensive Income (Loss), Net of Tax.  Why is it that Other Comprehensive Income (Loss), Net of Tax is modeled in three different areas of the US GAAP Taxonomy with three different sets of [Axis]? Why would how something is modeled change based on where in the taxonomy that it is modeled?
• Balance sheet line items and possible line items in disclosures not in sync. Why is it that the balance sheet is modeled as a [Table], yet line items which could go on the balance sheet as line items and would certainly tie to the balance sheet are not modeled as a [Table]? Seems logical that each of these list of detailed items would have the same [Axis] as the balance sheet if they are modeled as concept.  (If they were modeled as dimensions of a concept I can see why the [Axis] would be different.)
• [Table Text Block] go inside or outside a [Table]. Why is it that the same information is outside a table if it is [Table Text Block] tagged (block tagged), yet if that exact same information is detailed tagged, then it is modeled within a [Table]? It seems to me that whether something is "block tagged" or "detailed tagged", it still relates to the [Table]. The only difference is whether one tag is provided (i.e. for block tagged) or multiple tags are provided (i.e. for detailed tagged) for the information relating to that [Table].
• Class of stock [Axis] different on balance sheet and in disclosures. Why is it that common stock and preferred stock modeled on the balance sheet has different [Axis] than the same information modeled in the disclosures? The disclosure for class of stock information makes more sense than that information as it exists on the balance sheet.  Also, it seems to me that it would be more appropriate to have "Class of Preferred Stock [Axis]" and "Class of Common Stock [Axis]" and separate the disclosure into two disclosures, rather than putting two different things together. Treasury stock I am not sure about, I need to research some things.

Basically, I would advise caution when it comes to figuring out which [Axis] to use in SEC XBRL filings.  These sorts of inconsistencies point out that how the US GAAP Taxonomy is modeled might not offer good guidance.

It simply cannot be the case that where in the taxonomy that something is modeled (i.e. in which network) has anything to do with what [Axis] are assigned to the [Table] or whether something should be modeled as a [Table].  The way I see it, this provides additional information that everything within the US GAAP Taxonomy should be modeled as an explicit [Table].

Check out my details and go look at the 2011 US GAAP taxonomy (commercial and industrial companies entry point) for yourself.  I would be interested in the conclusions which you reach.

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.