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.