Saving the SEC’s XBRL Program

Some years ago I promised myself that I would not write about XBRL again. I’m breaking that promise. eXtensible Business Reporting Language was a major conceptual breakthrough when it was first developed in 1998. But that was over 20 years ago, and XBRL has progressed little beyond a regulator-demanded user-unfriendly standard with little (voluntary) uptake by report producers, and less evidence that anyone actually consumer and uses native XBRL. There are financial analysts in university (and possibly beyond) who were not born when XBRL was developed. 

At the heart of displeasure with the SEC’s XBRL program at the core of XBRL, the “eXtensible” concept, or as the XBRL community liked to sell the concept, “tell your story, your way”. Thankfully there is a “simple” fix that will save the SEC’s XBRL program, save filers time and money, enable to (almost) pain-free expansion of the program, and increase the likelihood of uptake by consumers of financial information.

Unfortunately, the complexity of XBRL has been a problem from day one. My all-time favourite condemnation of XBRL goes all the way back to 2008 when someone said that XBRL was “using a dinosaur to crack a walnut”.

But first some background:

There are uses for XBRL and XBRL-type reporting technology, but if you are considering going down that route, beware.

The idea was simple; each piece of information in a financial statement/report could be tagged in such a way as to enable the machine to machine communication of financial and business information. The use of a common taxonomy of elements ensured that a piece of data (a “fact”) tagged would mean the same thing to any consumer of that piece of data. Anyone producing financial or business data that was to be shared would be able to ensure that the consumers of that data would know exactly what they were consuming.

Soon, the FDIC (Federal Deposit Insurance Corporation), the US banking regulator, had incorporated XBRL into the Call Report process, ensuring as early as 2004 that all reporting banks in the United States were reporting using a common taxonomy.

All “successful” XBRL implementations share one key factor; they use “closed” taxonomies and do not allow filers or providers to add extension elements.

Today, around the world, XBRL is required by various regulators are the standard for data tagging of financial statements. And in virtually all of those implementations, from the UK to Singapore to Japan and the Netherlands (to name a few), financial statements are provided to the accountant or service provider who then converts Excel into XBRL and then submits that file to the regulator. The regulator then gets to convert the XBRL back into Excel for analysis. Why? Because XBRL is complex and resource-hungry, where the equivalent benefit can be achieved from a spreadsheet.

In the US, the SEC (Securities and Exchange Commission) requires that financial statements in the 10Q, 10K and a range of other filings, be filed in HTML and in an XBRL version. The SEC is also moving to require “Inline-XBRL” filings. Unfortunately, the SEC’s XBRL program remains a burden for which there has simply not been adequate, or even partial, buy-in from the producers or the consumers of companies SEC filings.

Fundamentally the SEC’s XBRL program has been a failure.

Producers of filings to not like it, and consider the production of XBRL to be costly and time-consuming. Don’t take my word for it, read the recent article following the SEC’s roundtable on short-termism from July 2019.

In listing the bullet points from the discussion of how to improve the 10Q process, the final bullet point stated: “And then, what about XBRL? (It was noted here that many issuers find XBRL expensive and very time-consuming and highly doubt its usefulness, not to mention that the SEC has just increased the XBRL burden for companies. Another panellist quoted an issuer as describing it as the “worst part” of the process.)” (emphasis mine).

The SEC itself is a lukewarm user, and if they have ever announced that it was the XBRL that allowed them to spot a case of fraud or financial misstatement then I missed that announcement. 

Data providers such as Yahoo Finance do not bother to provide a “download XBRL” button, and if you want the data, download it in Excel. If you want to XBRL, you’ll need to go to individual filing companies’ websites and download the files from their Invest Relations page, or you will need to go into the SEC’s EDGAR system and search on the company and download the XBRL from the SEC’s site.

While iXBRL (inline-XBRL) will be a boon to consumers of XBRL, at least those reading documents through their eyes, and wondering if the XBRL-tagged facts actually match the information on the printed form, this does little or nothing to solve the main problem; the difficulty of producing the XBRL in the first place.

The “FIX”

The US GAAP Taxonomy, the “dictionary” of allowable tags for financial statements contains over 18,000 elements. Or, as the AICPA said, “The US GAAP Taxonomies contain over 15,000 elements representing commonly reported financial concepts for US GAAP financial statements”. That was a number of years ago. But really? 15,000 “commonly reported”. And this number does not include the plethora of company-specific extension elements that are created every year. 

