Implications of XBRL on Audit firms

The growing requirement for companies to produce financial statements in the XBRL format is now beginning to impact auditing firms. Audit firms need to plan for the coming wave of additional effort required to provide assurance over XBRL documents, and need to be building the cadres of skilled individuals who will provide such support to audit teams. The phase-in periods are quite different by jurisdiction, as is the expected total additional effort.

Audit and assurance firms should be exploring the potential impact and planning exactly when and how they will build the skills and acquire the tools that they will need to provide assurance over XBRL documents produced by clients.

The potential cost of audit could have a negative impact on market acceptance of XBRL. We must be looking beyond the depth of the pockets of Megaconglomacorp, and understand the impact of XBRL audit on smaller filers and smaller (non Big-4) audit firms.

Go to Non-Sequitur to learn more about Megaconglomacorp: http://www.gocomics.com/nonsequitur/2010/07/21

XBRL is not a "new" standard and is being used around the world, primarily by regulators, to improve the quality of data collected, and to improve the quality and efficiency of analysis of that data. In some cases the information is converted to XBRL by the regulator, and in other cases the reporting companies produce the XBRL. It is company produced XBRL that will be audited.

Challenges

As with any "new" technology or process, audit firms will face challenges as they come to terms with new audit requirements. Certainly an initial challenge will be deciding if and when to develop a cadre of skilled individuals with the knowledge to be able to audit XBRL. Too early and these skills will not be required, too late and the rush will impact operational efficiency. Yet moving beyond the simple “do we / don’t we” question into a time when audit of XBRL is performed, there are three challenges that audit firms and the audit profession needs to consider.

Resources

As we know, the resource requirements of the audit process are not "smooth" through the year - there are clearly definable peaks of resource requirements, falling at quarter-ends and annual reporting events. These peaks vary from country to country depending on the distribution of financial year-ends and the amount of audit activity that gets squeezed into short periods of time.

I use the image of a wave moving toward the beach - the total resource required at any time represents the sea, and the increased time sensitive resource represent the wave. Consider how that wave approaches the shore (the mandatory reporting event) and the way the resource wave grows as it approaches the shore. At that last moment before breaking on the shore, the wave reaches its highest point - the most resources are being applied in that final short moment to ensure a final report.

XBRL reports are, in most cases today and for the coming three to six years, produced "after" the primary report is finalized, as an additional output format. This means that the audit of the XBRL (at least the "final" XBRL) report represents an additional set of highly specialized skill sets added to the top of that resource wave.

Software

Of course auditors mitigate the total resource required through the use of sophisticated software tools. Certainly in the XBRL space, tools are now available that help reduce the total incremental effort, and these tools are evolving quickly. Today however, most software is an extension to validation software and requires the user of the software to be an XBRL "expert".

Standards

Finally there is the problem of auditing standards. As yet there are no standards for the auditing of XBRL. There is guidance (from the American Institute of CPAs - AICPA) for the performance of "Agreed Upon Procedures" (AUP) examinations and reviews of XBRL documents. This assurance however remains "negative" assurance and for internal use only. The XBRL International Assurance Working Group continues to discuss issues around provision of assurance, but does not have the remit to produce an auditing standard.  It is probable that the AICPA's AUP guidance will form the base of any future standard for providing assurance over XBRL.

The lack of an international auditing standard for XBRL will not remove the need for auditors to provide some level of assurance over the XBRL being produced. Audit firms will need to consider their own thresholds of tolerance when providing assurance, and should be lobbying the IAASB and IFAC to fast-track the development of an auditing standard for XBRL documents.

Costs

While my purpose is not to suggest how Audit firms perform assurance, or to indicate the effort involved, it is worth noting that in the United States, AUP engagements for provision of assurance over XBRL documents have resulted in total auditor time of between 50 and 100 hours for the first basic "block tagged" XBRL (tagging of financial statements), and significantly higher for "detail tagged" XBRL (tagging of all financial information throughout the financial statements and notes to the financial statements). Subsequent quarterly "reviews" will take take, but should not require the full 50+ hours. Expect the total hours to quadruple for "detail tagged" XBRL.

The primary cost drivers are the time required to perform the engagements, and the software used in the engagement.  Subsequent engagements should see the total time commitment reduce, and enhancements in XBRL audit software over the coming few years should also reduce the total time required.

The Market and tolerances

This may seem simplistic, but I think it is fair to say that the average auditee will not lightly accept an additional 50 - 100 hours of audit time added simply to audit the XBRL. Those in the XBRL space that are focused only on the Fortune 1000 or FTSE 100/250 do not see this as an issue - these hours will simply be folded into the already thousands of hours and many millions of Dollars or GPB that makes up the total audit cost.

