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.

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.

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.

Guest Post: Using XBRL for Solvency II reporting

XBRL is a global standard, and while Random Comments tends to focus on the US and the SEC Mandate, it is important to look well beyond, and see the range of other applications and projects that will leverage the power of XBRL. When we survey the landscape of business reporting, Insurance is clearly an area of significant information exchange that would benefit from the unique strengths of XBRL for business reporting and information interchange.

Gideon Benari is the editor of Solvency II Wire [www.solvencyiiwire.com], a website dedicated to news and insights on Solvency II, the European insurance directive which is due to come into effect on 1 January 2013. He recently wrote an article posted on the XBRLBlog. Here he provides us a summary (with link to the full article). 

Using XBRL for Solvency II reporting

Solvency II, the new regulation for the European insurance industry, will use XBRL as its reporting standard. Solvency II is a risk-based regulation that will affect capital adequacy requirements, governance and reporting standards across Europe.

The eXtensible Business Reporting Language format, essentially a sophisticated form of text mark up, facilitates the transfer of data between financial organisations in a standardised way. This will allow regulators to make like-for-like comparisons of data from insurers across Europe.

One reason XBRL is suited for Solvency II reporting is that the taxonomies can be extended to local level. According to a study published in the Journal of Financial Regulation and Compliance (2010)* examining the use of XBRL for Solvency II, “Once a taxonomy has been created at the European level, extensions can be added to cover the particular features of national regulatory frameworks, thus ensuring the homogeneity of the system of information while giving it the flexibility that the framework requires.”

Solvency II is due to be implemented in January 2013. Currently the European Insurance and Occupational Pensions Authority (EIOPA) is working out the finer details of the regulation.

Commenting on EIOPA’s decision to use XBRL, Anthony Fragnito, CPA, CEO of XBRL International, said, "The EIOPA mandate for XBRL in the pension and insurance sector is a critical step toward the transparency and process improvement benefits of XBRL to insurance and risk management, and expands the XBRL footprint across the financial services and capital markets sectors."

The full version of the article “XBsRoLvency II: Say it with XBRL” can be found on the XBRL Magazine Blog. Further details on Solvency II and XBRL can be found at Solvency II Wire.

References

*    Enrique Bonsón, Virginia Cortijo, Tomas Escobar, Francisco Flores, Sergio Monreal, (2010) “Solvency II and XBRL: new rules and technologies in insurance supervision”, Journal of Financial Regulation and Compliance, Vol. 18 Iss: 2, pp.144 – 157.

SEC's askOID - 2 Thumbs Up

