Digital Financial Reporting

An updated version of the document US GAAP Taxonomy - Tips, Tricks, and Traps is available.

US GAAP Taxonomy - Tips, Tricks, and Traps

Changes in the new version include building out the remaining networks (extended links) which were incomplete in the prior version, general proofreading edits.

If you had the draft of 2008-07-28, the first 34 pages really did not change much at all.  The vast majority of the additions were after that point.

The authors of the document want to thank those who have provided comments and other feedback.

All to often, XBRL is seen as simply something they may need to file with the SEC because they have to.  Here is an example of why this view is mistaken.  Consider the following screen shot:

I remember back when I was in college trying to understand how to compute the present value of net minimum payments under capital leases.  Intermediate Accounting was the class where I was exposed to this.  I sort of got this then, enough to pass the class at least, and enough to pass the CPA exam.  But look at this image above.  How helpful is that, which is a tree presentation of what is in the US GAAP Taxonomy, at understanding how the present value of net minimum payments is calculated?  I say quite helpful.

Now, I don't know about you, but (a) I am not very good at memorizing all this stuff and (b) frankly, I would consider myself a pretty average (at best) accountant. This stuff has been a HUGE help in understanding accounting.  All laid out for you.

Another point is that I was fortunate enough to participate in the creation of both the US GAAP Taxonomy and the IFRS Taxonomy.  (This was a great exposure into the world of IFRS for me).  I noticed during the creation of the taxonomy that (a) the accountants did not always agree where things were supposed to go, at least at first, (b) may times people had their understandings incorrect.  The best example of this was the creation of the income statement with all those "steps" toward arriving at "Net Income" (extraordinary items, discontinued operations, cumulative impact of accounting changes, and all that stuff).  People would get those in the wrong order.

Particular for average accountants like me, the UGT is quite a reference resource.  Even if you never use it to report a financial statement using XBRL, the UGT basically allows average accountants to more easily understand all this stuff.  And for accounting students, it seems to me this is even better!

A document called US GAAP Taxonomy - Tips, Tricks, and Traps is available here on this blog.  On that page there is an abstract of the document.  In summary, the document provides:

• A framework for understanding the US GAAP Taxonomy.
• Tips, tricks, and traps which relate to the entire taxonomy.
• Tips, tricks, and traps which relate to each network (extended link) within the taxonomy.  Of the approximately 60 extended links in the commercial and industrial companies entry point, 32 of those networks are completed.

The document was created by Christine Tan and myself.  Both of us worked on the US GAAP Taxonomy project team.  In talking to others who were trying to understand the taxonomy we heard that they really did not know where to start.  We believe that is document provides an excellent starting point.

More information is available on the page noted above.

There are many different ways to view the US GAAP Taxonomy (Version 1.0).  Just looking at the set of files is not what XBRL is all about.  Rendering the information within those files is much more interesting to business users.  Eventually, these applications will get better and better. This is a summary of many of those ways (if you know of other viewers, email me and I will add them to the list):

• Official Version:  This is the official version of the UGT.  You can basically browse the file structure, grab a file.  This is not really that useful to business users, but you can use this to see what is going on behind the scenes.  Software applications will likely grab files from here, cache them on your local machine to improve performance.
• Download:  You can download a copy and use the local version here.
• Viewer Application:  Here, you can view the taxonomy within a viewer application.  Hopefully, lots and lots of these types of applications will appear with increasingly better interfaces.
• Another Viewer Application: This is another viewer application.
• Excel:  This is an Excel spreadsheet which has the CI entry point loaded in it.  You can use the features of Excel to sort, search, etc.
• The Future:  This is not the US GAAP Taxonomy, but imagine an interface which looks like this.  This is slick!  (Developers, note the source code which is provided. Come up with something interesting and email me a link and I will reference what you created).

Each of these options has its pros and cons.  What is the coolest is that there is a possibility to do this because of XBRL.  If the US GAAP Taxonomy was in the form of a piece of paper, a PDF file, or even a set of HTML pages on a web site; repurposing the taxonomy would be significantly hard or flat out impossible.

What I look forward to is being able to do the same thing with the thousands of SEC filings which will be appearing over the coming years!

