Putting a price on XBRL for American Business

In 2008 the SEC mandated the provision of registrants' financial statements in the XBRL format, with phase-in being over a three year period. While many of us were frustrated by the delayed phase-in, in retrospect this was probably a very wise decision by the SEC. The phase-in has provided the window for software and processes to improve, and for there to be a body of experience to give us all a good idea of what is about to happen.


Now that we are entering the third year, and the true cost and impact is beginning to be seen and felt. It is difficult to place any truly reliable figure on the total cost to American business, but a range (albeit a very wide range) is certainly possible.


Before I go any further, full disclosure, raas-XBRL (www.raas-XBRL.com) is a service provider delivering inexpensive XBRL production services, so if I sound like a vendor, there's a reason. I am also a huge advocate for XBRL as a reporting standard. I am not an advocate for detailed tagging for the phase-3, or smaller, filers. I think that is a waste of money and time.


So what are some of the key things we learned so far?

• The SEC was not far off in their estimates of time requirements, at least for the very largest filers.
• The SEC was not far off in their cost estimates for first time filers, at least for the very largest.
• Detailed tagging is a nightmare, the value of which has yet to be demonstrated.
• It is still possible to be "opaque" while using XBRL to demonstrate just how "transparent" you are. Introduce a new system, find a new way around it.
• This is going to cost US business a lot more than anyone imagined.
• So far, the only visible beneficiaries of detailed tagging are the consultants.

It is usually around this time that I start getting e-mails from XBRL advocates asking me how, as a prior Chairman of the XBRL US Steering Committee, can I say these nasty things about XBRL. I say them because they are true.


What are my assumptions?


Lets take a minute to estimate how much XBRL is going to cost American business. To do that we need to start with some assumptions:

1. There are 1500 phase-1 and phase-2 filers, and approximately 8500 phase-3 filers, for a total of approximately 10,000 filers.
2. The most common estimates in the market are an average of 60 hours for first time filers. The phase-1 filers averaged over 120 hours. Phase-3 filers hopefully will average to the downside of the 60, but for the "highest" cost estimate I use the 80 hours for the first 10Q, and the same for the first 10K, with the other 10Qs requiring half as much time. I use the 60 hours as the "lowest" cost estimate time requirement.
3. For the 1500 phase-1 and phase-2 filers, I have estimated no change in total effort for out-years. This is because detailed tagging requires the deconstruction of footnotes each time, and is not a one-time large effort followed by a lower roll-forward effort such (as it is with block tagging).
4. For detailed tagging, although lower than the estimates that have heard (and believe, of a six-times the first year effort) I'm using a four-times cost, hoping somehow that efficiencies will result in lower total costs.
5. The SEC based it's cost-of-XBRL estimates on a $250/hr rate. I will provide a low - high range of $150 - $250 to cater for a mix of consultant and internal resources. So for the "highest" total cost estimates I use the $250/hr. For the "lowest" total cost estimates, I'm using an average $150/hr, but that does assume use of internal resources only.
6. I have also estimated an annual software license cost of $15,000 per filer.This may or may not be applicable for many small filers this is not the case, and certainly with raas-XBRL, there is no additional software license.

Before getting to the costs, I accept that these are assumptions, and as such, each is open to interpretation and modification based on the readers own assumptions, experience or knowledge. Proponents of XBRL will want to use the lowest estimates possible, to provide an ROI that is clearly positive, or at minimum a lower cost burden. The only problem is that vague notions of "transparency" when there are, today, so few users of the information, makes it difficult to demonstrate the ROI on XBRL.


I am confident that there is a good ROI for tagged financial statements, but I cannot see any decent ROI for the costs of detailed tagging for smaller filers. I believe the SEC should defer that requirement immediately, and keep that deferment in place until systems have been upgraded to be able to deliver the ROI.