But we must look beyond the depth of the pockets of Megaconglomacorp, and try to understand the cost to the vast majority of other businesses. These are the companies, public and private, that will be paying first to create XBRL and then paying to have the XBRL audited. Therefore we must be looking for ways to reduce the incremental cost the cost of production and audit of XBRL. While process improvements and reductions in reporting time will reduce the cost of producing XBRL, the additional cost of auditing XBRL must also be reduced.

I fully expect software to audit XBRL to improve significantly over the coming couple of years, to the point where the total complexity and cost can be brought down to 'reasonable' levels. Of course, "my" reasonable and an auditee's reasonable may or may not be the same thing.

What will not change will be the need for auditors to gain a working understanding of XBRL, and the need for audit firms to have this additional expertise available.

What to audit in XBRL

Some (but only some) of the XBRL audit issues include:

• Use of extensions – if allowed, why were they created, and is there already an existing element?
• Confirmation that the information is the "same" – This covers more than simply “are the numbers the same”.
• Parentheticals – is all the information appropriately tagged, including information include within labels.
• Calculations – are all calculations appropriately constructed
• Dimensions/Tuples applied
• Label over-rides – have the taxonomy standard labels been used, or company specific labels, and do all labels match the non-XBRL documents
• Taxonomy selection – obviously the correct taxonomy must be used

The list goes on...

What is XBRL

XBRL (eXtensible Business Reporting Language) is an open standard for the interchange of business information between computer systems, by mapping information to entries in logical dictionaries (taxonomies) of business terms, thereby ensuring that the provider and recipient of the information share the commonly accepted meaning of each piece of information. XBRL also allows the creation of custom dictionary entries (extension elements and taxonomies) to allow the reporting or provision of company specific information.

In effect, XBRL allows a “wrapper” of information to be placed around any business "fact", be it a number, a date, or text. In XBRL terminology, this is called "Tagging", or to "Tag" a piece of information. That “wrapper” then ensures that the provider and recipient are referencing the same definition of the information, significantly improving the usability of information by reducing potential errors and confusion over the meaning of any individual piece of information.

XBRL gets "competitive"

In the past week both XEU (XBRL Spain), XUS (XBRL US Inc) and XBRL Japan have announced "competitions" with prize money for the winning entries. Initially I was quite uncomfortable with these competitions, as they almost seem like a great way to get some good ideas into the public domain – crowd sourcing if you will, from people without the contacts or economic ability to bring fully fledged products to market.

Maybe I'm a social Luddite, but I've always been uncomfortable with the idea of "crowd sourcing" - get bunches of people to donate their time and brain power, only to have a very few actually be able to apply the capital required to exploit those ideas.

XBRL US is offering a single $20,000 prize, while XBRL Spain is offering 5,000, and XBRL Japan is offering Y100,000 in prizes.

The best ideas will win (and will receive prizes that are of a recognition level and not product level), the second best ideas (and third, etc) will still be great ideas, and will now be available to anyone with the pockets to actually take to market. It sounds like a wonderful way to pick and choose from the best and brightest, and to then take their ideas to market.

Yet on the other than, all participants know exactly what the deal it. There's no exploitation.
Campbell Pryde of XBRL US Inc recognized the difficulty in coming to the right balance, but said that all entrants thus far were made aware that their  entries would then be in the public domain, hopefully as building blocks for a new generation of software and tools exploiting XBRL data.  He also said 

“The intent of the competition is to stimulate interest and awareness in the developer community about the opportunities available to them with XBRL data.  The more open source applications available, the more ideas generated and the more applications companies can build on.  All this leads to quicker and broader adoption among investors, analysts, and other users of corporate financial data.”

Great ideas will be given an airing. Some will make it to market, others won't.

And the individuals who present the ideas will be demonstrating their knowledge of XBRL, and demonstration that they are innovators. Best of all, they will be showing their skills and knowledge to a plethora of potential employers, to the securities industry, and to the wider XBRL community.

