Financial Reporting Using XBRL

The SEC announced its successor for the old EDGAR system: IDEA, Interactive Data Electronic Applications).  See the SEC web site.

The press release for the announcement can be found here.  A web cast of the announcement can currently be found here.  (It may be moved here eventually)

IDEA is a new technology/architecture framework.  It is being built along side EDGAR.  The two systems will operate alongside each other for a period of time, then IDEA will be the system used moving forward.  EDGAR information will likely always exist as an archive of company information.

The SEC says IDEA will be global (40 languages as an example), cheaper for smaller companies, the platform for 21st century disclosure, flexible, and easy as possible for investors to use.

The SEC also says that they are not going into the software business, but "e-applications" can be built on top of the interactive data within IDEA.  The SEC gave examples of three applications which would make use of IDEA:  HUB (enforcement tracking), RADAR (analysis of risk), PHOENIX (helps get money back to investors).

No intermediate step of a data provider will be necessary.  Investors will be able to compare companies in a manner similar to how they can compare hotels or airline ticket prices.  Investors may even be able to provide "reviews" of companies.

Neal Hannon and Mike Willis explain three different strategies preparers can use to meet the SEC mandate on the Hitachi Blog.

These three ways are:

• Outsource the XBRL to a financial printer or other EDGAR filing agent
• Use a bolt-on XBRL software package to create XBRL exhibits internally
• Integrate the XBRL mapping inside your normal financial reporting process

The advantages and disadvantages of each option is discussed.

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.