31 May 2011

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.  


25 May 2011

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?

23 May 2011

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.

19 May 2011

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...

14 May 2011

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.


09 May 2011

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!

02 May 2011

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.