The payback will come as production of XBRL becomes the norm in all consolidation software regardless of the size of package, and we can see the benefits of faster closes, cleaner numbers (internal to companies), greater ease of analysis within companies, and public domain or free software applications that enable the retail investor to actually exploit XBRL. That is when detailed tagging of all filers 10Ks and 10Qs should happen. But until then, detailed tagging of phase-3 filers is simply a massive and unjustified burden.


Lets ballpark the cost


So lets look at what these assumptions will mean for the total cost to American business of implementing the SEC's XBRL mandate.


For 2011 - 2012 (a full year of filings) the lowest total cost is almost $550 million, while the top of the range is almost $1.1 billion. Yes, in the coming year, American business is going to shell out between $550,000,000 and $1,100,000,000 in fees and additional time costs to provide basic XBRL to the SEC (and detailed tagged filing for the 1500 largest filers). That is a wide range, but is based on the fairly wide ranges that the assumptions include.


In 2012 - 2013, the SEC requires an additional 8500 companies to provide detailed tagging. That is going to result in a massive increase in the cost burden of being public. If access to capital is a primary reason for going or staying public, then the increased cost burden of XBRL detailed tagging can only reduce the value of the access to public capital. If the cost burden is too high, I think we will see a number of companies delist.


Based on the assumptions above, the total cost to American business in 2012 - 2013, for the provision of XBRL to the SEC, could reach $2,600,000,000.


These cost estimates do not include any additional cost for assurance over the XBRL. The SEC provides two years of litigation relief for the XBRL component of their filing. That two year window expires this year for the top 500, and for the next 1000 it expires next year. Presumably that means that these companies will need to have assurance over their XBRL. Current ranges for non-detail tagged "Agreed Upon Procedures" engagements are running anywhere from $25,000 to $50,000 per, with anecdotal evidence that the base price in moving upward pretty quickly. I fully expect that number to increase dramatically for detail tagged XBRL. Certainly that may be chump-change to a top 500 companies already paying millions for their audit. Yet this is an additional cost directly attributable to XBRL.


Simply put, in the 2012 - 2013 year, the group-3 filers, roughly 8500 US companies, will shoulder an additional $1.5 billion in costs to be public. That comes to an average of $180,000 per filer. Now lets imagine that my numbers are wrong, Complete wrong. 100% wrong. That still means an additional $90,000 burden per US public company.


Recommendation


The ROI on XBRL needs to be demonstrated, and soon.  I also cannot recommend strongly enough that the SEC, XBRL US Inc, XBRL International and the major proponents of XBRL work to develop and communicate the ROI on XBRL, a return on Investment to the filers, that significantly exceeds the coming upsurge in costs.

Looking back, looking forward - the SEC's XBRL program

(This was originally posted on the Insitutional Risk Analytics weekly newsletter by Christopher Whelan on 12 April 2011.) 

The US Department of Homeland Security now requires all airlines to provide a list of all US bound passengers before the airplane takes off from its originating airport. Why? Because waiting until the plane arrives to screen for potential terrorists or threats is wasteful. The information upon arrival may be accurate and complete, but it is no longer timely. 

Financial reporting to the markets is much the same, with audited annual reports and quarterly reports being provided to the SEC (and through them to the investor community) - in effect after the plane has landed. By the time the information is provided to the SEC, it may be accurate and complete, but it is no longer timely. The immediate buy-sell-hold recommendations and actions have already taken place at the time of the earnings release, and sometime before. In fact it is difficult to find anyone that actually looks at a 10-K in detail. 