It seems to be a majority opinion that there is some sort of rendering issue with XBRL.  I have a different view.  It has been my experience that rendering XBRL is actually not all that challenging.  This document was generated from an XBRL instance document using XSLT to generate XSL-FO, and then the XSL-FO was sent to an FO processor to generate the PDF rendering.  I have no real problem with that rendering.  Also, I was the one who created this, not a developer who really understands how to create XSLT who probably could have done a better job.

The issue with rendering XBRL is really a meta-data issue. 

Generally, there is not enough information within a taxonomy to enable the desired renderings.  Three other things get in the way also.  The first is inconsistencies in the taxonomy make it harder to render instance document information.  The second is that taxonomies tend to be modeled around a presentation perspective rather than a more appropriate data modeling perspective.  And finally, taxonomies tend to be build in huge chunks, as opposed to smaller components which help software render instance documents build against the taxonomy.

In fact, a well modeled taxonomy can also solve the problems related to creating a consistent taxonomy, it can solve issues related to users properly extending the taxonomy, and in addition it enables rendering information contained within instance documents in a manner human readers can understand the data.

A really good example of what I am talking about can be seen in the samples provided with XBRLS which you can see here. 

So what is the key here?  The key is a modeling layer.  Being a CPA and not having an IT background I may explain this a little incorrectly; but the essence is that the same things should be modeled in the same ways within a taxonomy.  A modeling layer is somewhat like a template which guides the creation of a taxonomy.

The US GAAP Taxonomy uses this modeling layer type of an approach.  It is about 98% there.  But, it needs to go the final 2%.  Two things will be achieved by doing this.  The first is that it will have a complete modeling layer and the second is that because of the modeling layer, the taxonomy will be more consistent.

Let me give you a few examples.  You may have noticed things such as [Table], [Domain], [Member], [Line Items], and [Roll Forward] in the US GAAP Taxonomy.  The US GAAP Taxonomy Architecture document even discusses some of these, see section 3.3 Tables, Line Items, Axes and Domains; also 4.5 Implementation of Tables discusses this.  And if you look at the taxonomies, you will see more examples of this.

I created a little view of one extended link of the US GAAP Taxonomy.  You can take a look at this here.   To view this, open the file in your browser (Internet Explorer, but you have to have the Microsoft .Net Framework 3.5 installed (you have this if you are using Vista, but you can download and install it if you are still on XP).

In that file, notice all the colors.  Notice how consistent the colors are within the assets and liabilities section of the balance sheet.  But in the equity section it is significantly more inconsistent.  It could be consistent.

The bottom line is that if taxonomies in general, and the US GAAP Taxonomy in particular, had just a little more meta data; then the following can be achieved:

1. More consistent taxonomies can be created because that meta-data can be used to enforce the consistency.
2. The consistency and the models (templates) used to create that consistency can also be used to enforce quality extensions of the taxonomy.
3. Effective renderings for human consumption can be generated (for example, one style sheet or other process could be used to effectively generate a human consumable rendering for SEC filing.
4. Using the taxonomy becomes easier because users can deal with the taxonomy (when creating the base taxonomy, creating extension taxonomies, creating instances, and analyzing instances) at the modeling layer and never have to go down into the XBRL layer.

It takes a little more than just the models, the models also have to be good organizations and good modeling of the data.

Another reason that a data oriented view of the taxonomy is important is that it is easy to agree on.  The data is the data, it is rather straight forward.  But how to present that data has a many, many different options as many, many people have many, many different views of what the best presentation is.

Further, if this is not done the following will occur.  The first thing is that application developers are going to have to somehow assign this meta-data to the taxonomy somehow, outside the taxonomy, probably in code.  This will be expensive, it will not be reusable on other taxonomies and it will have other negative ramifications as it fights the symptoms, rather than solve the problem.  You will also still have the extension issues and inconsistencies in the taxonomy to deal with.  Rendering the extensions will be even more of a challenge, as the software developers will have to take each and every filing, and the inconsistencies they posses (as there is not way to currently control the inconsistencies).

I would love to be wrong about all this, but I think I see this correctly.