When the SEC established the Office of Interactive Data (their way of creating a completely misleading name for XBRL) they also put together a team of people to answer questions about XBRL issues. In the time since, the askOID@sec.gov e-mail address has received (I had hoped to put a range in here, but they told me they do not provide that information - but I'd guess hundreds, maybe thousands) of  e-mails from a wide range of individuals and companies from around the world.

I have, on more than one occasion, when baffled or simply wanting to ensure I have exactly the right answer, sent e-mails to askOID@sec.gov. The responsiveness has always impressed me. In addition to a very rapid response, the information has always been precise. Sometime too much so for me, and if I have had follow-up questions, in almost all cases either the answer arrived (again, quickly) or the offer was made to call we and walk me through the question and answer.

Sometimes the answer has simply been a pointer to a paragraph in the rule, other times to other material on the SEC's website. On the occasions when we spoke, it was invariably to clarify my poorly constructed question(s), and always resulted in the clarification that I needed.

With an additional 8000+ filers coming on stream this summer, I expect the e-mail stream is already heating up. Hopefully they will be able to maintain the same level of support that they have to date.

The SEC has also recently established an online form for questions, located at: http://www.sec.gov/cgi-bin/contact_risk_fin/. The online form does provide a structured environment for entering questions, which should help OID process the requests for information. They also provide a phone number and new e-mail address for technical questions. "For technical support or questions on the Interactive Data Chapter 6 of the EDGAR Filer Manual, please call (202) 551-8900 option 3 during normal operation hours (9 AM to 5:30 PM EST) or email webtech@SEC.gov."

Of course, there remains at least one "oxygen thief" at the SEC and dare I say it, within their Interactive Data program, but the folks that answer the askOID@sec.gov are certainly not in that category.

So two thumbs up to the SEC Office of Interactive Data and the people receiving and responding to the askOID@sec.gov e-mails.

XBRL: Meeting the Needs of the Financial Analyst

Today we have a guest post from one of the finest voices in the world of XBRL. Bob Schneider is a San Francisco-based business writer. He was formerly editor of Data Interactive, the Hitachi XBRL blog. The views expressed are his alone, as is the style, making reading Bob's views an ongoing pleasure.

XBRL: Meeting the Needs of the Financial Analyst

I’ve just finished reading The Leopard by Giuseppe di Lampedusa, a superb novel  (made into a wonderful Burt Lancaster movie) about a Sicilian aristocrat at the time of the Risorgimento. Written in Italian about events remote both in time and place, there must surely have been numerous words and passages that were extraordinarily difficult to render in English. Yet the book’s translator, Archibald Colquhoun, rarely succumbs to the temptation to merely italicize the original Italian, leaving the reader to decipher these unwanted “extensions” to his personal dictionary. No doubt there are imprecisions, but the prose remains smooth and graceful throughout, and the reader’s pleasure uninterrupted.

The tasks of the literary translator, and those of the accountant who maps financial statement items to XBRL taxonomies, have little in common. But with respect to word choice by the former and element selection by the latter, their marching orders are similar. Both should choose from the existing glossary the term that most nearly matches the intended meaning; only when no term corresponds should the lexicon be expanded.

The art, of course, is deciding where nuance requires neologism. I remember a TV host asking the awesome wordsmith William F. Buckley Jr. – who once wrote a column titled I Am Lapidary But Not Eristic When I Use Big Words – why he so often violated the admonition to writers to use familiar terms. Buckley replied that the interviewer had only stated the first half of the rule; the full injunction is to use the simplest word that most completely conveys the writer’s meaning. (Buckley’s response is more fully and elegantly conveyed in the cited article.). There’s a constant tension between familiarity and precision and anyone who puts fingers to keyboard will make his choices (eg, IMHO, there’s little to be gained by using eristic instead of controversial or disputatious.)

But writers and translators know that, even if eristic isn’t in our personal dictionary, we can find it in Webster’s. The Webster’s of the US financial reporting world is the 2011 US GAAP Financial Reporting Taxonomy which has some 15,000 elements. Whether this number is small or large, adequate or inadequate, can be debated (as can the 15,000 estimate itself). What is indisputable is the large number of extensions to the taxonomy that companies are using in their XBRL exhibits. In a March 21 blog post, Dan Roberts reviewed some 1,500 filings and noted that 23 “have over 50% extensions, with the highest being 67% which translates to two out of every three data points reported and tagged in XBRL were extensions.” In a recent Compliance Week article, Dan states that “extensions so far represent about 11 percent of all data reported into the XBRL system.”

Imagine trying to read The Leopard with one of every ten words in Italian!

Let’s assume – wrongly – that all of these extensions provide more precision and information than existing elements in the taxonomy. Taken as a whole, might extensions represent significant added value that analysts can utilize, offsetting any added difficulties in comparability? 

Financial statement data is essential to the work of the securities analyst, but it’s also important to understand its limitations for his needs. The data is expressed in the language of complex and voluminous accounting rules that can offer its authors wide latitude in methodology. It is historical data, and while it contains clues about the future, it’s mostly about the past. It’s completely public and available to everyone, which means the analyst’s ability to gain any marginal advantage from it – as opposed to proprietary information that can be gleaned -- is difficult and limited.  By “proprietary,” I don’t mean anything nefarious, like unauthorized insider information; rather, it is all the nonfinancial knowledge – management quality, new technology, industry structure, customer sentiment, the regulatory environment, and so forth -- that analysts most vitally bring to bear.

Moreover, there are analysts, and then there are analysts. I once attended a career planning session that included a panel discussion with investment professionals, among them two securities analysts. They were each asked how important accounting was in their work. One said that accounting was the language of business -- if you didn’t like accounting, forget about a career in the financial world. The other, a technology analyst, hesitatingly said he thought there might be someone over at Bear Stearns following accounting issues.

Both responses were perfectly reasonable: for some industries, like banking, the reported numbers – and the rules under which they are determined -- are crucial, while in others (certainly technology) stock prices are driven by “proprietary” information. Of the thousands of equity research reports I’ve read, only a minority made any mention of accounting standards, and often just to clarify year-over-year comparisons.

The relative usefulness of financial statement footnotes – which promises to turn the steady flow of extensions into a tidal wave – is brought into sharp relief by the results of a FINRA-sponsored study published last August in the Journal of Accountancy. Examining how “investment professionals” (including both buy-side and sell-side analysts) and “nonprofessional investors” use the company annual report, the study found that while 68% of professionals viewed at least one of the 21 footnotes, 12 of the 21 footnotes were viewed by fewer than 20% of professional analysts.  The highest percentage of professionals viewing any single footnote was 37% (the disclosure of “subsequent events”).

A possible counterargument of XBRL proponents would be that this low utilization is exactly the reason we have the mandate, which will soon allow investors to penetrate opaque footnotes and unlock their analytical value. Perhaps, but a recent letter to the SEC by the Committee on Corporate Reporting of Financial Executives International does not indicate latent demand for any XBRL data:

Of those companies that track the usage of this information [ie, XBRL filings] on their corporate websites, none reported more than a slight interest in this information from the investor community. The number of hits ranged between 3 and 20 hits, per quarter and some of those may have been either employees of the company or the service provider verifying the accuracy of the final XBRL data posted on the websites.

Whatever efforts one might make toward mitigation – the difficulty of finding XBRL data on corporate websites, the lack of a “critical mass” of XBRL data that would make it worthwhile, alternative sources for XBRL exhibits – a neutral observer must admit these are very low numbers indeed.

Ralf Frank worries that XBRL “still looks and feels more like a concept car than one [investment professionals] can drive off the lot.” In a recent interview with Hitachi’s Data Interactive blog, he ruefully complains “What about downstream processes? The corporate reporting supply chain – that is how those of us in the investment world would see it – does not end in the database of a regulator.” While recognizing the value of the “real assets” of the IFRS and US GAAP taxonomies, he extols the virtues of a “Core Financials” approach:

We have always been in favor of a strategy for XBRL that rests on spreading it as quickly as possible….Under a “Core Financials” approach reporting would be wide, not deep. XBRL instances containing broad, core financial summary sheets for a large number of companies would be provided rather than detailed, granular instances on fewer companies. So investment analysts would have, say, 50 items from each of 10,000 companies instead of 1,500 items from each of 1,000 companies.

But has this current lack of utility of XBRL exhibits made me an apostate? Not at all. I still believe the global data standard for business information, when deployed with converged IFRS/national GAAP accounting principles and rules, will offer extraordinary benefits for both investors and the broader class of economic actors. But the focus must shift to the needs of end-users, the consumers of financial information. A 10-K will never be as much fun to read as The Leopard; but through the efforts of the XBRL community it can be made more transparent, understandable, and rewarding.  

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.

Time heals? Assurance avoids

Broc Romanek, editor at the Corporate Counsel has just posted an extract from the WSJ article, announcing the White House's plan to nominate two commissioners to the SEC. The first name should be well known to the XBRL community. Commissioner Luis Aguilar was the only commissioner to vote against the XBRL final rule.

We should remember why.

Commissioner Aguilar supported the goals and objectives of the SEC's Interactive Data (XBRL) program, and supportive of the proposal put forward, except for one aspect - the lack of an assurance requirement. Of course, with a 4:1 split on the vote, he could safely vote against the Rule without endangering its passage by the Commission.

But the rationale for his vote should be considered by anyone who thinks that the SEC might provide an extension to the two year liability relief provision of the Rule.  In December 2008 I wrote (and quoted from Commissioner Aguilar's comments):

Only Commissioner Aguilar had the courage to vote against the rule, declaring that this was the first time in history he has seen the SEC weaken protections for investors:

I am not prepared to reduce the level of protection that I believe investors are entitled to. Using new technology to improve disclosure is a good thing — but not when it dilutes investor protection. In these times of market turmoil, investors need to know the SEC is looking out for them.

Let me quickly say that I have always been, and remain, deeply convinced that XBRL can and will revolutionize business reporting, both internal and external, and that XBRL has the ability to deliver incredible efficiencies across the business reporting supply chain. And let me add that, in the long run, the SEC’s action last Wednesday represents a major step forward toward the full implementation of XBRL for financial reporting in the United States.

The good news is that two years have passed, and the first wave of filers (the group-1 or phase-1 or year-1 or whatever) are now leaving the protective covering of that litigation relief, and will now be liable for the content of their XBRL.

Lets look again at Commissioner Aguilar's final comment:

"It departs from our best traditions,and shackles investors with the risks and costs arising from errors and misstatements in interactive data, even though issuers control the process of preparing the disclosure and are in the best position to ensure its accuracy and reliability."

Returning Commissioner Aguilar to the SEC will be good for the SEC, good for XBRL, and I am very pleased to see his re-nomination.

Equally, returning Commissioner Aguilar should serve as fair warning that it will be very difficult to get an extension to the liability relief through the Commission, and no filer should expect to see such a deferment.

Time, they say, heals all - and indeed the XBRL world has had two years to figure out how to provide assurance over XBRL. But at what cost. Stay tuned...

Putting a price on XBRL for American Business

In 2008 the SEC mandated the provision of registrants' financial statements in the XBRL format, with phase-in being over a three year period. While many of us were frustrated by the delayed phase-in, in retrospect this was probably a very wise decision by the SEC. The phase-in has provided the window for software and processes to improve, and for there to be a body of experience to give us all a good idea of what is about to happen.


Now that we are entering the third year, and the true cost and impact is beginning to be seen and felt. It is difficult to place any truly reliable figure on the total cost to American business, but a range (albeit a very wide range) is certainly possible.


Before I go any further, full disclosure, raas-XBRL (www.raas-XBRL.com) is a service provider delivering inexpensive XBRL production services, so if I sound like a vendor, there's a reason. I am also a huge advocate for XBRL as a reporting standard. I am not an advocate for detailed tagging for the phase-3, or smaller, filers. I think that is a waste of money and time.


So what are some of the key things we learned so far?

• The SEC was not far off in their estimates of time requirements, at least for the very largest filers.
• The SEC was not far off in their cost estimates for first time filers, at least for the very largest.
• Detailed tagging is a nightmare, the value of which has yet to be demonstrated.
• It is still possible to be "opaque" while using XBRL to demonstrate just how "transparent" you are. Introduce a new system, find a new way around it.
• This is going to cost US business a lot more than anyone imagined.
• So far, the only visible beneficiaries of detailed tagging are the consultants.

It is usually around this time that I start getting e-mails from XBRL advocates asking me how, as a prior Chairman of the XBRL US Steering Committee, can I say these nasty things about XBRL. I say them because they are true.


What are my assumptions?


Lets take a minute to estimate how much XBRL is going to cost American business. To do that we need to start with some assumptions:

1. There are 1500 phase-1 and phase-2 filers, and approximately 8500 phase-3 filers, for a total of approximately 10,000 filers.
2. The most common estimates in the market are an average of 60 hours for first time filers. The phase-1 filers averaged over 120 hours. Phase-3 filers hopefully will average to the downside of the 60, but for the "highest" cost estimate I use the 80 hours for the first 10Q, and the same for the first 10K, with the other 10Qs requiring half as much time. I use the 60 hours as the "lowest" cost estimate time requirement.
3. For the 1500 phase-1 and phase-2 filers, I have estimated no change in total effort for out-years. This is because detailed tagging requires the deconstruction of footnotes each time, and is not a one-time large effort followed by a lower roll-forward effort such (as it is with block tagging).
4. For detailed tagging, although lower than the estimates that have heard (and believe, of a six-times the first year effort) I'm using a four-times cost, hoping somehow that efficiencies will result in lower total costs.
5. The SEC based it's cost-of-XBRL estimates on a $250/hr rate. I will provide a low - high range of $150 - $250 to cater for a mix of consultant and internal resources. So for the "highest" total cost estimates I use the $250/hr. For the "lowest" total cost estimates, I'm using an average $150/hr, but that does assume use of internal resources only.
6. I have also estimated an annual software license cost of $15,000 per filer.This may or may not be applicable for many small filers this is not the case, and certainly with raas-XBRL, there is no additional software license.

Before getting to the costs, I accept that these are assumptions, and as such, each is open to interpretation and modification based on the readers own assumptions, experience or knowledge. Proponents of XBRL will want to use the lowest estimates possible, to provide an ROI that is clearly positive, or at minimum a lower cost burden. The only problem is that vague notions of "transparency" when there are, today, so few users of the information, makes it difficult to demonstrate the ROI on XBRL.


I am confident that there is a good ROI for tagged financial statements, but I cannot see any decent ROI for the costs of detailed tagging for smaller filers. I believe the SEC should defer that requirement immediately, and keep that deferment in place until systems have been upgraded to be able to deliver the ROI.


The payback will come as production of XBRL becomes the norm in all consolidation software regardless of the size of package, and we can see the benefits of faster closes, cleaner numbers (internal to companies), greater ease of analysis within companies, and public domain or free software applications that enable the retail investor to actually exploit XBRL. That is when detailed tagging of all filers 10Ks and 10Qs should happen. But until then, detailed tagging of phase-3 filers is simply a massive and unjustified burden.


Lets ballpark the cost


So lets look at what these assumptions will mean for the total cost to American business of implementing the SEC's XBRL mandate.


For 2011 - 2012 (a full year of filings) the lowest total cost is almost $550 million, while the top of the range is almost $1.1 billion. Yes, in the coming year, American business is going to shell out between $550,000,000 and $1,100,000,000 in fees and additional time costs to provide basic XBRL to the SEC (and detailed tagged filing for the 1500 largest filers). That is a wide range, but is based on the fairly wide ranges that the assumptions include.


In 2012 - 2013, the SEC requires an additional 8500 companies to provide detailed tagging. That is going to result in a massive increase in the cost burden of being public. If access to capital is a primary reason for going or staying public, then the increased cost burden of XBRL detailed tagging can only reduce the value of the access to public capital. If the cost burden is too high, I think we will see a number of companies delist.


Based on the assumptions above, the total cost to American business in 2012 - 2013, for the provision of XBRL to the SEC, could reach $2,600,000,000.


These cost estimates do not include any additional cost for assurance over the XBRL. The SEC provides two years of litigation relief for the XBRL component of their filing. That two year window expires this year for the top 500, and for the next 1000 it expires next year. Presumably that means that these companies will need to have assurance over their XBRL. Current ranges for non-detail tagged "Agreed Upon Procedures" engagements are running anywhere from $25,000 to $50,000 per, with anecdotal evidence that the base price in moving upward pretty quickly. I fully expect that number to increase dramatically for detail tagged XBRL. Certainly that may be chump-change to a top 500 companies already paying millions for their audit. Yet this is an additional cost directly attributable to XBRL.


Simply put, in the 2012 - 2013 year, the group-3 filers, roughly 8500 US companies, will shoulder an additional $1.5 billion in costs to be public. That comes to an average of $180,000 per filer. Now lets imagine that my numbers are wrong, Complete wrong. 100% wrong. That still means an additional $90,000 burden per US public company.


Recommendation


The ROI on XBRL needs to be demonstrated, and soon.  I also cannot recommend strongly enough that the SEC, XBRL US Inc, XBRL International and the major proponents of XBRL work to develop and communicate the ROI on XBRL, a return on Investment to the filers, that significantly exceeds the coming upsurge in costs.

XBRL: The futures so bright, we should put away the Kool-Aid

Timbuk3 sang a song called “The futures so bright I gotta wear shades”. There really is no better way to describe the potential future of XBRL. I say potential because like all future’s, we will be part of making that future. But making that bright future first requires us to be honest about the present and the potential. XBRL will not bring world peace, and is not the best solution for many of the problem statements that XBRL says it will solve. The market has had a decade to explore and compare XBRL against other solutions to these problems, yet for some reason has not used XBRL to achieve those benefits.


It is time to acknowledge that there are problems for which XBRL simply is not the solution. Maybe it is time for us to recognize that there actually are better, cheaper, fast solutions for some problems.


That is not to say that there are not problems for which XBRL is the best solution, but more on that later.


So think of this article as me standing up in front of the world and saying “I am an XBRL-holic. I’ve drunk the Kool-Aid for too long. I know what it tastes like, but I’ve also come to know its limits”.


Forget the Myths


I have had on-again off-again conversations over the past few years with ERP vendors or advocates. My question to them is usually goes along the lines of “There’s this really interesting article on the potential of XBRL, can you take a look please and let me know what you think?” Thankfully I’ve yet to have any of these people come back and say “XB-what?”


All acknowledge the advantage of a vendor independent, open standard for information interchange. They understand and support the opportunities for semantic interoperability that XBRL enables, again from a vendor independence perspective.


But every one of them also has been scathing about the claims for XBRL to transform internal reporting and internal processes. Each of them has labeled the identified problems as being symptoms of poorly implemented ERP systems or ineffective processes. Each told me that business process re-engineering, while no longer the consulting product or phrase de-jour, is still the best way to gain the internal benefits promised by XBRL, and at a far lower price than the custom development exercises that current XBRL implementations require.


When I talk with them about the ability to use XBRL for provision of information that has accuracy built in, there is grudging acceptance, but only when that information is being provided to or coming from an external party. Normalization of reported elements in an external financial reporting environment also gains some support. The most support comes from the idea of an open standard that provides a boundary standard for provision of information between parties where the structure and content is not mandated by a form.


But while they have been almost unanimous their view that while XBRL is a valid and potentially effective standard for such data exchange, not one said that it is or would be effective for data analysis. All said that the data would first need to be converted into another format – vanilla XML, Excel, CSV, SDR or other format to allow for faster processing, storage and usability by humans or computers. Even the FDIC, which uses XBRL to collect Call Report data from banks in the United States, provides the output in three formats. I do not know of any entities that take the XBRL feed from the FDIC, but I am sure there are some.


I have heard of at least one XBRL project in which XBRL information was sold as a data-quality solution that could be used within a company for client and prospect analysis. My understanding is that the users basically said “Thanks, but we really don’t want to train our people in a whole new standard – can you give us that in Excel?”


We also hear a lot about XBRL for Internal Audit. Apparently XBRL will revolutionize consumption and analysis of data from GL or accounting systems or other data sources. This is a great dream, especially to me, a former Internal Auditor. Yet it is also a solution to the day before yesterday’s problem. Yesterday (well, for the last 15 years or so) data analysis products have been built for internal auditors (and external auditors) that will accept data from almost any proprietary GL or accounting system. These systems can then import the data and run a couple of decade’s worth of pre-packaged and developed algorithms, formulas and calculations on that imported data. (Do you want to run a Benford's Law calculation across a 100,000++ records? Well, just push a button and it's done.)


Some of these products even built the capability to import XBRL, but I could not say how many users actually are using that capability. In one case, the application can import XBRL GL, yet as there have been zero users, the company stopped supporting the standard for data consumption “years ago”. XBRL GL might have had a future a decade ago, but I now believe that XBRL GL serves only two purposes. 1) to provide a bookend to the Business Reporting Supply Chain slide that is almost obligatory when XBRL presentations are made - XBRL GL “proves” that XBRL has a place, independent of existing ERP or accounting systems, virtually from the point of transaction entry/creation. 2) to serve as a test bed for development of taxonomies for business operations. After a decade, how many ‘real’ XBRL-GL implementations are there in the world?


