XBRL will be vital for CR reporting - but not by itself

Last night (24th March 2011) CorporateRegister.com announced the CR Reporting Awards for 2011 (results here). They also provided for a "debate" which, while I was unable to attend in person, I had the pleasure of participating in.

There were two topics:

Topic A: In future, all good CR reporting will be integrated
Topic B: XBRL will be vital for CR reporting

This second topic matched Liv Watson against Daniel Roberts (me). Liv's bio on the site reads: "Liv Watson is a Director and leads the Research and Development function at AccountAbility. She was one of the original developers of the XBRL standard, as well as a founder of the XBRL International consortium." I have had the pleasure of knowing Liv as a friend from many years. Her contributions to XBRL rank above virtually everyone else. 

Liv's (and my) full arguments are here, and comments are invited.

I thought I would also publish my arguments here. They stand alone form the general argument, and reflect my belief that we must do more to make CR (or CSR or Sustainability) reporting more effective, and that XBRL is only one way to accomplish that goal.

------------------------------------

There are more important issues to be addressed in CR reporting

Let me begin by stating that I believe that CR (Corporate Responsibility) reporting is no longer a nice-to-have – it is vital for capital markets to perform their primary function; the efficient allocation of capital for optimal return to investors. That means taking into account the true cost and impact of business, and that requires far more information than is currently reported.

The “Efficient Market” theory is well and truly dead, and in its place is recognition that more effective communication is required to approach even a facsimile of an efficient market. That additional communication needs to clearly demonstrate how each company impacts the “commons”. XBRL by itself does none of this, it is a boundary standard for the exchange and provision of data-level information that can be ‘trusted’. XBRL is important. But there are more important issues that must be addressed in CR reporting.

So if I (regretfully) disagree with the statement “XBRL will be vital for CR reporting”, then what do I consider vital?


1. Mandatory reporting
2. Against a regulator defined standard
3. That integrates financial and non-financial measures
4. That is audited
5. And finally, that is tagged, preferably in XBRL


1. Mandatory Reporting:

As long as CR reporting is optional, all reporting will be subject to the test: “Are we getting a better return for our money by producing this report than spending that money on other marketing activity?” Optional reporting ensures that forward looking businesses will report, cynical businesses will report what they want to report, while cost-sensitive businesses (which means most businesses) will provide limited or no reporting.

Mandatory reporting by all listed companies will ensure that the markets can view reported results from all companies by sector or size, or any other combination. Mandatory reporting is possible, requiring only the political will to make it so.

2. A Regulator Defined Standard:

Multi-stakeholder-created standards produce reporting requirements that are, by their very nature, the negotiated product of, well, stakeholders. This makes the standards malleable, with the reporting company invariably having the option of what to include and exclude. This makes CR reporting fundamentally a marketing issue. I call this the “Windmills and Daisies” syndrome, designed to create a good feeling while deflecting the reader from deeper issues.

Only when the regulators define the standard (with none of this “Core” and “Additional” stuff) will the standard be able to be applied equally. Ideally, such a standard would be the work of a consortium of regulators. In effect, an IASB for CR reporting.

3. Integrated Reporting:

Mike Krzus and Bob Eccles make the case for integrated reporting in their fine book “One Report”. They cite examples, and show how it is possible today to provide a more complete picture of a business for the investor community. Such reporting, in conjunction with a regulator defined standard, will ensure that what we now call “extra-financial information” or “externalities” can be and are reported alongside the range of information we currently use.

4. Audited CR reports:

When the external auditors review the financial statements, they do not ask the client what is in and what is out of scope, or what is material. They decide the scope and materiality. Until CR reports are subject to the same standard of assurance, the content and information provided will be viewed with skepticism. Such auditing standards already exist, so no additional standards development is required.

5. Report content tagged for easy consumption:

Once financial and non-financial information is being provided in a single integrated report, complying with a regulator approved standard, and containing audited information, it will only be a matter of time before providers and consumers of the information seek mechanisms to make it “easy” to consume. I want the information to be provided in XBRL. I am a huge proponent of XBRL, and chaired the XBRL US Steering Committee.

But only once organizations like the GRI (and others) stop paying lip service to XBRL, and build a real taxonomy, will the information be tagged in the XBRL standard. As a supporter of XBRL, my personal fear is that something “simple” will be used as a substitute, reducing the value of the information and benefits that can be achieved.

In summary, CR reporting requires meaningful, complete, accurate and trusted information that communicates a company’s true impact in a manner that allows rational decision making based on a holistic picture of the business. Certainly that information tagged in XBRL will be helpful to consumers of that information. Most important today is that the information is being collected and made available.

Observations from the (XBRL) Cloud - 15th March

As more XBRL is produced and provided to the SEC, what can we say about the instance documents as a whole, and with limited information, what general observations can we make?

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:

1. There are still too many errors getting through (or being accepted) by the SEC's own validation.
2. 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?

Why is XBRL so Expensive? (Cost Factors)

