Digital Financial Reporting

I through together a quick and dirty accounting policy viewer prototype using the SECXBRL.info web service API.  There are two interfaces, both of which are HTML based.  This one is HTML5 and uses iFrames.  If that does not work for you, try this alternative interface which does not use iFrames (which I could have goofed up).

Some facts:

• Total time to create: about 2 hours. (Of course, I spent 3+ years working to understand SEC XBRL financial filings)
• Skills required: Accounting knowledge, Microsoft Access, XPath, Microsoft XML Parser, HTML (i.e. no XBRL knowledge required
• Number of filings searched: S&P 500 only
• Queries used: total of 2.  Step one was to find the filings which had the disclosure I was looking for, I picked us-gaap:AdvertisingCostsPolicyTextBlock.  Step two was to use the information returned from the step one query to get the actual policy for each of the companies which reported that policy.
• Number of text blocks available to query: Lots.  See here in HTML and here in XML.
• Value of XBRL-based information: Priceless.

Next step is to do more policies and create my first iPad/iPhone application! (Maybe)

Here is the Microsoft Access VBA code. Here is the Microsoft Access Database table.

Per SECXBRL.info 20% of the DOW 30 companies pass 100% of the fundamental accounting concept validation rules.  See the list here.

Of the 6 reporting entities which pass all of these validation criteria (DUPONT, 3M, Intel, GE, Microsoft, Cisco), two pass all for the first time in 2013 (DUPONT and Cisco).  You can see a comparison for 2011, 2012, and 2013 validation results here.

Half of the DOW 30 passes 90% or more of the fundamental accounting concept validation criteria.

I put together some example dimensional-type queries using the functionality of SECXBRL.info.  You can see and walk through the queries here, or if you want you can download this Excel spreadsheet which executes the queries and populates the Excel spreadsheet with the query results.

While Query 5 which shows a breakdown of assets by business segments is the sexiest example (see the results below), by working through all the examples you can start to see some issues you need to keep in mind when querying information across reporting entities.

(Click to view larger image)

Here is the result of another query of the business segments of the S&P 500. (This is the actual query syntax.)

I am not going to go into any more detail, you can fiddle with the examples on your own (all run on the DOW 30 so you don't need a subscription to the service).

One thing I will point out is how you can manage the reality that some filers have a dimension (or [Axis] they are also called), some do not, and sometimes different dimension-defaults are used by different filers.  Walk through the examples and you can see how you can manage all of that using the query.

I have made available a significantly improved version of an XBRL-based Financial Report Ontology (FRO)prototype.  Again, this is still a prototype; but it yields lots and lots of information.  Fiddle around with it if you are interested.  Most business people probably won't understand what they see.  Truth is, most technical people probably won't understand what they are looking at either.  But both business people and technical people will start to understand more and more once they can see what you can do with all that "stuff".

There are a few things that I want to point out.  First, there is an index page that starts to summarize important pieces.

Second, there are a handful of prototype pieces.  Of particular interest is this: http://www.xbrlsite.com/2014/Protototype/fro/Test_Linkbases3.xsd

It may not look like much, but load that into a good XBRL tool and take a look at the XBRL definition relations and observe what is going on. If you don't have anything else, grab the Arelle GUI tool.  It is a bit hard to use and I cannot seem to get the definition relations to look exactly how I want them to look; but it does let you explore what is going on. If you want to spend the money, CoreFilings SpiderMonkey works nicely.

The image above is how these relations look in my tool (UBmatrix Taxonomy Designer).  If you look at that screen shot and then you step your way through the XBRL linkbase and XBRL taxonomy files, I think you will be amazed.  Or, maybe I am just easily amazed.

The problem with the graphic though is that you cannot see the details of the relations.  You have to see those within some software product. You also have to understand the specific meaning of the relations to fully appreciate what is going on.  The bottom line is this: generic, global standard way of expressing business rules. Why is that important?  Read here.

What you are looking at is numerous "layers" of information which fits together "perfectly".  What I mean by perfectly is not that what I am showing is 100% correct.  What I mean is that if there are errors in the representation, no problem that can be fixed.  But, what is really interesting is knowing THAT you can layer things together like this, THAT it works correctly in XBRL software (4 tools work as expected, 1 does not), and most importantly HOW to achieve this.

I am not going to explain this more right now, I will explain later.  But, I did want to get this out here for people who wanted to understand this sort of stuff and so that I can send something to people that helps them grasp this.

Kudos to the XBRL technical people.  You guys did an awesome job in architecting XBRL.  A lot of things they said along the way that I did not understand at the time, well, those things are making more and more sense.

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.