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.

Why did the SEC mandate XBRL?

Earlier this week I witnessed a very interesting discussion. A room of people were speculating on why the SEC had actually imposed their XBRL mandate. Was the SEC's focus on the "retail investor" just a marketing ploy? If the analysts weren't using it, had the analysts missed the point? What is the benefit for the company creating the XBRL? Who is using the data, anyway? This is all great speculation, but I think misses the point, and the what I believe to be the original driver for the SEC's program.


I am convinced that the real genesis of XBRL can be found in the financial scandals of the early 2000s (and in... hushed silence.... SOX 408).

I believe the SEC has mandated XBRL because they need the data, and that provision of that data to the investor community, while part of their mandate, is and was secondary. It is difficult enough to perform analysis of companies with semi-manual processes, no matter how much data you have. To improve efficiency, you need to import the data, and run it through your analytics before any human sees the data. The FDIC has demonstrated this with their XBRL based Call Report upgrade in 2006 (but that is a different story).

The big difference is that the SEC is not (we all hope and assume) making buy and sell decisions based on the data. they are doing what they are mandated to do: protecting the capital markets. That does not require split-second buy-sell decisions, but careful analysis, identification of outliers, and dare I say it, wondering why companies choose to not be comparable.

So getting back to the main point - the scandals resulted in that wonderful paragon of legislation: Sarbanes-Oxley, also known as the "Full Employment in the Accounting Profession Act". Of course, the world focused on the now (in)famous Section 404. And, after years of documentation, testing and (the dreaded Section 302) certifications, oh, and probably billions of dollars in auditor and consultant fees, internal controls actually are better.



But look a little further. Look at Section 408 (kindly extracted here by The University of Cincinnati College of Law: separate link).

c. Minimum Review Period. In no event shall an issuer required to file reports under section 13(a) or 15(d) of the Securities Exchange Act of 1934 be reviewed under this section less frequently than once every 3 years.

Of course, there's more. Paragraphs "a" and "b" increase the scope to include "Regular and Systematic Review" of a large number of filers. 


Basically, Section 408 requires the SEC to review all filers not less than once every 3 years. It also requires that all companies meeting a set of conditions be reviewed every year (a set of conditions that I think would probably cover close to 10% of filers).

To do that, the SEC's manual (or near manual) systems would have had a difficult time coping. Section 408 in effect is the source mandate for XBRL, a mandate on the SEC that requires a data standard that can provide the SEC with computer to computer data for 'easy' consumption by computer systems. Those systems can then perform the pre-processing and analytics, flag up the outliers, and even identify some of those that should be reviewed every year. That, I believe, is the primary original driver for the adoption of XBRL by the SEC.

Protecting the capital markets by rapid and frequent review of filers, enabled by computer to computer provision and consumption of data. Apply that argument, and the requirement for XBRL becomes self justifying. All other additional uses of XBRL become an added value to the economy and investors.

The next question is: What does this tell us about the SEC's probable next steps?

First, get use to XBRL, its not going away. Second, expect the SEC to accommodate filers enough to make provision of XBRL as 'easy' as possible. After all, if the SEC needs the data for their purposes, then if concurrent provision to the markets as critical a requirement. 


Finally, if the program is critical to SEC success (which I believe it is) and they will work to make sure filers do not attempt to derail the program, I fully expect the SEC to defer detailed tagging for "group 3" filers. The burden will prove to be heavier than the benefits that they will already be achieving simply from the consumption of the primary financial statements. But these are guesses only...