SEC XBRL on IBM Bluemix
Saturday, September 27, 2014 at 08:40AM
Charlie in Demonstrations of Using XBRL

Ted Potma, Product Manager at IBM Canada Ltd, created a demonstration of IBM technologies SEC XBRL on IBM Bluemix.  There is a LinkedIn discussion related to this demo.  Basically, you enter an entity name, enter a concept, and you click a button and get a graph of the concept over time.

This is worth checking out and the LinkedIn discussion is worth reading.

One thing I learned from the discussion is that there is API level access also.  Seems like the API level access flexible.  So for example, HERE I used a CIK number and a concept. And here is another.  That is rather nice.

Although, this is a little troubling. If you go to the "About" page you will see the following:

No Extension Elements

Any facts that use an extension element as their concept are ignored. Likewise any fact that is dimensionalized using extension elements as axes or members is ignored.

 This can be explained with one word: comparability. If what we want to do is graph one organization's assets against another, we need to ensure that they define "assets" the same way. The SEC allows me to file ted:Assets instead of us-gaap:Assets if I so choose (assume the "ted" prefix doesn't resolve to a us-gaap standard namespace). This allows filers a great deal of freedom, but drastically reduces the usefulness of the data.

 There's also the hope, however distant, that this may sway the SEC into restricting or even eliminating extension elements/taxonomies all together. At the last IBM Vision during the XBRL workshops IBM's clients expressed that they don't see any real value to creating extension elements, and only do it because they have to.


That is telling. Totally misguided, but none-the-less telling. Clearly whoever wrote that does not understand US GAAP, financial reporting in general, or the power of appropriately used extensions to enable a reporting entity to articulate the nuances and subtleties of their reporting entity. Understanding these nuances is critical to understanding the financial position and financial condition of an economic entity.

Now, I am not saying that the way the FASB and the SEC are using XBRL's extensibility is correct. It is not correct and therefore it may appear that extensibility should be ditched.  But that would be like throwing the baby out with the bath water. Perhaps another alternative is to employ XBRL's extensibility appropriately.

Basically, that statement about how this system is handling extensions basically says "RDF is of no value". Do they REALLY mean that???  Seems like semantic realities of the system are being cast away for the sake of expediency.  Probably does not handle amended filings correctly.  Might not handle currency/units correctly. Certainly will not be able to deal with restated financial information.  Probably cannot deal with reclassified financial information.

Article originally appeared on XBRL-based structured digital financial reporting (http://xbrl.squarespace.com/).
See website for complete article licensing information.