Fundamentally, every significant implementation of XBRL for the past 15 years (as long as there really have been any implementations of XBRL) has been based on a “closed” taxonomy in which filers are not able to create company-specific extensions.

To fix the SEC’s XBRL program, they should consider the following:

1. Create a limited-set US GAAP Taxonomy. The original estimate was that at fully functioning IS GAAP taxonomy could be created with 4500 elements. While that number clearly is low, it should be possible to create a taxonomy that allows companies to report all “common” concepts in under 10,000 elements.
2. Where companies cannot find the “perfect” fit element, they should use the closest element, and/or revise their reporting to ensure that they are reporting information that is common to their industry of to US GAAP principles.
3. Encourage the development of “templates” for reporting. This will enable companies and service providers to produce XBRL as standard output, saving time and cost, especially for smaller filing companies.

Yes, this sounds simplistic, and it probably will not happen. 

Why not? Unfortunately, there are drivers for the retention of the complex system of company-specific extensions. Simply put, too many jobs are on the line. 

The FASB maintains a team whose job is the “maintain” the US GAAP taxonomy. This includes the annual release of an updated taxonomy in which new elements are added to cater for “common” company-specific extensions. Companies providing software will see their market disappear if the reporting process can be simplified. And of course, if XBRL is actually simplified, then it will become clear that almost anything that can be done with XBRL should be possible with learning engines and (gasp) Excel.  

After all, XBRL has been around for 20 years. That is 20 years of Moore’s Law improving the speed of processes, 20 years of improvements in systems and analytic capabilities, and 20 years in which IA and learning engines have, if not matured, then at least become mainstream.

It is time to fix the SEC's filing program. Fix it, or abandon XBRL.

Why Worry?

In 1985, Dire Straits released their their iconic album Brothers in Arms. While there are so many great tracks on that album, I keep finding myself singing "Why worry? There should be sunshine after rain, these things have always been the same, so why worry now". (You can listen in here)

So, sunshine after rain.

What on earth does this have to do with XBRL? 2nd quarter filings are flowing in to the SEC, including the associated XBRL versions of the filings. And what is notable about these filings? These filing represent at least the ninth XBRL filing for all SEC filing companies other than those spared by the inability of the IFRS to create a taxonomy acceptable to the SEC (although that really is a different, sadly disturbing, topic). That means that all filers have now left their period of "litigation relief".

The SEC was, of course and as always, very clear - there is no mandated requirement for XBRL to be audited. After all, Chairman Cox was famously worried that requiring audit or XBRL would spell "crib death" for the XBRL project. How right he was, yet how wrong at the same time.

After all, who would be supportive of the additional burden of having to pay for production of XBRL, and then have to pay for an audit of the XBRL. 

This left the SEC with a small problem when it came time for the Final Rule. How to require a new reporting format from filers with one of the stated purposes being to improve the quality of information provided to the investing community - while at the same time keeping to the promise to not require an audit of the XBRL?

The answer; give filers two years to learn how to get their XBRL right, then make the XBRL carry the same legal liability as the HTML filing, but without a requirement for an audit.

Here is the problem; the two year window did not give enough time for the development of a deep enough reservoir of resources that actually understand XBRL, and the development of enough skilled individuals within companies to produce XBRL that is "the same" as the HTML. Certainly not to any meaningful level of confidence.

Now CFOs should be asking themselves "Why Worry?" Our providers know XBRL, shouldn't they, even if we don't? Right? And the SEC isn't really serious about this stuff, are they?

Too many filers simply do not have the resources to have dedicated XBRL expertise in-house. And the increase in total XBRL resources required to support production of XBRL filings has grown by over 100 times in five years. So, in 2009, for every 1 "XBRL resource equivalent unit" then we now need almost 100 today. (I'm inventing a new unit of measure here - the XBRL resource equivalent unit (the XREU, but I promise to avoid using that). The XREU is a unit of measure equal to the person resources, trained in XBRL, required to produce the equivalent of a first year "block tagged" XBRL filing. So I'm assuming for simplicity that each filer required 1 unit equivalent for their first year of filing. I am also, from personal experience and wide discussion, that “detailed footnote tagging” (DFT) represents three times the first year effort, and therefore equals 3 XREUs. Finally, I am also assuming that assurance over the XBRL requires 1 XREU per filer. I know, a very blunt instrument of an estimate, but let’s go with it for a moment.)

