How to make the best of the (fill in the blank) XBRL situation

From Twitter: @mwillis001: How to make the best of the XBRL situation. PwC Webinar, May 11 2pm EST ... http://bit.ly/en84ki

Now, some people might expect me to say something like "How to make the best of the XBRL situation". After all, the "XBRL situation" could be described as an avalanche of mandate rushing downhill, about to crash over those nice little American businesses all standing around with theirs cups of hot chocolate by the ski lifts. Okay, maybe not, after all, it will be in July and August that more than 8000 companies will produce XBRL for the first time and provide it to the SEC. I just could not bring myself to use the tsunami metaphor.

Regardless, there is a significant additional reporting burden arriving, and all the wishing won't make it go away. And that means that business must get ready.

How to make the best of the (fill in the blank) XBRL situation:  So to jump directly to my suggestion, then you can read the rest is you want, is for filers to download and read the 2011 XBRL Buyer's Guide. No decisions should be made based on one single factor, but on a balance of the factors that matter most to the situation and needs of the company.

But now, back to the my stream...

I was just bemused to see one of the greatest advocates for XBRL and the first Chairman of the XBRL International Steering Committee actually promote a webinar call "How to make the best of..." anything. To me, "how to make the best" has always been one of those phrases that is linked with "of a bad situation".

I for one do not think that XBRL is a bad situation, but is it a situation of significant additional cost to business. raas-XBRL, my firm, provides inexpensive production of XBRL for SEC registrants. We're proud of what we do, how we do it, and the fact that we use state-of-the-art software that is the best and most intuitive by far. (And I've been looking at this stuff since 2003).

So what are the "situations"?

We keep hearing estimates of 80 or more hours to produce the first "block tagged" XBRL. We think this is crazy. We consider 10 hours to be plenty of time. Also, we think that 4 hours of review, for the vast majority of companies, is plenty of time.

Learning a new technology. Why? How much time did you spend learning PDF?

Implementing specialized software. Frankly, I expect virtually all accounting and reporting packages, regardless of their size, to be including XBRL as an output format within the next three to four years. And the great news with this is that only the worst laggards will have XBRL as an output format only. I also fully expect accounting and reporting software to be pushing XBRL deeper into the process, so that information is linked to appropriate company specific (or industry standard) taxonomies from the point of initial entry of the information. This will allow the information to be tracked all the way through the process.

So XBRL is going to deliver significant business process improvements. Eventually.

But today vendors are suggesting that you should not wait until your existing accounting and reporting systems cater for XBRL, but you should invest potentially tens of thousands in new systems or replacement systems, simply so that you can avoid spending a far more modest amount of money to "make the problem go away".

But of course, its not a problem, is it? It is a "situation".

So I also recommend you attend the PwC Webinar on May 11, so that you too can learn "How to make the best of the XBRL situation".

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. 

Recent XBRL myths

Over the past weeks and months even, there has been a growing pool of myths about XBRL. Some of these are, frankly, uninformed while others provide justification for the high prices that some vendors are charging. Here we present some of the fallacies that we are hearing that are being passed off as hard fact.

1. 30,000 - 40,000 or more elements in the taxonomy

More and more websites are cropping up with warnings that with 30,000 or 40,000 elements in the 2011 US-GAAP taxonomy, XBRL is a really complex problem that will require experts to help solve - even if it’s just to wade through all those elements.

Fact: the FASB says that there are around 15,000 elements, and that the 2011 release has not resulted in any meaningful increase in the total number of elements. Now, we're not suggesting that 15,000 elements is not a lot, from first hand discussions with the FASB, we have been told that the 30,000 - 40,000 number is just plain wrong.

Fact: there have been a huge number, easily over 100,000, Extensions. but extensions are not a core part of the taxonomy, and may be contributing to the confusion.

2. 80 hours or more of client-side (filer) time

First-wave filers (the top 500 companies) did take an average of over 120 hours to create their first block-tagged XBRL (57% of respondents to an AICPA/XBRL US Inc survey of first time, top 500 filers). Additionally, as recently as December 2010, one of the major filing agents told an audience that they should expect their block tagging to require 125 person hours, *plus* internal filer time and expertise.

