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.