This might sound trite, but the primary purpose of a listed company is not to spend money on preparing reports for the regulator, no matter where they are in the world. Reporting to regulators is an overhead, and distracts resources from accomplishing the primary purpose of the business. XBRL reporting for the SEC (or any other regulator) requires additional software and people costs. From what we are seeing and hearing in the market, we think XBRL related costs are running at or above $27,000 for most per SEC registrants. Some are paying very much more. Really scary numbers, and this is for first time filing. We are hearing that detailed tagging is increasing costs by up to 6 times.

So why is XBRL so expensive?

Because too many of the software solutions are overly difficult to implement and require expensive (and rare) specialists - people who must have the costly dual skill sets that combine both XBRL knowledge and accounting/financial reporting expertise. Like SOX, expect gouging. Why? Because the software is complex, the standard is complex, and the skills are not readily available.

Of course the question "Why is XBRL so expensive" contains within it the answer to the question "Is XBRL expensive". I addressed this in my most recent article, where I point out that the perception of the cost of XBRL (in terms of it being "expensive") is an assessment that only the paying company can make, not the consultants or other external observers who stand to gain from a company's pain. The $25,000 quoted is not the highest price, and in too many cases does not include the time commitment required of companies.

Blatant commercial interjection: It does not need to be like this. Visit us.

So, accepting that spending money on reporting to regulators is an overhead, then any additional costs of such reporting can only be described as expensive.

Let’s look at the components of the cost of XBRL compliance. Basically there are two costs - People and Software.

People

People costs fundamentally are made up of cost of peoples' time (and the lost opportunity cost of that time) coupled with external time-based fees such as training costs or consultant fees. We'll use a benchmark of 60 hours for our cost estimates here. The highest estimate I've seen was 125 hours, not including internal resources. I don't know if this was scare-mongering, but it certainly scared me. But for "group 3" filers, I won't estimate more than 60 hours:

40 hours consultant time

20 hours internal time

Consultants: The SEC calculated an average of $250 per hour for consultant support for production of XBRL reports. So those 40 hours will cost $10,000.

Internal staff: If we calculate an internal cost (full on-costs, not just salary, and excluding any training) at $100 per hour, we add an additional $2,000 to the cost.

And what will these people be doing? The first thing some of the external providers and filing agents will do is try to convince you just how complex this is. Expect to be told about "arcroles" and "hypercubes", "linkbases" and "schemas". Prepare to be "baffled with bulls**t" as the old expression goes.

Then they (certainly internal people) will be learning XBRL (the first time through anyway) and the tools. They'll be mapping the financial statements to the taxonomy and identifying where extensions will be required. They'll build a company specific taxonomy, and mess around with labels, presentation orders, and worst of all, calculation linkbases. Oh, and did I mention negation? Sorry about that, negation is another one of those wonderful aspects of XBRL that I've heard referred to as "TTS", or "Terrible Technical Stuff". The SEC also has an extra wrinkle called "parentheticals" - the numbers that appear between parentheses.

Software

Now comes the software. XBRL software is expensive because the XBRL standard is complex. The full XBRL standard (and associated but required additions) exceeds 1200 pages of text. That's before the SEC's own requirements on top of the basic standard. 1200 pages provides a lot of scope for complexity, both in the software and in the potential output.

Prices for software seem to run from more than $20,000 all the way down to as low as $995 (but expect the 125+ hours, 40 of which will be learning enough XBRL to use the software, and the rest simply ensuring the they didn't miss something in the 1200+ pages, as I've seen in one offering). Some vendors are offering a software-only option (usually around $15,000) with an a-la-carte menu of consulting support - expect the times and costs mentioned above. These vendors also offer a "full service" option at around the $25,000 price level, which excludes internal costs.

One vendor offers a $5,000 price to "convert your input files" into the XBRL format. I'm waiting to hear what the actual client side effort will be to get to the point of being ready to provide files ready to be 'converted'.

Summing it all up

So there are people costs of $12,000 to start with, and an average software cost of $15,000, and you are now running at $27,000 to prepare your XBRL for the SEC.

That's why one of our "5 Questions" is "What is this really going to cost?"

Is XBRL expensive?

At a recent XBRL meeting, a participant (a representative of a large organization - not a filer) opined that he thought $25,000 was a perfectly reasonable price for a public company to pay for the production of their XBRL - after all, these are public companies and as such have the resources to pay whatever is needed to produce reports demanded by regulators. Basically - "what are these people complaining about?"

Personally, I consider an additional $25,000 to be an expensive additional cost to businesses, especially if someone else gets the benefit (but that is a different topic). Perhaps it is not so important to the Fortune 1000 companies, but unfortunately it seems easy to forget that many of the other 8000 SEC registrants are not big companies, and some actually are quite "small".

I do wonder what the reaction would be from the same person if they had to go to their superiors and say "We need to spend $25,000 on a new reporting requirement that gives us no benefit, but might help someone else, someday..."

They would inevitably be asked "How much does this reporting cost us today?"

"Well, last year we spent about $5,000 on all our SEC filings with our filing agent."

"So what you're telling me is that this year, simply to report is going to cost us 6 times as much as last year?"