So in 2009, we needed 500 XBRL resource equivalent units. And for estimation purposes only let's imagine that detailed tagging requires three times the effort, so in the second year, production of XBRL required the original 500 units (for the first filers) plus 1500 units for their detailed tagging requirement, plus another 1000 units for the second wave of filers.

For simplicity the following chart shows the growth in required XBRL resource equivalent units.

Oh, and just in case, I've also added the equivalent of 1 XBRL resource equivalent unit per filer for assurance starting in each filer's third year - the year they leave their litigation relief.

So why worry? Because a close look at the chart above shows a growth from 500 XBRL equivalent units in 2009 (basically, one filer's basic tagging of face financials equals 1 XBRL equivalent unit in this analysis) to over 50,000 XBRL resource equivalents this year; 2013.

Most CFOs, even if they have not see the chart above (or one like it) instinctively know that they are exposed. There simply has not been the time to train and retain the skill sets and individuals required to actually produce over 50,000 XBRL resource equivalent units. The additional small problem is that this pool of resources are needed simply to meet US SEC registrants only. There are many other XBRL implementations around the world, including India, that are competing for the few existing and established resources.

And knowing that the resources simply are not there, then it is only prudent of those CFOs to worry about their XBRL, and the liability that they now carry.

Why worry? There should be sunshine after rain. But for now, it is still raining brand new, freshly minted XBRL resources.

Put bluntly - the CFO that does not worry about their XBRL is a worry.

We are a year or two away from sunshine.

Laughing at the High Priests

The Wall Street Journal article on November 13th (Companies Grow Weary of XBRL) contains a lovely line:

"When Cyprus asked a panel of corporate controllers at the conference whether they were getting any value out of XBRL, the hotel ballroom full of corporate finance professionals erupted into laughter." 

In context, Nick Cyprus is the controller and chief accounting officer at General Motors, and this was at the FEI (Financial Executives International) conference in New York this week.

I do not know if the High Priests of the Cult of XBRL were in the room. They usually are. These were just the right venues to peddle the tired old promises that XBRL would achieve everything from faster, better internal communication, more efficient external reporting, faster closes, and a host of other benefits - most of which could be achieved simply by actually effectively implementing the already existing ERP systems. But it is long past time High Priests heard the message - no more bullshit about how XBRL will save my business! As I have said in previous posts, the only winners from XBRL so far (in the US filing implementation) are the SEC (so we are told again and again), the consultants, and Indian outsource providers.

There were options for the SEC, options that would have cost far less and that would have had a negligible impact on American public companies. These options were not taken.

When I chaired the XBRL US Steering Committee in 2005/2006, I had a meeting at the SEC discussing what it would cost to build the XBRL US GAAP taxonomy. My response, based on the detailed planning document provided to me by the XBRL US Taxonomy Working Group, said $4.5 million.

I gave that number, thinking "too high, we're dead".

The response I got was "Dan, we're the government. We really cannot solve $4 million problems. If you'd said $400 million, we might be able to do something." All tongue in cheek, of course.

Yet, how prophetic.

Because now the SEC does have a $400 million problem that they can solve. Let's hope they have heard what they need to hear from business.

As for the High Priests of the Cult of XBRL - I'm afraid they will never hear the laughter - even when it is no longer behind their backs.

Okay, I've been away a while

Yes, I took the month "off"'. I avoided most things XBRL (and even many things CSR). I chilled. And I liked it. Sure, I read the XBRL Google Alert every day, as well as the other 10 - 12 that I get. But instead of reading almost everything, there were days when the headlines were enough for me to say "na, nothing of interest here...'

And it has been a wonderful and liberating month off.

Lets face it, XBRL is interesting, and it might actually eventually amount to something. But then again, it could just as well be a slightly interesting information cul-de-sac. Sort of like the Multics operating system, or the ADA programming language. Both were hot. One because it was very good, but complex. The other because it was mandated by the US Federal Government for ALL systems.

Both turned out to be interesting cul-de-sacs. Sure, they helped show the way (from the wikipedia article: "Bell Labs pulled out of the project in 1969; some of the people who had worked on it there went on to create the Unix system. Multics development continued at MIT and General Electric."). But eventually they disappeared when technology leapfrogged. They were the leapfrogs, but somehow got left behind.

And the month off has reminded me that this will probably happen to XBRL, and sooner than we think.

There are thousands of applications under development every day for the iPod/iPad/iThingy, and thousands more being written for the cloud (on Google Apps, Yahoo, MSN, etc). And you don't even need XBRL if you want to download a public companies financial statements into Excel. There's a 'right-click' for that right in the browser. Where are the XBRL applications?

And as for XBRL either solving or avoiding the next financial crisis - well that's just a fantasy.  No data standard will in any way influence or impact what is really a crisis of confidence based on the results of years of those with the data lying to those who trusted them. XBRL would not have avoided the last crisis (or the next one) - no data standard will.

So I think I'll spend a bit more time with sunsets, and a bit more time worrying about how companies can actually make a difference. How they can be more effectively controlled and how they can manage risk more effectively.

Oh, I'm still going to be 'all over' XBRL, even if only to watch it slowly fade into irrelevance and shift farther back into that corner of the business known as "compliance". You know, the area that costs us too much money while only delivering value to someone-else somewhere-else.

And I'm still going to read the articles that tell us how one day, any day now, companies will be using XBRL to drive internal process improvements - something they have been completely unable to do using their existing ERP systems that they have paid millions to install, maintain, improve and use. "Here, just take this little pill (XBRL) and all your ERP efficiency and effectiveness ills will be cured".  It doesn't work that way. Never did, never will.

But we can go on dreaming. Hell, maybe I shouldn't go on holiday, maybe I should just keep dreaming about what XBRL might do...

But, this not being a complete dream-life, I've made myself a few commitments. I commit to:

1. continuing to provide the best service to our XBRL clients
2. ignore those those who fantasise (or lie) about what XBRL may do. They have agendas that are disconnected from the actual needs of those that will have to pay.
3. continue to raise questions - like "So when will XBRL International actually produce their own financials in XBRL?" If it is so easy and cheap, you'd think the very standards organization would use their own standard.
4. continue to wonder when, over a year later, the 'new' XII website will be announced

Rats! - I shouldn't have written that list, I think I need another holiday!

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.

I remember my very first XBRL meeting

I remember my very first XBRL meeting. It was 2003, and there were 25 - 40 people in the room. I distinctly remember all the benefits that XBRL was (is) going to bring. I remember a wonderful slide that had two time bars, one above the other - the "before XBRL" and "after XBRL" bars. Each bar was broken into segments, with the time required by each party identified - the Company (reporting), the Auditor, the Bank, the Analyst and the Regulator.

The bottom bar showed all segments shrinking, except - a very important 'except' - the Company segment. It looked something like this (reconstructed from faulty memory).

Who benefits from XBRL - 2003

XBRL will increase transparency, and will deliver massive benefits to regulators and investors. As it becomes more widely entrenched and systems are built that will exploit the power of tagged information for credit risk, the banking community will take up XBRL and use it widely. This will benefit businesses by improving access to credit at rates commensurate with their financial health and potential. As systems integrate XBRL into the 'front end', operational efficiencies will be achieved by companies. This they will happily pay for.

Unfortunately we also know that Detailed Tagging is going to impose significant cost on businesses, at little or no tangible benefit to the companies that are required to pay for their reports to be detail tagged.

An issue I've had from my very first XBRL meeting has been a Big-4/Consultant agenda of "let them spend (on our consultants), while we tell the world how good this will be for them". That has been the message from all the Big-4. At that time I was at Grant Thornton, a great firm. And a firm that was focused on the "middle market", not on the biggest companies.

I had come to that meeting almost directly from a meeting with a nice little company ($50 million turnover) and watched how they managed every penny, looking at specific metrics, and providing the reporting that they needed to. They felt (and I quietly agreed) that the Audit required of them was a pure overhead, because they could not see the benefit to them - other than access to credit. So their audit was at the lowest price they could manage, and there were no frills. In fact, there were few frills in their offices, including the President's and the CFO's offices. Oh, and the CFO had three staff, total.

I then went to the XBRL meeting, and listened to (name redacted) talk about how everyone downstream was going to get benefit - the banks, the regulators, the auditors, the investors... Everyone else was either reducing their risk, increasing their own effectiveness, or improving their return on investment. Everyone except the president of that $50million metal stamping business. And when I asked what would be the benefit to him, (name redacted) scowled and repeated the benefits to the banks, etc. I repeated my question, and that was the moment that (name redacted) and I became "friends".

I am still, 8 years later, waiting for anyone to tell me how the president of that small metal stamping business is going to actually see, in bottom line terms, the benefits from the money that they are required to spend on XBRL. Certainly there will be benefits, but not from creating XBRL for external consumption.

In fact, adding insult to injury, the same basic chart of can still be found here - XBRL - What are the Benefits. There is no date on the page. Maybe, just maybe, this is out of date and there is a new chart with benefits to the producer of the XBRL (the one who is paying).

The (minimal) tagging requirement from the SEC seems reasonable to me - to enable the SEC to regulate the markets and reduce risk. Detailed tagging, simply put, provides benefit to a few downstream while imposing the costs on the producer of the information.

So I'll be blunt - the Big-4 and the large companies that advocate Detailed Tagging are out of touch with the smaller filers. Businesses that are coming out of recession, and are happy to have survived, and are now looking to grow again. And they survived by watching every penny, taking the difficult decisions, sometimes very painful decisions. They don't waste money. If they are going to choose to spend it, they want to know what they're getting for that money. Not what someone else will get for their money, but what return they will get for their money.

I could use the word "investment" - but really, we're talking about money. Limited money.

So is anyone surprised that the $2500/year XBRL vendors are bringing in the clients? They shouldn't be surprised. The sad thing is that many of the purchasers at $2500/year are in for a nasty surprise when the discover the real level of effort on their part, and the very real danger of missing SEC deadlines for lack of resources.

XBRL is complex, and expensive - either in external costs, internal costs, or a combination. Total costs will fall, but there is probably going to be some real pain along the way.

For more information on XBRL offerings, visit us at www.raas-XBRL.com or pick up a copy of our 2011 XBRL Buyers Guide.

Don't fear the XBRL

There's a lot of fear out there - but as Blue Oyster Cult sang in the late 1970s "Don't Fear the XBRL" - or was that "Don't Fear the Reaper"?

The SEC has gone out of its way to make initial filing of XBRL as easy and risk free as possible. XBRL may be complex, and it might be an SEC mandate, but that does not mean that is needs to be complex, or that the SEC is looking to make examples of any filers. Nor does it have to cost as much as the quotes coming from some of the major financial printers / filing agents.

Let’s look closer at some of the things we're hearing:

1. XBRL is SOX all over again.

If companies do not make their plans, and are not careful about the choices they make, XBRL will be a mini-SOX. It does not need to be. It is possible to have financial statements converted to XBRL for very reasonable prices.

2. The SEC will come after me if I get it wrong.

Actually, they won't, unless you intentionally get it wrong. The SEC specifically states that companies have a two year litigation relief, and they must only demonstrate a "good faith" effort to have provide XBRL that is "the same" as their HTML filing.

3. XBRL will take 120 hours of people time.

We have seen all sorts of time estimates for XBRL. These estimates (all for "block tagging" - the first year requirement) range all the way up to 125 vendor hours plus internal time. We believe 8 - 10 hours is much more reasonable. Anything over that is, in our view, either the result of inefficient processes or software.

4. I will be liable for what's in the XBRL.

True, but refer to number 2 above - the SEC has granted a two-year window, basically with the intention of giving filers the time to get it exactly right. Of course, we wouldn't have it any other way, but with so many choices from the taxonomy, there is a good chance that some items may not be 'perfectly' tagged. The SEC cares more that the data is available than that it is 'perfect'.

5. The taxonomy is huge.

Again, sort of true. There are reports of the taxonomy having up to 40,000 elements. The truth is closer to 15,000. But don't worry, the taxonomy is structured to facilitate identification of the best element, and most tools have strong search capabilities these days.

6. The SEC is just going to defer this anyway.

Don't plan on it. I'd say more, but I really don't need to. Too much has already been said. This is not going away.

But there are a few things to worry about:

7. Year-2 Detail Tagging.

The second year tagging requirement currently defined by the SEC does result in significantly more work. Numbers of tagged items are rising by an order of magnitude, and we are hearing that total effort is increasing by 6 times or more. Hopefully the SEC will do something about this.

8. Assurance costs.

A quick word about assurance - it is optional. However, it can be expensive. We recommend that if filers want a review, they should do it themselves, or they should have an independent accountant perform basic quality assurance over the XBRL mapping selection.

Summary -

There really is little to be afraid of, if you are careful with your choices. The biggest fear is that without doing your homework, you will spend too much. After all, just how complex are your financial statements?

Assurance over XBRL: the potential cost for American business

Subtitled: A cautionary tale

Since the early days of 1999, and in the eleven years since, the accounting profession has invested hugely in XBRL, and as we all know, accounting firms are a public good, so this investment has had the purest goals of enabling greater transparency and internal company process improvements. And in that spirit, I have no doubt that they will be doing everything in their power to reduce the marginal incremental cost of assurance over XBRL to a net increase of $0 over current audit costs.

It is merely a byproduct of that altruistic concern that will result in potentially (again subject to some very questionable assumptions - see below) anywhere up to an annual $100 million in additional revenue to each of the Big-4 (although possibly "only" up to $30 million from the first wave of filers).

The cautionary message is this: unless the assurance profession finds a way to ensure that the marginal incremental cost of assurance over XBRL is $0, XBRL will be seen as simply another cost burden being placed on American business. Continuing to pile cost onto the producers of the XBRL while delivering the benefits to the users, will increase resistance and endanger businesses acceptance of this new filing requirement.

Lets be absolutely clear - a cost-benefit analysis requires that both the costs and the benefits be defined and measured, and then balanced to confirm a net benefit (and thus support for the proposition) or a net cost (which will only increase resistance).  If we do a societal cost benefit, then we can balance individual company costs against societal gains, but it still needs to be quantified.

Background

The SEC, in the XBRL mandate, provided litigation relief for the first two years of production and provision of XBRL with 10Q and 10K filings. At the end of that two year window, filers will no longer have that protection. Does this mean that there is a requirement for the XBRL to be audited? No. Does this mean that companies may be held liable for investment decisions or adverse changes in share values due to erroneous information making its way to the investing community via the XBRL? The answer to that is "the jury is out". Well, actually, since no case has been taken yet, there is still no jury, so maybe that's no the right answer.

In my most recent post, I provided a set of assumptions, and from those assumptions developed a range of potential cost to American businesses to provide XBRL to the SEC.  I did not include the cost of audit in that calculation. I'm attempting to do so here.

Assumptions

A reminder, as in my previous post, what follows are assumptions, and reader should accept or change them to fit their own views and expectations. I welcome a different set of assumptions and a different set of expected costs.

1. Virtually all of the top 1500 largest filers are audited by the Big-4, and that that those 1500 are 'evenly' distributed across the 4. (I know they are not, but for the sake of basic assumptions...)
2. Today the only assurance that can be provided over XBRL is through Agreed Upon Procedures - not an audit and not external assurance.
3. The cost of assurance over block-tagged XBRL ranges from $25,000 - $50,000, a range that reliable sources have told me is 'conservative'.
4. Assurance professionals, as part of their assurance process, need to look at each extension and confirm that there was not an equally valid existing taxonomy element that could have been used.
5. Extension elements (in first year "block tagged" XBRL) are running in the 10s, not the 100s in block tagged XBRL.
6. The second year of XBRL production brings in the requirement for block tagging, which is increasing the number of reported elements by up to a factor of 10.
7. Extensions in block tagged XBRL are running in the 100s. In one (outlier) case I counted over 700, in another (randomly selected) the number of extensions went from around 10 to over 200.
8. External assurance, for the same subject matter, generally required more work and quality assurance than AUP internal assurance.
9. Auditor risk will be significantly higher for external assurance over XBRL than for AUP assurance.
10. Auditors will have identified process improvements that will reduce a "cost per element", so to speak, or assurance.
11. The total effort to audit will be at least 10x the first year (when assurance was voluntary), due to more complex XBRL and a massive increase in extensions.
12. Total effort (big assumption, please feel free to modify) will therefore be 8x the AUP (10x the XBRL, more QA, improved processes).
13. In all cases, I'm rounding down for additional conservatism.

So, with that behind me, what costs $25,000 today will only cost $200,000 when assurance is required, or should I say, when filers and auditors no longer have litigation relief. And by the same logic, the higher end could easily reach $400,000. But if we settle on an average of $300,000 to provide external assurance over the XBRL, we then have something to extrapolate.

So lets take an average of 360 year-1 and year-2 filers per Big-4. Lets look at $300,000 each. Pretty soon we have over $100 million in additional audit revenue per in 2013. The firms themselves are gathering the information that will validate (or otherwise) these estimates right now, as the first wave of filers leaves the safety of the SEC's two year umbrella.

So some counter arguments

These are pretty wild guesses. What are some of the arguments against these figures? Again, I'll simply list these as if they were assumptions.

1. If XBRL really is built into the consolidation process, then there will be less need to actually audit the XBRL. The good news is that this may well be the case, and as such, consolidation software companies could well be selling systems implementations or upgrades purely on the cost saving of reducing the (coming) audit costs. "Spend more money with us or you will spend even more money with them".
2. The SEC might extend the litigation relief period - but I wouldn't plan on that. In fact, while the CCR did ask for that, with the re-nomination of Commissioner Aguilar, I'm pretty confident they won't get an extension.
3. My numbers could be completely wrong. Well, as with all assumptions, that's a given. The issue is not are the right or wrong, the question is "what are your estimates of the cost based on your assumptions?"
4. The assurance profession will identify mechanisms by which the cost of assurance over XBRL can be slashed.

What is happening?

For almost six years various working groups of XBRL International and the AICPA have focused on defining how assurance can be provided over XBRL. Some progress has been made. Yes some sticking points remain. In April 2009 the AICPA released Statement of Position 09-01, "Performing Agreed-Upon Procedures Engagements that Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data". To date that remains the primary guidance for assurance over XBRL.

The IAASB continues to put XBRL in the "later" basket, although I'm hearing that increased interest in being shown.  The PCAOB, official auditing standards setter these days, released a set of Q and A on XBRL in 2005, and to the best of my knowledge they have not updated it since.  

Credit should be given to the AICPA, which has been taking the lead, and with the major firms all involved with their task force on assurance over XBRL. Amy Pawlicki at the AICPA has taken on the difficult task of chairing the XBRL International Assurance Working Group, and has not been shy about pushing participants to advance the goals of the Working Group.

I also have no doubt that the major auditing firms have developed, or are developing, software that will automate the vast majority of the checks that auditors are required to perform. Robust automation can radically reduce the overall workload required to assure XBRL. The residual concern is that the firm might not see any benefit in reducing the cost.

In summary, much is happening, and hopefully guidance will be made available that will reduce the marginal cost of assurance over XBRL to a $0 incremental additional cost to filers.

A disappointment

Which leads me to a little disappointment that I have. After my previous post on putting a cost on XBRL, instead of anyone providing an alternative range of cost, the majority of responses (public) were to say that my assumptions were wrong and that I do not factor in the benefits. Or as one person put it: "An analysis that considers the costs without the benefits does not seem like it is very balanced."  My response was, and remains "An analysis that considers the benefits without the costs does not seem like it is very balanced." So while advocates of XBRL continue to say just how wonderful XBRL will be (especially if you are a very big company with a lot of money to spend), none of them seem willing to admit that there is a cost to implementation of XBRL.

Recommendations

1. The audit profession must demonstrate how it is driving down the cost of providing assurance over XBRL.

2. I have a difficult time quantifying the benefits of assurance over XBRL, but I am confident that some in the assurance community, and certainly those who have been advocates form XBRL for a decade should by now have quantified the benefits. Please share that information. But it should be quantified.

3. Those who disagree with my analysis should provide a counter analysis that documents their assumptions and the resulting calculated costs to balance against the benefits that they quantified in number 2 above.

4. If you are a filer, ask your auditor how much assurance over XBRL will cost. Demand at least a range and estimate (if you are a 2nd or 3rd year filer).

5. Send me any information you can on what it is costing you or what you have been quoted - I will not post or in any other way allow identification of you, your company or your auditor.