The first observation I would make is that the SEC's validation and acceptance of instance documents probably needs to be tightened up a bit. Arguably, the SEC should not be accepting a filing with over 95 SEC Edgar Filer Manual (EFM) validation errors. Likewise, when some of the largest filers are providing XBRL with 67% of elements being extensions, it suggests that detailed tagging might produce an awful lot of data, but precious little comparable data.
From a software or vendor perspective, there are also some interesting observations. The first, of course, is that the name of the software used to produce the XBRL may or may not relate to the actual parties that produced the XBRL. Certainly the software provider is named, but the filing agent or outsource provider (for example) is not. Still, even the information that is available is illuminating.
So before I jump in to some of what I've seen, I'd like to thank Cliff Binstock for producing and providing the XBRLCloud Report online. This is a fantastic resource for performing a simple 'health check' on the current state of XBRL filings with the SEC. On 15th March 2011, I visited the XBRLCloud report and copied it into Excel - the report currently is limited to around the 1500 most recent filings, due no doubt to the size of the downloaded information. For my purposes this is fine (although I would love to see all the data) as it roughly covers the first filing season of this year, with most of the first and second wave filers reporting.
Key findings
In terms of the results, I've picked out some specific information, and run some averages. For each of these, I deliberately don’t mention the specific company or software solution that was used to create the instance document, as I'm sure all the software vendors will be pointing out their successes (be it the most filings, the cleanest filings, the fastest or the cheapest). There is no need to point out the software vendors or filing agents (where they are the same) whose tools produced the instance documents with the most errors, warnings or inconsistencies (I call these the dirtiest, though that's probably a bit unfair), or the most extended filings.
One interesting observation is that it seems easier to get an SEC EFM Error accepted than a Warning. For example, the instance document with the most Errors (EFM) had 96, while the instance document with the most Warnings had only 8. Of course, when we look at inconsistencies, the largest had 775. Now that's impressive. I could well imagine a conversation after seeing a list of 775 inconsistencies: "But will the SEC accept it?" - "Yes" - "Then just file the damn thing and move on."
Errors (EFM)
As already mentioned, the highest number of SEC EFM errors in a filing was 96. But there were an 90 examples of instance documents with EFM errors. The good news is that means there were over 1400 instance documents with zero (0) EFM errors. Furthermore, no vendor is over-represented in the EFM errors category, with some having no EFM errors in filings created with their software. However, while some vendors had zero Errors, no vendor had zero Errors, Warnings or Inconsistencies.
Moving into Warnings and Inconsistencies, the numbers become a little more interesting, with the highest "scores" (so to speak) being 8 and 775 respectively. As mentioned above, it is remarkable that the highest number of Errors in an accepted filing is 12 times the highest number of Warnings.
Errors (GAAP Architecture)
Looking at GAAP Architecture errors, the numbers are also a little disturbing, with the highest number of errors being 382. That's a huge number of GAAP Architecture errors in one filing, and again, suggests more of a "running out of time" than an acceptance that errors are acceptable.
As with the EFM Errors to Warnings ratio, there is a similar ratio in the GAAP Architecture errors, with the highest number of Warnings being 26 in a filing. Again, there is no specific pattern across the vendors.
Extensions
The biggest issue visible to all is the percentage of extensions. 23 of the filings in the list have over 50% extensions, with the highest being 67% which translates to two out of every three data points reported and tagged in XBRL were extensions.
The entire point of an extension is to provide the capability to report information that represents a unique aspect of a company's operations or reporting. As David Blaszkowsky said to me some months ago ""Well, the number of extensions is being seen, or presented, as a bad thing. Actually, I could not disagree more. I'm quite excited about extensions. Thinking about it, extensions will reveal unique differences in substance between companies. Isn't that the whole point?" Unfortunately the level of extensions in some filings simply makes a mockery of that idea
Why so many extensions? Who knows? Could it be that the US GAAP taxonomy is inadequate for some types of organization? Could it be that it was simply faster to create a new extension for each item than to search for and use the appropriate element? Was there a desire to "be transparent while ensuring opacity"? It certainly suggest that the FASB has its job cut out updating the taxonomy with elements to enable comparability.
I do not know the answer, but "I'll tell you what I know - England Prevails". (Oops, sorry about that - 10 "attaboys" to the first person who correctly identifies the movie that is from).
But back on track; I do not know the answer, but I cannot imagine that XBRL tagged information that is two-thirds extensions actually adds any value to the analysis of an individual company, or provides any assistance in sectoral or industry analysis.
Observations
I said that I would not discuss individual vendors and their results. The averages across vendors/software are not significantly different, with some highlights and some, well, low-lights in the data. In addition, for some of the software solutions there are too few filings to make analysis and discussion meaningful. One "high error" report where there are only six filings using that software does not prove a trend, especially when the other filings using the same software all look clean.
Equally, the XBRLCloud report does not let us see what filing agent or provider produced the instance document (except of course in cases where the filing agent and the software provider are the same).
However, it is possible to see what software is not included in the Cloud Report. That said, with a "free" offer I'm confident that they will be back on the list soon. Then again, is it possible that after their first filing (and the client subsequently moving to a different provider) a "free" offer will be a good way to attract new clients? Never mind that an audience recently heard at a show-case presentation that the actual cost of the solution would be $12,000 or more...
Summary
The XBRLClould report contains a wealth of information about filings with the SEC, and it is well worth taking a wander through the results. At the same time, it is also possible to use that information selectively. After all, we can be pleased with the number of filings and the smooth progression of the mandate but the XBRLCloud Report certainly raises questions.
Regardless, my own conclusions include:
- There are still too many errors getting through (or being accepted) by the SEC's own validation.
- Extensions are out of control. Is this because companies wish to create extensions (thus reducing comparability) or because the elements do not exist. Or is there simply not enough time?
No comments:
Post a Comment