Suddenly that does seem a bit expensive. Six times the cost at zero additional benefit.  Of course, there are alternative options that include pushing XBRL further back into the reporting infrastructure, but here we're talking about the specific cost of implementing a regulatory reporting requirement. After all, if your advisers have already come to you with demonstrations of how embedding XBRL deeper in internal processes would save money, then you would already have done so, and wouldn't be reading this.

Being fair, I've see prices ranging (external dollars spent, excluding any internal costs for resources) from as little as $3,000 to as much as $30,000. I do recommend that anyone considering a $3,000 solution ask our "5 Questions". Actually, I recommend everyone ask our "5 Questions" of multiple vendors, regardless of the price quoted.

Number 4 in our "5 Questions" is "How much will this really cost?" We recommend filers (and their filing agents and their advisers) ask what will be the expected total cost. After all, software alone is not the only cost, nor is time. Too frequently we're hearing pricing for software separate from consulting support. We are also hearing and reading about the additional time that could be required, both by external providers and by internal resources.

Again, here are our "5 Questions":

1. How much time will this really require?
2. How long must we budget for XBRL production after "pencils down" on our filing?
3. What is the quality of XBRL filed with the SEC using your solution?
4. How much will this really cost?
5. Do we need to learn XBRL?

Because $25,000 (excluding your internal costs) is expensive, especially when there are less expensive options that require significantly less effort on the part of the filer.

So the next time someone tells you that XBRL compliance is not expensive and that $25,000 is a reasonable price to pay, ask them how much of that they would like to contribute - after all, they will probably be one of the beneficiaries of that spend.

(To provide additional assistance, we have developed the 2011 XBRL Shoppers Guide.)
 

XBRL Usability Part 2: Checking the Extension Cord

XBRL Usability Part 2: Checking the Extension Cord

(Re-posting of Dennis Santiago's recent article - originally posted 8 Feb, 2011. Dennis is CEO of Institutional Risk Analytics. You can reach him by e-mail at dsantiago@institutionalriskanalytics.com, at 310-676-3300, or you can follow him on twitter: @DennisSantiago)

In our previous installment of IRA’s testing of U.S. XBRL filings we reported that one only needs the EDGAR Accession file to be able to properly monitor and locate SEC filings both with and without xml exhibits. We are now confident enough to cease monitoring of the SEC’s experimental XBRL feed and begin using a true production version to process filings via the standard EDGAR system.

As we await the arrival of a new wave of filings in June 2011 we thought we’d check out the library of variables that will be available. In addition to US-GAAP data elements, filers are allowed to add “extensions” to their submittals. These extensions are independently defined by each company and do not require external coordination or rationalization at this time. The way extensions are added to a filing is via the xsd file, an XBRL definitions file that starts with statements to bring in standardized taxonomies followed by the company’s independent extension set. Every SEC filing with an XBRL exhibits file set has an xsd file. Not all of them have extensions.

We instructed our computer to count up the population of 10-K, 10-Q and 20-F filings for the past year and rummage through the xsd’s. On the particular test run we did there were 36,136 SEC filings meeting our test run criteria in the Accessions tape. Of these 3,880 included XBRL exhibit attachments representing 1,488 Central Index Key (CIK) SEC Registrants. This was roughly one fifth of the population expected to start submitting in June 2011.

Of the 3,880 filings, we found that 3,039 (78%) contained extension elements. The remainder only used primary taxonomies in their construction. The number of extensions in these documents ranged from a low of one extension to a high of nine hundred twenty-two extensions in a single filing. The total number of extension elements created by the sampled filings was 183,846.

Extrapolating this to an estimated 8,100 companies submitting beginning in June 2011 (8,100/1,488 = 5.44X) says that we are looking at an annual extension library to keep track of just over one million independently created elements in addition to the US-GAAP set. Wowie!

This actually doesn’t bother us that much. We have expected for a long time now that the extensions work around for the taxonomy architects not being able to anticipate every possible data element would create this type of algal bloom in the data. It merely points out two things.

First, unless one is doing merger and acquisition work, one can probably ignore most of these extensions and do most first and second level screening analytics just using the US-GAAP subset. This replicates – if not surpasses – the detail coming out of the best of the fundamental feeds. Besides if you are doing M&A diligence, you are looking at more than just financial reporting filings anyway.

There’s always been the notion among analysts that the first true use of XBRL filings exhibits would be based on subset analytics as opposed to extreme diligence tracing of every nuance item in a filing. From what we see, the June 2011 filings population should provide the first near-census test opportunity to do aggregate and sector analysis on U.S. public companies where the data goes directly from SEC’s EDGAR system to the research department without needing to pass through an intermediary processor. And it is chain of process traceable to the government evidentiary source. We like that!

___________________________________________

Dan's Postscript: The issue of the number of extensions, coupled with versions of taxonomies, leads to questions over the costs of being able to easily consume and use the XBRL that is provided. This is an issue that the XBRL community will need to address, and doing so will help demonstrate and deliver the benefit that XBRL promises.