So, now that I have that all off my chest, we can move on to the benefits of XBRL, and my predictions, and what is the glorious future of XBRL – “so bright I have to wear shades”?


Chickens and Eggs


The XBRL Chicken and Egg problem has always been the lack of software, driven by the lack of data to use the software, there being too little data because there is not enough software that can cost-effectively create XBRL data, so there is not enough data to demonstrate the analytic power of semantically consistent data, so it has been difficult to build a business case to build the software to exploit non-existent data. And around and around we go.


The Chicken and Egg problem is coming to an end. While there have been a number of very effective XBRL implementations around the world, in most cases the data collected in XBRL is not actually made available to the consuming public. The SEC’s program is creating that giant pool of data. The entire lack of data problem (the Egg, or the Chicken?) is in the process of disappearing. Therefore we can expect two great leaps forward over the next couple of years. Note I said a couple of years. This is not today, and certainly not yesterday. This is in the future…


First, as millions of data-points of accurate information are made freely available, developers are beginning to understand the potential uses of that data, and the potential applications that can add value to that data. This is already happening, and we are seeing the first products coming to the mass market. This will accelerate.


Second, as production of XBRL becomes an assumed requirement for accounting and financial reporting systems, we will see XBRL being built into almost all systems. With XBRL being built in as an output format, it is only a small step (okay, not really) to allowing the linking of any input data to a corresponding element within a company specific, industry, national or international taxonomy. Even better, it should become possible to link any input data to corresponding elements in multiple taxonomies.