It has been my belief for quite some time that XBRL success requires two things; 1) a pool of XBRL data that is publicly available for use (which is now the case with SEC filings - but that was also available when the FDIC's program went live in 2006) and 2) the software to exploit that data. That software did not exist and was not developed after the FDIC program - and if it is not developed now, then the XBRL dream will suffer.

So in the final analysis - well done to both XBRL Spain, XBRL US and XBRL Japan for initiating these competitions. Soon there should be some pretty fantastic examples, open source all, of just what can be accomplished with the XBRL data that is available today.

Do you REALLY want to violate SEC Reg FD?

Violate Reg FD here

Okay, you've just finished your 10-K/10-Q. The final numbers are done, and the auditors have 'blessed' the document. Before the document is filed with the SEC, someone on your team creates an e-mail that attaches the draft 10-K/10-Q and sends it to an anonymous website that promises to let you see what the HTML version will look like. Congratulations, you've probably just breached SEC Reg FD and perhaps a host of other securities laws.

For all you or anyone knows, you've just sent your filing to a competitor, a newspaper, an analyst, a potential investor.

Exactly the same risk applies to the XBRL versions of financial statements that must now be provided by all filers. And indeed that is exactly what a website today suggests you do. A site that will allow you to upload a copy of your XBRL files and provide you with a viewer to see what your XBRL will look like once its filed with the SEC.

I tried the site today, using an XBRL document downloaded from the SEC (special thanks to the person who suggested this obvious way to test... so obvious I missed it). I wonder how many other people got to see the XBRL that I uploaded. Thank goodness it was not the XBRL of a real client or filer.

Broc Romanek, Editor of TheCorporateCounsel.net, notes: “If companies are accidentally selectively disclosing their financials, that appears problematic and they could be deemed to be violating Reg FD as well as be considered to have inadequate disclosure and internal controls.”

How innocent, and enticing - XBRL is complex, so to make sure your XBRL will be viewable on the SEC site, just upload it here and you can view it yourself.

But look closely at the site. There are no names, no contact individuals. A Who-is search comes back with no information. This should raise alarm bells to any IR professional, any CFO or any auditor. Just who will be accessing this information.

Last week, I went to their "Contact Us" page and sent a message asking who they are. I have not received an answer.

The "https" URL is a great red herring. It screams "we are a safe site, we encrypt to and from". But if you have no idea where the data is going, does it matter how safe the transmission is?

In November 2010, after the leaks of Walt Disney and NetApp finanicals, Dominic Jones of IRWebReport wrote "IR Web Report’s view is that the recent incidents are due to management at the companies failing to put in place proper disclosure controls and web publishing systems, not because of any inherent weaknesses in website technologies." (emphasis his)

We're now moving into a new world of filing, with the addition of XBRL documents as part of the filing package. These XBRL "instance" documents contain all the information included in the primary financial statements and notes to the financial statements. These documents in XBRL require the same level of protection and control as they did when they were just the financials. Prematurely disclosing the XBRL documents should be conceptually the same as releasing the HTML version of the official filing.

So now imagine finishing your 10-Q, and the XBRL version of that 10-Q. Well, the XBRL certainly does not look like the HTML that you have put so much work into - maybe you should load it into a viewer to see what it will look like, at least to confirm that the numbers and labels and elements are correct.

It would be difficult to come up with a better example of an opportunity to demonstrate poor controls over the release of financial information

Of course, I do not believe that this is a cynical attempt by a company to gain nonpublic insider information, or to get companies to accidentally violate Reg FD.

I also do not believe that any company that is providing a public service has any reason to do so from behind a mask of secrecy.

XBRL and Banking - the coming boom

I am very positive and hopeful (no - expectant) about banks using XBRL for credit analysis, and the Dutch are leading the way.

The coming deluge of filing in the US, with an additional 8000+ companies financial statements being available in XBRL, will have two very real impact in relation to banking and XBRL.

1. No smaller accounting or financial reporting software will be able to 'ignore' XBRL, and I fully expect XBRL to be a standard output format for all within the next two years.
2. There will be a steady flow of new applications to analyse the information, with some of those applications being natural applications for bank.

Where will this lead? Directly to Banks using XBRL for corporate client credit analysis and monitoring of non-public clients. It is only a matter of time, and not very much time, before banks will be requesting XBRL versions of financial statements from non-public clients - statements that today are provided in Word, Excel, PDF or even fax/printed.

The changes that this will drive include, but certainly are not limited to:

1. Better XBRL production software, either as out-sourced services, SAAS, or built-into already in use accounting and financial reporting systems.
2. A massive increase in the pool of XBRL data - although the vast majority of that data will not be publicly available.
3. Assurance over XBRL will take on even greater importance, and tools and processes to make that highly efficient will be needed - soon.
4. New taxonomies for financial reporting - in most cases "closed" taxonomies sponsored either by individual banks or by banking associations and industry groups. Why "closed"? Because extensibility is great is you are the SEC and you want anyone to report anything. If you are a bank, a million extension elements is simply unrealistic and of zero additional value to your analysis.
5. Better quality credit analysis, leading to more efficiently scaled cost of capital for non-public companies (lower for the better credit risk companies, higher for the higher risk companies).

So I am actually extremely bullish about XBRL for banking. It is not here now, but the market conditions are finally coming into place to make it almost inevitable in the next few years.