In 2008 the SEC proposed a rule requiring registrants to provide XBRL (eXtensible Business Reporting Language) versions of their annual and quarterly reports (10K and 10Q) and for foreign filers to provide XBRL versions of their 20-F or 40-F filings. In 2009 the final rule was passed (33-9002) ( http://www.sec.gov/rules/final/2009/33-9002.pdf ) that created a three-year phase-in based on market capitalization and filing status of each registrant. 

This new reporting requirement was sold by the SEC as a step forward for the investors, by reducing the effort required to consume information (no more parsing of HTML or text documents) and improving quality of information reported (by removing manual re-keying errors). After all, if information can be consumed at the data element level, with a 'tag' telling the consuming computer what that piece of data is, then the entire process becomes quicker, cheaper and more accurate. 

The dream is great, the reality is additional reporting burden and cost for little visible benefit. And this is where the SEC can and should be focusing its efforts - demonstrate and communicating the benefits of XBRL, and push for greater adoption earlier in the reporting process. Because "Interactive Data" as the SEC calls XBRL, can deliver real time and cost saving, companies should be looking for ways to exploit the additional reporting power that XBRL provides, and the SEC should be fine tuning their program. 

A Short History

To find the origins of the SEC's XBRL program we need to go back to the grim days after Enron and Worldcom and the introduction of the "Full Employment in the Accounting, Auditing and Consulting Professions Act", also known as Sarbanes-Oxley (SOX). Numbers - 302 and 404 - became the newest form of torture out of Washington. CEO/CFO certifications of the effectiveness of Internal Controls ensured that no matter the economy, the auditors (and consultants) would be busy, for at least a few years through implementation and the first couple of years of operations. 

But buried in SOX was another number - Section 408 - which requires the SEC to review all filers not less than one every three years, and many filers every year. The highly manual (all right, manual takes on a new meaning when it means copying and pasting data from documents into spreadsheets, but none the less, by today's standards that is manual) processes at the SEC meant that these review requirements were simply unachievable. Something was needed, and the idea of tagged data, directly consumable by systems to automatically populate analytic engines looked, and still looks like just the answer to this problem. 

As an aside, when I asked a senior SEC official what they would say if Congress asked them if they were complying with section 408, he answered "Dan, we would look them in the eyes and say 'Yes, of course we are complying'." Then he smiled. 

Of course, the SEC didn't need SOX 408 to know that they needed to do something. They wanted to find the next Enron or Worldcom before a whistleblower or counterparty discovered it for them, the hard way. They knew they needed to do something, and the forward looking leadership began to press for improving the use of the information they already receive, or changing if necessary the format of the information received.

As SEC Chairman Christopher Cox can into office, with budget constraints and a system that was moving too slowly, he found an existing program in place exploring the concept of "tagged" data. Conrad Hewitt was an early supporter of the concept, and Jeff Naumann had already been brought over from the AICPA to explore the concept and if possible, provide a set of recommendations on how to move forward. 

At the same time, Jon Wisnieski at the FDIC (in conjunction with the FFIEC and OCC) was developing the new CDR project to upgrade the Call Report process. This project pushed XBRL out into the Call Report production software used, at that time, by 8200 banks across the United States for their quarterly reporting. 

The XBRL component of the CDR project went live in late 2005 and saw immediate benefits in terms of the quality of information reported to the FDIC, and dramatically reduced the overheads at the FDIC for analysis of banks. Reporting times dropped, data quality jumped almost overnight, with the number of banks that received queries from the FDIC each quarter dropping from around 35% to 5%. 

The same information, or a subset of that information, was then made available to the investor community through feeds from the FDIC, in one of three data formats, two compact legacy formats as well as the full XBRL document. IRA uses those feeds from the FDIC (but not in the XBRL format) to populate their database and feed their bank analytics and ratings. The key here is that the fact of XBRL in gathering, characterizing and validating the bank reports enables a multiplicity of data output choices for consumers.

And the SEC could only have been watching the FDIC with envy. 

Mandate

So in the heady days after the successful FDIC implementation, Barry Melancon at the AICPA received a call from Chairman Cox asking for a letter outlining the steps the SEC could and should take to implement an XBRL program. 

The timing could not have been better, as on the day of the call, an internal meeting at the AICPA took place in which one of the discussion items (informal of course) was when and how to wind up the AICPA's direct involvement in XBRL and when to sack the AICPA's Director of XBRL. It does not take much to imagine a possible change in tone, from "how do we reduce this overhead" to "how do we maintain control over the XBRL movement". 

As Chairman of the XBRL US Steering Committee at the time, the change was easy to see. One week the question from the AICPA was "can we spin off XBRL in 6 to 9 months?" Soon that had morphed into "we think it might take a couple of years to spin off XBRL into an independent entity." So a letter was written to Chairman Cox outlining the steps that the SEC could take to position itself to implement XBRL. 

The first and most important step was completion of the US GAAP taxonomy, which at the time was being built by dedicated volunteers, and simply was not ready. As Liv Watson of EDGAR Online said, an "Industrial Strength Taxonomy" was required. 

And so it was. 

In September 2006 Chairman Cox again called Melancon and this time asked how soon an independent XBRL entity could be established to be the contractor to build that industrial strength taxonomy, and could that new entity provide a proposal to the SEC for the development of the taxonomy. 

I've left out a number of steps that took place in between the letter and the call, including a meeting at the SEC in which I was asked how much the taxonomy would cost. My answer then was that I had been told by the Taxonomy Working Group that it would cost $4.5 million. The answer I got was "That's too bad, if it was a hundred million it would be easier to get appropriated than $5 million - that's just the way Washington works." 

None the less, as part of an EDGAR system upgrade program, the SEC budgeted $5.5 million for the XBRL US GAAP taxonomy, with the contract to be fulfilled by the newly created XBRL US Inc. 

With the coming change in administration at the White House, or at least an assumption of a coming change, it was clear that if Chairman Cox was going to get the credit for modernizing the reporting environment, an XBRL proposed rule would be needed, and a final rule voted on by the Commission by late 2008. 

The clock was ticking. 

At the same time, the Pozen Committee, while supporting the introduction of XBRL, recommended a phased in approach. The Committee's concerns turned out to be spot-on. Was there adequate software available in the market to use pure XBRL documents? Were there an adequate pool of resources that understood XBRL file creation? Most important, would the cost to filers be comensurate with the benefits and thus acceptable? But the ghost of SOX haunted the program.

In 2008, the proposed rule was issued and subsequently voted on to become the final rule, with it's three year phase-in. In 2009 the first XBRL instance documents began to arrive at the SEC. Giving the SEC credit, the estimated cost of implementation per company for first year (non-detailed tagged data) was up to $80,000. A review after the first year found the experiences of companies to be very close to that level of cost. The SEC had no idea what the cost of detailed tagging would be. In the two years since the first companies provided XBRL, costs have come down, the software has become much better, but there remains a chronic shortage of skilled XBRL specialists. 

Who benefits?

So now the largest 1500 public companies companies across America are producing and providing XBRL versions of their financial statements to the SEC. In addition, some companies are using XBRL as the opportunity to improve their internal reporting processes, pushing XBRL farther back into their reporting systems. United Technologies ("UTX") is a good example, having used XBRL as the catalyst to improve their external reporting processes, saving over 800 person hours per quarter (before the detailed tagging requirement, but that is a different issue). 

The other 8700 companies (the number estimated by the SEC in the "final rule") will be providing XBRL for the first time with their second quarter 2011 filings - their 10Qs due on August 15th. Foreign filers filing in IFRS will be providing their 20-F or 40-F filings in XBRL starting with their 2011 annual reports, provided the SEC approves the IFRS taxonomy. 

So other than those companies using XBRL to re-engineer their external reporting process, the primary beneficiary today is the SEC. As mentioned in the introduction, the investor community has yet to demonstrate significant interest (other than pockets here and there) in XBRL, simply because the information while complete and accurate, is not timely. It is timely for the SEC, as their analysis is based on the audited and reviewed financial statements, not on the earnings release. Of note, a separate mandate requires Mutual Funds to provide the risk and return summary in XBRL, beginning January 2011. These filing are already arriving at the SEC. 

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?"