What will this allow?


The market, with enough data-sets and individual XBRL-tagged facts, will (note I’m still using the future tense, though that becomes the present within months, not years) confirm to the software industry that there is enough data, and therefore probably enough demand, to support a business case for new software development.


It will allow (again, future tense) listed companies to not only provide their own financial statements on their websites, but to produce low-cost, high quality analysis of themselves and their peers/competitors – basically self produced market analyst coverage. Companies will also have the ability to provide the type of analysis that will enable a visitor to actually “play” with the data and run comparisons directly from the investor relations screens on the company’s website. Talk about being able to “tell your story, your way”.


More regulators will (some already do – present tense) be able to perform rapid and cost effective analysis of companies, identifying the outliers sooner than the market, such that regulators may intervene before investors suffer massive losses from fraud or business failure. This will enable regulators to more cost effectively achieve their mandates of protecting the markets and investors.


High quality, free data, provided directly from the regulator, will force the data aggregators to improve the quality and range of services built-into their data offerings. Why? Because is the data is free, the value is in the added services, not in selling the data. Anyone will be able to download the data for free. At a guess, the Google and Yahoo Finance online services will be adding additional capability, if they are not already – enabling the side by side analysis of multiple companies, at little or no cost to the retail investor.

So in this not-too distant future we have XBRL being produced as a natural output of most accounting systems, and we have inexpensive tools for consumption and analysis of XBRL. This opens the market to the entire commercial banking systems around the world to request XBRL versions of financial statements, radically increasing the number of companies producing XBRL. And they will be producing XBRL because it will be as easy as producing an Excel, Word or PDF version of their financial statements for their bank. When the marginal additional cost to produce XBRL sinks to $0, there will be no reason not to produce reports in the standard.

Finally of course, XBRL being built into systems will support improved governance, risk management and effective internal controls – where that is not already being achieved through effective process implementation or re-engineering. It will definitely improve the external reporting process, by reducing internal data-friction.

So yes, the future of XBRL is so bright that if we focus on what XBRL can actually achieve, we can put away the Kool-Aid, and put on the shades!

Light a candle today, and remember!

It is not right to celebrate anyone's death, but sometimes it is difficult not to. My loathing for the man, and all that he stands for, simply makes it impossible not to feel a sense of release knowing that he has been killed. Of course he is not alone, so there remains much to do. Criminal lunatics who hide behind and use their religions to justify terror and evil must be resisted, no matter where, no matter who. May his name be erased from history. May his deeds fade.

And those that worship him, may they come to realise that the only things he accomplished were to harm them, their children, their countries and their futures.

So today light a candle and remember his victims - in every land.

How to make the best of the (fill in the blank) XBRL situation

From Twitter: @mwillis001: How to make the best of the XBRL situation. PwC Webinar, May 11 2pm EST ... http://bit.ly/en84ki

Now, some people might expect me to say something like "How to make the best of the XBRL situation". After all, the "XBRL situation" could be described as an avalanche of mandate rushing downhill, about to crash over those nice little American businesses all standing around with theirs cups of hot chocolate by the ski lifts. Okay, maybe not, after all, it will be in July and August that more than 8000 companies will produce XBRL for the first time and provide it to the SEC. I just could not bring myself to use the tsunami metaphor.

