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.

The IFRS Taxonomy Modules Manager (ITMM) which is available here.  I would encourage business users to take a look at this as it provides some insights for business users.

What the ITMM is trying to do is pull the pieces of a taxonomy together which a preparer would use to construct a business report, likely a financial statement.  The user makes use of the application to select the pieces and then the application builds the underlying XBRL "stuff" (it is called a discoverable taxonomy set or DTS, but business users should not have to understand this level of terminology) which will be used to create an XBRL instance document (an XBRL based business report).

What is good about this is that it shows something very important to realize, particularly if you are a business user.  This important point is that software can be built to do things like this.  All a software application has to do is spit out the required XBRL.  How it gets there is up to the software application.  Don't like how the software application works in terms of features?  Just give the feedback to the software developers, they can make it better.

Some features I would like to see related to this are:

1. Business users don't need stand alone systems like this, they need this functionallity within the tool being used to create the XBRL based business report.
2. Smart wizards which know what sorts of things might go together, nor never go together, would certainly help the user out.  For example, the user is generally going to want ONE cash flow statement, not even be able to select both for one report.
3. Generate "templates" of the common stuff which is used, but the business user can then "turn on" or "turn off" pieces of the taxonomy, rather than have to wade through the entire taxonomy.

These are just a few obvious features.  This list is not knocking what the folks at the IASCF are doing, but rather trying to help business users understand the types of things they could, and should, be asking for from software.

I have realized something which has caused a change in thinging.  XBRLS really should be two pieces, not one piece.  Right now, XBRLS combines an architecture and a modeling layer.  There are benefits to having these two pieces separate.

The benefit of an architecture layer is that you can constrain the generally too numerious options offered by XBRL.  You can also remove unnecessary and undesirable flexibility which exists within XBRL, making your system easier to build and use.

The modeling layer helps build your taxonomy consistently, helps users of the taxonomy understand the taxonomy easier, allows for software to be created more easily and enables the creation of features which make it easier for a business user to create, use, and report against a taxonomy.

While all systems need some sort of architecture and some sort of modeling layer; separating the two allows for reuse of the architecture.  I am not sure if a modeling layer would be usable if it were moved to a different architecture, have not thought about that much and have not really experimented with this idea much.

More information on what a modeling layer is, its benefits, and how to create one coming soon!  Stay tuned.

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.