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 - the One True Standard?

Summary

XBRL (eXtensible Business Reporting Language) is the One True Standard for business reporting; or is it? It is long past time for the XBRL community to be considering what are the situations where XBRL will make a qualitative difference in business reporting, and stop declaring that every reporting problem can be solved if only it was XBRL’ized.

Two hypotheses:

For sake of argument lets start with two potential hypotheses:

1. XBRL is the standard for business reporting from creation of any individual concept of business information through to the reporting and consumption of that individual or aggregated piece or pieces of business information - that XBRL satisfies and is the most effective standard for all points along business reporting supply chain.
2. XBRL is a specialized standard that can and should be used for specific applications and situations where the use of taxonomies and the complexity of XBRL will solve business reporting issues.

Unfortunately sometimes questioning the first statement is not welcome. Yet accepting it leads to some pretty interesting ideas of what XBRL can do or where it should applied.

The first hypotheses is difficult to support in a world where software vendors, accounting firms, individual companies and standards setters have yet to fully embrace and build the standard into their core products and services. After all, belief in the efficiency of markets would suggest that something as obviously beneficial as XBRL should have been fully embraced and implemented by markets years ago. Yet we still require the support of regulators to create demand and products.

In every case where XBRL has been voluntary, where companies have had to make an investment or expenditure decision, participation rates have been, well, unimpressive. This does not in any way disprove the value of XBRL, but it does indicate that in its first decade, the value proposition for individual companies required to make an expenditure decision has been inadequate to propel XBRL into ubiquity.

And companies will not "just realize the benefits and implement XBRL", which has been said to me a number of times. People and companies do not work that way. If they did, "we would all just realize [...fill in the blank...]" and we would actually have World Peace.

Does this mean then that XBRL is not an effective standard for efficient and effective business communication? Absolutely not. From my perspective it simply demonstrates that XBRL is not a panacea, and that we need as a community to be supporting the most effective use-cases, and promoting the value proposition to investors and decision-makers associated with those use-cases.

Taxonomies are Very Expensive:

We must also remember that every implementation of XBRL will require a taxonomy, and taxonomies are not cheap. When I asked the XBRL US Domain Working Group in 2006 to tell the Steering Committee how much was needed to develop the US GAAP taxonomy, I was told $3 million. I asked for a justification of that, saying “I can spend $3 million, but what would it be spent on?” The Domain Working Group came back with a plan, and I took that plan to Washington. I said, “Okay, realistically we might need more like $4.5 million”.

In the end, the numbers that I have heard for the actual cost of the US GAAP Taxonomy range between $12 and $18 million. That is 4 to 6 times the Domain Working Group’s estimate, and these were the taxonomy development experts. Even the higher number ($4.5 million) was low by 3 to 5 times.

The costs of the NTP (Netherlands Taxonomy Project) are not public, but also probably significant exceed common assumptions. It certainly took longer than expected.

The FDIC, one of the most successful XBRL projects to date, imposed a one-year postponement on their go-live date to ensure everything had been adequately tested.

So every time someone suggests that “this is a great application for XBRL”, consider the cost and time, and ask them who will fund the taxonomy development.

Some examples of XBRL for Everything:

Over the years there have been some interesting suggested use-cases for XBRL. I think my favorite was from earlier this year, when it was suggested that XBRL tagging of information in containers could be used to help thwart Somali pirates. If you take a look at this site (http://www.marinetraffic.com/ais/), you'll see where a huge number of ships are at any moment in time. Notably missing is any information from the Arabian Sea and Indian Ocean. My guess is that ships passing through this area do not want their location known, and they certainly do not want to broadcast their cargo to pirates or land-based handlers of the pirates.

Another is the idea, long held and promoted, that XBRL can be used to at or near the transaction level. Of course, this potential use-case is strongly defended in the XBRL community, because to fail to support this use-case would be a de-facto acknowledgement that XBRL is not the right answer to every question. When you are a hammer, everything looks like a nail. Now, I know that saying this will result either in angry responses, or pouting grumpiness from a few proponents of the concept of XBRL-GL. Get over it. XBRL as an international organization has paid lip-service to XBRL-GL for a decade, yet not a single ERP vendor of any market size has indicated any intention to implement (if any have, the XBRL world certainly is keeping quiet about it). If any smaller ERP vendor has indicated such an intent, we as a community have not made enough noise about that.

Today, to accomplish the dream of using XBRL-GL for internal (and external) audit analytics, the user must first convert the data into XBRL- GL, or import into an analytic tool that supports XBRL-GL. How much easier to simply import the data based on the file formats provided by IT or by the client.

So the alternatives are?

XBRL proves itself most valuable as a boundary standard, where multiple reporting entities need to provide information to a common consumer or consumers of that information.

The FDIC provides a great example XBRL as an optimal standard for data collection. The FDIC collects quarterly "Call Reports" from approximately 8000 (and falling) banks in the United States. In October 2005 the FDIC went live with their XBRL enabled CDR (Central Data Repository) system. The software vendors who provide the front end software used by banks to create "Call Reports" were required to build the FDIC's taxonomy into their applications, and to use the XBRL to pre-validate the information provided by the banks.

The FDIC was able to use this improved process to dramatically reduce the numbers of errors, and to increase the numbers of banks per FDIC analyst. The FDIC has gained significant efficiency benefits from their XBRL implementation. In this case, XBRL is being used very specifically to enable a many-to-one boundary reporting process and content improvement.

The FDIC provides access to the collected information in three formats, each of which contains the same data.  Downstream consumers of the information may take XBRL, SDF (Structured Data Format - basically a CSV/flat file) or human readable PDF files from the FDIC.

IRA (Institutional Risk Analytics) is a user of FDIC data. IRA performs analysis of banks and runs its own "stress tests", and provides a score for each bank, along with comprehensive analysis driven by their models. IRAs banking data is used by a number of significant entities to analyse bank performance, and by a very large number of individuals who purchase IRAs reports on their individual banks.

Here's the rub - IRA does not use the FDIC's XBRL feed. I talked with Dennis Santiago, CEO of IRA, about his data choices. He sad to me "Dan, why would I make a choice to spend more programmer time and company money on a complex standard when I can get the data as a flat file and directly import and use that data. It does not make economic sense for me to use the XBRL. I know that data in the flat file will be as clean as the XBRL; it comes from the same source."

"We tried taking the XBRL, but we just had to spend too much effort stripping it back to flat files so that we could run computations and analysis against the data. We were already, and still are taking flat files from other data providers. Taking the flat files from a trusted entity dramatically speeds up our processing, reduces our storage, and has zero negative impact on the quality of our product. If anything, attempting to remain current with an ever evolving taxonomy imposes simply too high a price on our business."

Recommendations:

XBRL is a standard, it is not a hammer. We need to stop looking at every situation as a nail.

• There are plenty of valid examples of reporting situations for which XBRL is the perfect answer. And while some might not be terribly happy about it, the iXBRL requirement from HMRC is probably one of those examples. XII and the jurisdictions should be looking for such projects and programs.
• The SEC should consider following the FDIC's example, and provide multiple formats to consumers of the XBRL data is provided by filers. Is there a more "trusted" or "trustable" entity then the SEC for data? In which case, a "flat file" from the SEC in a defined format should work wonders for a large number of users of that information, and like IRA, they may be able to make quicker, more efficient use of that data available from the SEC.
• XII should, through its working groups, develop a model for the effective estimation of the true costs and time required to develop a taxonomy that can then be used as input for projects considering an XBRL solution.