BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries from June 10, 2012 - June 16, 2012

XBRL International Releases Semantic Model Public Working Draft

I have long called for and pushed for a global public standard logical model of the semantics of XBRL-based information.  XBRL International took a huge step in that direction today when it released the second version of the XBRL Abstract Model.

As of this point I have not read this document thoroughly, but I am quite confident that this is a very significant improvement over version 1.0 of this document which was a muddled UML model of the XBRL technical syntax. 

The scope of the XBRL Abstract Model 2.0 is a good summary of what they are now trying to achieve:

Scope: The abstract modelling task force will be responsible for delivering an UML model which captures the semantics of the XBRL 2.1 core specification and the Dimensions 1.0 specification. The UML model will capture the fundamental¬structures and design of XBRL and XBRL Dimensions as standalone UML artefacts, decoupled from any specific XML syntactical details. The scope was expanded in December 2011 to include the use of these semantics by XBRL extension modules including Formula, Table Linkbase, Versioning, and to base the meta-model on accepted industry meta-modeling technology.

What does all this mean?  Well, one thing that it means is that it validates all the work I have been doing in this direction since about 2007.  What I have come up with is summarized here, Digital Financial Reporting.

While my terminology is different, the fact that I do have a logical semantic model means that all I need to do is map my logical semantic model to this XBRL International XBRL Abstract Model.  Further, my model builds on the XBRL Abstract Model.  My model builds on the base logical model adding in the specific things necessary for the financial reporting domain; leveraging not the XBRL technical syntax, but rather the semantics of XBRL.  Said another way: basically I am in really good shape.

Further, the US GAAP Taxonomy and SEC XBRL financial reports will be distilled into the XBRL Abstract Model 2.0.  Why? Well, they have to be able to be distilled down into this model or the XBRL Abstract Model 2.0 does not work.  If the US GAAP Taxonomy and SEC XBRL filings don't fit into this model, the model will be tweaked (it is only a public working draft) until it does.

I would encourage anyone building software to both read and understand this XBRL Abstract Model 2.0 and to provide feedback during the public comment period so that the recommendation is as good as it can be.

Posted on Friday, June 15, 2012 at 07:00AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

SEC XBRL Financial Filings Reach Significant Milestone: A Readable Rendering

Back in November 2009 I gave an A+ to one SEC XBRL filer, Citigroup, for meeting a base set of criteria. By February 2010 the number which got an A+ grew to 24. By March the list grew to 92.  Then in September 2010 it grew to 4875.  If one looks at the XBRL Cloud EdgarDashboard, you don't see much red in the "E" for EFM validation errors column or even the "W" for warnings.

Great job SEC filers!  Lots of improvement.  This is not to say a lot more work is needed.

Another significant milestone has been reached: a readable rendering.

What do I mean?  Well, looking at an extreme example will make the point.  Consider the example below:

SEC XBRL filing with rendering "issues"

It would be hard for me to believe that anyone sees this example as something which should be emulated.

Why do SEC XBRL filings render like this?  Well, let me tell you who has the most readable rendering that I have seen.  There are only two criteria and I am not saying that this is the only SEC filing which meets these criteria.  What I am saying is that it is the first SEC filing which I have run across which meets the criteria.

The first criteria is that the filing must be a 10-K, meaning it has lots of rather complex stuff in it.  The second criteria is that you can look at the information in the SEC XBRL financial filing and you are not totally confused by what you see.

So who is the winner of this distinction?  Google.

What is even more interesting is that I get close to the same renderings in three different software applications created by three different entities.  First of course you have the SEC viewer which was created by the SEC.  The second is XBRL Cloud.  That viewer is freely available to use for looking at SEC filings, thus the link above. The third company is CoreFilings and their product is Magnify.  You have to either buy that software or get a trial version for 30 days to try it out.

Do you understand what this means?  One global standard, three different software vendors.  I am sure that there are more software vendors can load and render Google's filing.  But I have only used three.

And how did Google achieve this distinction?

  1. Google created many smaller pieces, rather than fewer larger pieces. Google's filing has 92 networks.  Remember that half of them are XHTML "[Text Block]"s; so I figure that there are about 40 or 50 pieces, given that the primary financial statements do not have [Text Block]s.
  2. Google modeled the information.  If you go look at that not-so-good example above, it is pretty easy to tell that whoever modeled that has no notion of a "model" in their mind and that all they did was pick a piece of the financial statement, parsed the HTML presentation into pieces, and then put some "tag" on the piece.  Google did not do that.  Google clearly thought about what they were doing, they modeled the information, and the rendering turned out pretty good as a result. Perhaps not perfect, but there is not one of those pieces which looks even remotely like the example shown above.
  3. Google matched up [Axis] and [Line Items] well. A major reason for poor renderings is mismatches between the [Axis] and the [Line Items] for reported facts. This relates to point "1" above (many smaller pieces, rather than fewer larger pieces).  Proper match ups, which Google most of the time, causes better renderings.

That is really all it takes to get a good rendering.  Don't believe me?  Take a look a the renderings of the disclosure templates I am creating. If you find one that you don't understand (clearly you need to understand the accounting) please let me know.  The disclosure templates are small pieces, but don't be fooled by that.  Add more [Axis] or add more [Line Items] and you will still have good renderings.

Bad renderings are caused by: (1) bad models and (2) bad rendering engines.  If you have a good rendering engine and a bad modeling, you will have a bad rendering.  Good rendering engines cannot fix bad modelings.

Great work Google!  I think I will go through all Google's computations and see how well they did on those.

Posted on Wednesday, June 13, 2012 at 09:02AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Don't be Road Kill in the Switch to Digital Financial Reporting

Many movie theaters are going out of business because they cannot make the switch to digital projection equipment. The Borders bookstore that I used to like to go to is now an empty, vacant building.  A couple of years ago I sent thousands of dollars worth (when new) of photography equipment to Goodwill because it was obsolete. My Denon stereo system was scrapped years ago, as were my collection of cassette tapes.  I am still wondering what to do with all my CDs which now live on my iMac within iTunes so I can get them on my iPod.

The switch away from the historical paradigm of financial reporting to the new paradigm of digital financial reporting will occur sooner and faster than you might believe.  Are you prepared?

While XBRL might be a career niche today, it may turn into a constraint if you don't have the skills you need to survive in a world of digital financial reporting.

How do you get those skills?  I summarized this in a blog post a while back.

The real question is not how to get there you need to be, it is whether to make the investment to get there.  IBM seems to be making the shift. Others are also. 

The dynamics of the innovation process can be hard to understand and even harder to predict.  Then deciding whether to make the leap one needs to consider risk.  The global consultancy firm Gartner classifies XBRL as a transformational technology.  Gartner defines transformational as something that "enables new ways of doing business across industries that will result in major shifts in industry dynamics."  Major shifts means lots of change and some winners and some losers.

Don't be road kill in the switch to digital financial reporting.

Posted on Tuesday, June 12, 2012 at 09:26AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint