01 August 2013

Why Worry?

In 1985, Dire Straits released their their iconic album Brothers in Arms. While there are so many great tracks on that album, I keep finding myself singing "Why worry? There should be sunshine after rain, these things have always been the same, so why worry now". (You can listen in here)

So, sunshine after rain.

What on earth does this have to do with XBRL? 2nd quarter filings are flowing in to the SEC, including the associated XBRL versions of the filings. And what is notable about these filings? These filing represent at least the ninth XBRL filing for all SEC filing companies other than those spared by the inability of the IFRS to create a taxonomy acceptable to the SEC (although that really is a different, sadly disturbing, topic). That means that all filers have now left their period of "litigation relief".

The SEC was, of course and as always, very clear - there is no mandated requirement for XBRL to be audited. After all, Chairman Cox was famously worried that requiring audit or XBRL would spell "crib death" for the XBRL project. How right he was, yet how wrong at the same time.

After all, who would be supportive of the additional burden of having to pay for production of XBRL, and then have to pay for an audit of the XBRL. 

This left the SEC with a small problem when it came time for the Final Rule. How to require a new reporting format from filers with one of the stated purposes being to improve the quality of information provided to the investing community - while at the same time keeping to the promise to not require an audit of the XBRL?

The answer; give filers two years to learn how to get their XBRL right, then make the XBRL carry the same legal liability as the HTML filing, but without a requirement for an audit.

Here is the problem; the two year window did not give enough time for the development of a deep enough reservoir of resources that actually understand XBRL, and the development of enough skilled individuals within companies to produce XBRL that is "the same" as the HTML. Certainly not to any meaningful level of confidence.

Now CFOs should be asking themselves "Why Worry?" Our providers know XBRL, shouldn't they, even if we don't? Right? And the SEC isn't really serious about this stuff, are they?

Too many filers simply do not have the resources to have dedicated XBRL expertise in-house. And the increase in total XBRL resources required to support production of XBRL filings has grown by over 100 times in five years. So, in 2009, for every 1 "XBRL resource equivalent unit" then we now need almost 100 today. (I'm inventing a new unit of measure here - the XBRL resource equivalent unit (the XREU, but I promise to avoid using that). The XREU is a unit of measure equal to the person resources, trained in XBRL, required to produce the equivalent of a first year "block tagged" XBRL filing. So I'm assuming for simplicity that each filer required 1 unit equivalent for their first year of filing. I am also, from personal experience and wide discussion, that “detailed footnote tagging” (DFT) represents three times the first year effort, and therefore equals 3 XREUs. Finally, I am also assuming that assurance over the XBRL requires 1 XREU per filer. I know, a very blunt instrument of an estimate, but let’s go with it for a moment.)

So in 2009, we needed 500 XBRL resource equivalent units. And for estimation purposes only let's imagine that detailed tagging requires three times the effort, so in the second year, production of XBRL required the original 500 units (for the first filers) plus 1500 units for their detailed tagging requirement, plus another 1000 units for the second wave of filers.

For simplicity the following chart shows the growth in required XBRL resource equivalent units.

Oh, and just in case, I've also added the equivalent of 1 XBRL resource equivalent unit per filer for assurance starting in each filer's third year - the year they leave their litigation relief.

So why worry? Because a close look at the chart above shows a growth from 500 XBRL equivalent units in 2009 (basically, one filer's basic tagging of face financials equals 1 XBRL equivalent unit in this analysis) to over 50,000 XBRL resource equivalents this year; 2013.

Most CFOs, even if they have not see the chart above (or one like it) instinctively know that they are exposed. There simply has not been the time to train and retain the skill sets and individuals required to actually produce over 50,000 XBRL resource equivalent units. The additional small problem is that this pool of resources are needed simply to meet US SEC registrants only. There are many other XBRL implementations around the world, including India, that are competing for the few existing and established resources.

And knowing that the resources simply are not there, then it is only prudent of those CFOs to worry about their XBRL, and the liability that they now carry.

Why worry? There should be sunshine after rain. But for now, it is still raining brand new, freshly minted XBRL resources.

Put bluntly - the CFO that does not worry about their XBRL is a worry.

We are a year or two away from sunshine.

1 comment:

  1. SEC could always extend the elimination of the requirement indefinitely under a cost of compliance cap restraint. A vehicle for doing this would be to set a requirement that auditing will be deferred until the technology for an audit's cost matures to the point that it results in no additional cost to the filer. Audit costs are documented and it does not seem to me that hard to identify the proper datum lines even down to the company by company level of granularity.

    This is a strategic suggestion. It would force XBRL deeper into the financial reporting process and also force auditors to invest their own capital into more efficient means to conduct such audits. The auditors have always been big proponents of XBRL so it makes sense they should be even bigger proponents of creating the technology conversions within their space to help create transparency efficiently.

    Ultimately, the SEC's job is to create the environment to make that happen without negatively impacting industry or markets. Pushing the investment cost out of industry or taxpayers seems the strategic course of action.

    The two-year learning curve then start paying one's auditor expanded fees to assure compliance was and remains a naïve idea. It's a private tax on doing business and bad public policy in a process proving far more complex than the rosy pictures painted of it when it was conceived. We should instead be looking at this with a larger eye to maturing all of the infrastructure technology. Many laggards to extracting economic efficiencies remain to be remedied. I believe they can be if the process remains focused on the prize of a more friction free form of market transparency.

    Dennis Santiago