« Reasons Why Fundamental Accounting Concept Tests Fail | Main | Fiddling Around with Fundamental Accounting Concept Report Frames »

SEC XBRL on IBM Bluemix

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.

Posted on Saturday, September 27, 2014 at 08:40AM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.