Technology adoption does follow a predictable curve, and the leap across the chasm from early adopters to mass adoption is also quite predictable. Tagged data still has an issue with demonstrating an immediate benefit, consequently inspite of huge marketing dollars spent on education and training by some of the leading vendors, adoption still waits for a carrot or a stick. It appears now that at least for public company filings in XBRL, the stick will drive the next surge. Without clear and strict and relevant guidelines by the SEC on compliance and QA, it is quite likely that we will continue to see tagged data that may be of less value than the current data sources unless vendors step up their QA efforts.
It should be noted, however that some companies like Microsoft, and some providers like Business Wire have successfully generated correct, flawless tagged data so either self correction is required by the other vendors or better compliance penalties by the SEC in allowing the miscreants to get away with shoddy work. In the end, the message to new adopters is to look very carefully at past performance of XBRL providers and do their due diligence before entering this brave new world.
Since Bowne & Co. and RR Donnelly each filed their first XBRL-related documents with the EDGAR system on April 4, 2005, (up to November 27, 2006), there were a total ninety-three VFP filings representing thirty-one companies.
A study published last month showed that of the ninety-three XBRL filings, fifty-two or almost 56% were not compliant with the latest XBRL specifications and that these incorrect filings had calculation errors. The highest number of errors found in one single filing reached 68.
R. Corey Booth, the CIO of the SEC, has said, ". the preparation of XBRL statements is still perceived to be difficult. The preparer him-or-herself needs to be comfortable with both the technological aspects and the accounting aspects of the standard. And that this kind of subject matter expertise isn't as easy to find as we would like."
The study went on to say that Edgar Online, one of the front runners in XBRL filing, has filed all six of its VFP filings inconsistently under the study assessment, and, that the number of errors is increasing as time goes on.
Here are highlights of the study findings:
EDGAR Online:
- 2005/04/25: inconsistent, 12 calculation errors.
- 2005/09/26 (for first quarter): inconsistent, 15 calculation errors.
- 2005/09/26 (for first half): inconsistent, 22 calculation errors.
- 2006/04/20: inconsistent, 32 calculation errors.
- 2006/08/16: inconsistent, 32 calculation errors.
- 2006/11/16: inconsistent, 36 calculation errors.
Three companies have filings with numbers of errors more than 50:
Xerox:
- 2006/04/11: inconsistent, 57 calculation errors.
- 2006/09/08: inconsistent, 66 calculation errors.
- 2006/11/09: inconsistent, 65 calculation errors.
RR Donnelley:
- 2006/04/25: inconsistent, 68 calculation errors.
- Second filing had the highest number of errors in all VFP filings
- 2006/08/28: inconsistent, 52 calculation errors
- 2006/11/08: inconsistent, 56 calculation errors.
2 comments:
The word "error", as used in the original study and in this article, is - at best - misleading. To quote one sage,
"[I]t is advisable to use unambiguous language so as to ensure the comprehension of the listener. "Valid according to the rules of the XBRL Specification", "Valid according to the requirements of FRTA", "Consistent in respect of calculations defined in the DTS", etc. etc. Bandying around unqualified terms such as "Valid" is an invitation to misunderstanding. At least if you describe something properly and completely the listener has a better change of knowing exactly what it is that you are saying and even if (nay, especially if) they have a different opinion of what you should be talking about, they can then drill down into what it is you are actually saying."
Mr. Basu here passes along the misstatement that the instances are not "compliant with the latest XBRL specifications". That is simply not true. They are Specification-compliant; however, they were not "Consistent in respect of calculations defined in the DTS", which is very different.
What the paper characterized as errors, and what Mr. Basu repeats here, are inconsistencies, and the XBRL community has not yet come to agree on how to deal with those inconsistencies. These inconsistencies are most often caused by:
1. Instance documents representing reports where all of the subtotals contained in the taxonomies are not found in the instances and the calculation linkbase is not modified to match, and
2. Calculation relationships in taxonomies with a Gross/Net relationships where the Net and the Contra values are provided (e.g., Accounts Receivable and Allowance for Doubtful Accounts) but not the Gross.
3. A third not quite as common but very real situation ... the original financial statements are not consistent and there are math errors there, properly represented in the instances and causing a calculation inconsistency.
A true error may be caused by:
1. Wrong numbers being put in an instance
2. Missing information
3. Incorrect signs (+/-)
But the report did not break those situations out.
The reader with an interest in XBRL is invited to communicate back to the consortium. Should there be value to the capital markets for these inconsitencies to be more fully qualified ... or simply to "prohibit" the calculation linkbase relationships so there are no "error" reports even though things are different than they should be ... it would be helpful feedback.
Well written article.
Post a Comment