Digital Financial Reporting

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.

The US GAAP Taxonomy v1.0 is open for review comments.  I would encourage people to submit their comments or even just register to obtain access to the tracking system; that way you will receive an email of all the comments submitted by others.

You can register to provide feedback at this URL:  http://xbrl.us/usgaapreview/Pages/default.aspx

UBmatrix, Inc., the leading provider of XBRL information exchange solutions, is offering a free online seminar on June 25th for CFOs and senior financial executives on the recent SEC rule proposal for mandatory filing of SEC reports in XBRL.  For more information about this webinar, please see:  http://www.marketwire.com/mw/release.do?id=869805

This entry starts a thread communicating my personal take on the SEC proposed rule mandating XBRL for reporting by public companies.

The bottom line, in my view, is that I think the propose rule is really good all things considered.  The best section of the rule is section II. C. 2. Use of Technology to Detect Errors (page 57 through 67).  I think the wording provides a lot of insight into how the SEC thinks about XBRL.  Specifically, these sections stand out:

• "After the FDIC required submission of interactive data, it reported that its analysts were able to increase the number of banks they reviewed by 10% to 33%, and that the number of bank reports that failed to fully meet filing requirements fell from 30% to 0%."  (page 59)
• "Because analysts and other users would rapidly discover mistakes or alterations not consistent with the desired use of interactive data, filers would have a powerful incentive to prepare such data with care and promptly to correct errors." (page 59)
• "We expect that each filer would be in the best position to determine the appropriate manner in which to assure accuracy of the interactive data it would be required to submit and the viewable interactive data would result.  We also expect that software providers and other private sector third parties would help develop procedures and tools to help in that regard." (page 63)

At a conference I attended a speaker stated that "...the market is the best regulator..."  I agree with that statement.  As it becomes easier and easier for investors and other analysts to make use of interactive data; the data will get better and better.  Even better, public companies can use these same automate processes to get the data to the same quality level which exists now and even higher...but the cost of achieving this quality level will drop as more of these processes become automated.

The section of the proposed rule that I liked the least was the section discussing "levels of reporting".  This is section II. B. 3. a. Financial Statements and Financial Statement Schedules (pages 41 through 50).  Specifically, I have trouble with the following section:

• "This would be accomplished by tagging the footnotes using four different levels of detail:" (and then it goes on to list four bullet points, page 42)

This section is not only hard to follow but it just won't work.  This is one area where I will be sending in comments to the SEC.  The primary reason that I don't like this (other than the fact that it simply will not work) is that it is "document centric" in nature, where the SEC keeps trying to say they want to change EDGAR from a filing cabinet to a database.

Anyone who understands the rules of normalization which is applied to a relational database understands that duplicating data is a very, very bad thing.  "Levels" is exactly that, duplicate data.  Very, very bad idea.

Secondly, if the details are provided, any "level" can be created by combining the details to whatever view a user might desire.  However, a computer application has a hard time parsing "chunks" (i.e. what the SEC says should go into level "i").  Further, if anyone sat through the conversations which took place when creating the US GAAP Taxonomy (or any other taxonomy for that matter) they would realize that it is impossible to agree what would go into each footnote.  Different companies would want to group these footnotes in different ways.  Evidence of this is the different ways companies group things today.

I say that multiple levels is a very bad thing.  In the short term, sure.  Whatever it takes.  Longer term though, the details is all that is needed.  Users will create all the levels they need.  Getting companies to agree on how to combined things into comparable footnotes simply will not work, in my view.

What do you think?  Post a comment or send your views to the SEC.

The US Security and Exchange Commission issued proposed rule 33-8924 on May 30 which would mandate the use of XBRL.  The rule is 143 pages and is packed with great information.