Regardless, there is a significant additional reporting burden arriving, and all the wishing won't make it go away. And that means that business must get ready.

How to make the best of the (fill in the blank) XBRL situation:  So to jump directly to my suggestion, then you can read the rest is you want, is for filers to download and read the 2011 XBRL Buyer's Guide. No decisions should be made based on one single factor, but on a balance of the factors that matter most to the situation and needs of the company.

But now, back to the my stream...

I was just bemused to see one of the greatest advocates for XBRL and the first Chairman of the XBRL International Steering Committee actually promote a webinar call "How to make the best of..." anything. To me, "how to make the best" has always been one of those phrases that is linked with "of a bad situation".

I for one do not think that XBRL is a bad situation, but is it a situation of significant additional cost to business. raas-XBRL, my firm, provides inexpensive production of XBRL for SEC registrants. We're proud of what we do, how we do it, and the fact that we use state-of-the-art software that is the best and most intuitive by far. (And I've been looking at this stuff since 2003).

So what are the "situations"?

We keep hearing estimates of 80 or more hours to produce the first "block tagged" XBRL. We think this is crazy. We consider 10 hours to be plenty of time. Also, we think that 4 hours of review, for the vast majority of companies, is plenty of time.

Learning a new technology. Why? How much time did you spend learning PDF?

Implementing specialized software. Frankly, I expect virtually all accounting and reporting packages, regardless of their size, to be including XBRL as an output format within the next three to four years. And the great news with this is that only the worst laggards will have XBRL as an output format only. I also fully expect accounting and reporting software to be pushing XBRL deeper into the process, so that information is linked to appropriate company specific (or industry standard) taxonomies from the point of initial entry of the information. This will allow the information to be tracked all the way through the process.

So XBRL is going to deliver significant business process improvements. Eventually.

But today vendors are suggesting that you should not wait until your existing accounting and reporting systems cater for XBRL, but you should invest potentially tens of thousands in new systems or replacement systems, simply so that you can avoid spending a far more modest amount of money to "make the problem go away".

But of course, its not a problem, is it? It is a "situation".

So I also recommend you attend the PwC Webinar on May 11, so that you too can learn "How to make the best of the XBRL situation".