Fact: We think this is madness because we have been producing quality XBRL that requires an order of magnitude less total time, on our side and on the client-side. Opinion: any process that requires that much time (80+ hours for block tagging of Wave-3 filers) is simply inefficient or uses inefficient software.

3. Complexity

Yes, XBRL is a complex standard but then so is PDF. If there is one common comment we keep hearing it is, "How can this be so complex, our financial statements are not that different from our peers or even from most other companies. We do nothing exotic, so why is this so difficult?"

It does not need to be, and again this is Opinion, but anyone who tells you how complex this is, is simply ensuring that you are too scared to either do it yourself (with the right software) or engage someone to make the problem go away at a fair price. Consider your options. We've heard the president of one software provider say that they will not be satisfied until XBRL (with their tool) is "as easy as Word", and from what we've seen, they are well on their way to accomplishing that goal.

4. Cost

There are plenty of vendors charging from $15,000 to over $30,000, and some that are charging as low as $995 for software. These are not myths. The myth is that to get it done right by someone else you either need to pay that those exorbitant amounts, or that if you buy the $995 software you will not need to spend a huge amount of time becoming an XBRL expert.

5. It can be really really cheap

Well, that's not really a myth either - it can be really really cheap. Remember though, you only get one grace period, and if your service provider is not resourced for the peak time, then you will use that first grace period, and be stuck worrying about your provider’s ability to actually get it done on time next time, when you have no grace period.

6. FPIs are getting a deferral

As yet, Foreign Private Issuers have NOT been given a deferral. The SEC has said that they cannot file in XBRL until there is an approved taxonomy, and the IFRS taxonomy has not yet been approved by the SEC. That is very different from a deferral. Of course there might be a deferral, but that is not what the SEC has said.

Opinion: We fully expect the IFRS Foundation to release an updated taxonomy (they have already announced that they will), and for that taxonomy to be approved by the SEC which means that FPIs will indeed have to file XBRL versions of their financial statements.

Summary of articles for 2011 first time XBRL filers

Over the past eighteen months at the Random Comments blog, we have posted a number of articles and comments that we think are relevant to the Group 3, or Year 3 filers - those that must provide XBRL to the SEC for the first time in 2011. Instead of making you search and wade through the other stuff, we thought it was time to publish a quick directory.

The following is a quick directory of articles broadly grouped by topic. Over the time it seems there have been some consistent themes, including the cost and burden of XBRL, the availability (or otherwise) of experts, background type posts and some predictions. We hope this is helpful to anyone faced with their first year of XBRL. 

1. Don't expect the SEC to delay the XBRL program for Group 3 filers 

Cost and Burden 

2. Is XBRL Expensive? (Costs range from Under $8,000 to over $30,000).

3. Why is XBRL so Expensive (Cost Factors) Mainly people time and software, and the interaction of the two.

4. So how much effort is really involved?   

5. More on estimated costs How the SEC estimated the cost of XBRL com(January 2010)   

6. Never confuse cost with quality (Quality vs Price 1, Quality vs Price 2)   

7. Detailed tagging, just how big is the burden? Answer: Ouch! 

8. Detailed Tagging explained: a descent through Dante's inferno Or, the first 4 levels of Hell? 

Availability of Experts

9.  Over 10,000 companies to create XBRL this year - expertise will be in short supply   

10. After a decade of the standard, where are the experts

11. Cost of (voluntary) assurance over XBRL today    

Options for filers

12. As published in IRWeb Report - the 2011 XBRL Buyers Guide   

13. Should you replace your entire external reporting framework to produce XBRL?   

14. 5 Questions filers should ask any prospective service provider or software vendor.  

15. Outline of first time filer options.  

Background

16. Why did the SEC mandate XBRL? Remember SOX?   

17. Observations about recent filings (March 2011)   

18. XBRL and the audit and assurance industry  How some auditors are using XBRL as a marketing tool. 

19. A conversation with David Blaszkowsky of the SEC (Part 1, Part 2)   

Predictions

20. Prediction time (detailed tagging)

21. Assurance anyone? It will happen, but first the auditors need to figure out how to.

Guest Posts 

22. Dennis Santiago of Institutional Risk Analytics (XBRL Usability - Part 1, Part 2)

23. Neal Hannon:XBRL Conventional Wisdom Might be Wrong