Digital Financial Reporting

I explained in detail in this PDF why the SEC XBRL financial filing information is so hard to use and how to resolve that issue.  This document is helpful to that end, using the information; but it is also helpful to those designing or otherwise creating XBRL taxonomies because it helps them avoid the same problems.

Fundamentally, getting to the information is trivial and I walked you through how anyone with Microsoft Excel who can write rather basic macros can get at 100% of the information from all those SEC XBRL financial filings.  I even point you to a number of prototype applications you can download, reverse engineer, and create your own applications.  And frankly it is near magical how someone with even my limited understanding of programming can get to each piece of information and there is a lot that you can do with that information.

However, when you try to compare information you run into troubles. As I see the facts you run into so much trouble that you basically have to do a one-to-one mapping between each filing you want to use and some target you desire to use in order to compare two or more filings.

What this means, it seems to me, is that the only way an individual investor is going to get to use that information is if they buy it from some third party data aggregator who sorts all that data out for them, inuring substantial costs in the process and therefore having to charge hefty fees for the use of the information.

Is that really what the SEC intended?

If you look at why the information is hard to use by reading that PDF you will realize that solving this issue is really quite simple.  The FASB and SEC need only do a few rather easy things to do and the information will be easily comparable at a level which would make most people happy, it seems to me.

This is not to say that all comparability problems will be solved.  Those issues will take decades to figure out and relate to the nature of US GAAP and financial reporting in the US as practiced.  The easy way to make the information comparable is to turn US GAAP into "a form".  Then comparisons would be trivial, but the information would not be that rich or meaningful.  At the other end of the spectrum is to continue to give the users free reign to do whatever they desire, extend anything they want, report exactly how they see fit.  That will maintain the richness of and I believe highly valued style of financial reporting as practiced in the US today. Clearly what is reported could use some improvements, what I am talking about is the fundamental nature of public companies reporting to the SEC to tell their story, their way.  That is a highly prized characteristic of financial reporting as I see it.

Is it the case that some hybrid solution can be arrived at?  Some information is closer to that of a form and very comparable, but other sections of the report can be more ad hoc so companies can tell their story, their way.  Can some workable balance be struck between the two extremes?

What do you think the right balance should be?  How do you see the facts?

Compliance Week reports that the SEC is calling for patience from filers, saying that the benefits will be there at an AICPA conference.

The Compliance Week article also reports:

Susan Yount, a staff member in the SEC's Office of Interactive Data, said during the conference that Congress is showing a growing interest in structured data as a way to improve reporting for various government programs and initiatives. “This is an area that is not going to go away,” she said. “The notion of transparency and providing information in a format that can be put into a data warehouse and pulled out is a notion that in the 21st century is here to stay. If Congress, of all places, is interested in it, you can look for that sort of thing in the future.”

Arelle is an open source XBRL processor/platform which was written in python by someone who has a lot of expertise with XBRL. Arelle supports XBRL 2.1, XBRL Dimensions, Inline XBRL, the Generic Linkbases specification, the unit types registry, XBRL Formula, U.S. SEC Edgar Filer Manual, IFRS Global Filing Manual, and HMRC Joint Filing Checks. Arelle runs on Windows and the Mac OS.

XBRL Spain, which is a major contributor to EuroFiling and OpenFiling, has created an Arelle User Guide.

Pyke is an approach to logic programming, inspired by PROLOG, that is written in Python.

pyDatalog is another approach to logic programming written in Python.

I have updated a taxonomy exploration toolwhich is useful to accountants who want to learn about XBRL taxonomies by comparing/contrasting different taxonomies.

The tool is Microsoft Excel-based, 100% modifiable/configurable (i.e. the VBA code can be edited to your heart's content.

There are 1480 SEC XBRL 10-K and 10-K/A filings which were filed between January 1, 2011 and November 30, 2011, per the SEC RSS archive, which this tool reads.  Well actually, the tool reads infosets generated (thank you to XBRL Cloud for providing this conversion) from the SEC XBRL filings, so access to the taxonomies is quite fast.

Features include:

• 1480 SEC XBRL 10-K and 10-K/A filings categorized into sector
• The ability to load the taxonomy presentation relations into Excel where you can further tweak how you interact with the filings
• The ability to read the taxonomy presentation relations within a treeview-type interface

You may have to configure the application to work with the version of the Microsoft XML parser on your computer.

This version is unsupported.  If you desire to have a supported version or are looking for some specific functionality, contact me and we may be able to work something out.  Other such analysis and query applications are available should you need them to meet some specific need.  Contact me for more information.

There are two additional interfaces into this information. 

The first is a set of HTML pages. This is a simple, static interface which lets you look at the taxonomies of the filers.  A table of contents is provided which lists the filers in alphabetic order.

The second is an RDF file.  This XML file basically lets you create whatever user interface you want, given the metadata and data available.  This set of XML infoset files is basically what drives the Excel-based application above.