10 October 2010

Is XBRL like Blood?

This is the second year of the SEC's three-year phase-in of XBRL for listed companies in the US. So far one would have to say that the process has been remarkably smooth, considering that this is a new reporting technology for filers, and for the SEC. But it remains an "experiment" and sometimes experiments fail. Especially experiments that provide benefits to the downstream recipients, while imposing costs of the providers. The options are to ensure there are adequate benefits for the provider, and that provider costs are minimized.

To use a crude example, there is a chronic shortage of blood donors. Why? After all, it only hurts a little, and you get a nice cup of tea (has anyone but me noticed that "cup of tea" is almost always preceded by "a nice", as if there exists no alternative) and a really warm feeling inside that you've done the right thing. I would argue that the primary reason there is a constant shortage of blood donors is that most of the benefits accrue to the downstream recipients of the blood. Certainly the person receiving the blood is a major beneficiary. But looking further, easily the greatest beneficiaries are the for-profit hospitals and medical establishments.

So there should be little surprise that there remains an almost constant shortage of supplies of donated blood.  Provider pays, recipient benefits.

Now lets look at XBRL.

Today companies are given the opportunity (well, it was an opportunity, now it is a mandate) to spend their money and time to produce reports in the new reporting technology, only to have the benefits accrue to the downstream users of the data - the SEC and the analyst community (through free, high quality data).

Therefore, we should not be surprised to hear of directors of external financial reporting complaining that "it is too complex, with 16,000 elements and new software", not to mention either consultants or the external printers each taking their cut. And this is before any costs for assurance. I know, assurance is not required - but the SEC does say that filers must be able to demonstrate a "good faith effort" to provide clean and error-free data. So who wants to be the test case for what a "good faith effort" means in the XBRL world?

Fundamentally what is needed is cheap, easy-to-use software that removes the complexity burden, and radically reduces the cost of production of XBRL. Also needed is almost ubiquitous training to bring the reporting community up to a minimal standard of understanding. Face it, if close to 50% of all errors in filings (in the United States) are due to a negative number being entered with a leading "-" minus sign, when the element is already a debit item and therefore assumes a negative number - is that the fault of the financial reporting people, the fault of an overly complex standard, or the fault of software that does not help the user avoid that mistake?

Should a filer really need to spend additional money on a "consistency suite" to catch those errors, and to ensure that they selected the same elements as their peers? Surely that should be a public-good provided by the SEC as part of their validation checks.

So, maybe the SEC and the analyst community should be funding the XBRL validation software, to reduce or remove where possible any costs of creation of XBRL. After all, if they benefit, shouldn't they be carrying the cost of that benefit.

So again, if the "experiment" is going to be successful, three things are desperately needed:

1. Inexpensive software that intuitively helps the filer create their XBRL report, as "just another output format"
2. Ubiquitous training to build the baseline understanding required to reduce the potential for errors. Should the SEC be funding such training?
3. Validation software provided by the SEC to absolutely reduce the risk of error prone XBRL submissions.

What does this really boil down to? Reduce the cost to the provider. As long as the provider of the benefit does not receive the benefit, there will be push-back. Blood and information flow easier from provider to recipient when the costs and benefits are shared.

No comments:

Post a Comment