Yes, I took the month "off"'. I avoided most things XBRL (and even many things CSR). I chilled. And I liked it. Sure, I read the XBRL Google Alert every day, as well as the other 10 - 12 that I get. But instead of reading almost everything, there were days when the headlines were enough for me to say "na, nothing of interest here...'
And it has been a wonderful and liberating month off.
Lets face it, XBRL is interesting, and it might actually eventually amount to something. But then again, it could just as well be a slightly interesting information cul-de-sac. Sort of like the Multics operating system, or the ADA programming language. Both were hot. One because it was very good, but complex. The other because it was mandated by the US Federal Government for ALL systems.
Both turned out to be interesting cul-de-sacs. Sure, they helped show the way (from the wikipedia article: "Bell Labs pulled out of the project in 1969; some of the people who had worked on it there went on to create the Unix system. Multics development continued at MIT and General Electric."). But eventually they disappeared when technology leapfrogged. They were the leapfrogs, but somehow got left behind.
And the month off has reminded me that this will probably happen to XBRL, and sooner than we think.
There are thousands of applications under development every day for the iPod/iPad/iThingy, and thousands more being written for the cloud (on Google Apps, Yahoo, MSN, etc). And you don't even need XBRL if you want to download a public companies financial statements into Excel. There's a 'right-click' for that right in the browser. Where are the XBRL applications?
And as for XBRL either solving or avoiding the next financial crisis - well that's just a fantasy. No data standard will in any way influence or impact what is really a crisis of confidence based on the results of years of those with the data lying to those who trusted them. XBRL would not have avoided the last crisis (or the next one) - no data standard will.
So I think I'll spend a bit more time with sunsets, and a bit more time worrying about how companies can actually make a difference. How they can be more effectively controlled and how they can manage risk more effectively.
Oh, I'm still going to be 'all over' XBRL, even if only to watch it slowly fade into irrelevance and shift farther back into that corner of the business known as "compliance". You know, the area that costs us too much money while only delivering value to someone-else somewhere-else.
And I'm still going to read the articles that tell us how one day, any day now, companies will be using XBRL to drive internal process improvements - something they have been completely unable to do using their existing ERP systems that they have paid millions to install, maintain, improve and use. "Here, just take this little pill (XBRL) and all your ERP efficiency and effectiveness ills will be cured". It doesn't work that way. Never did, never will.
But we can go on dreaming. Hell, maybe I shouldn't go on holiday, maybe I should just keep dreaming about what XBRL might do...
But, this not being a complete dream-life, I've made myself a few commitments. I commit to:
1. continuing to provide the best service to our XBRL clients
2. ignore those those who fantasise (or lie) about what XBRL may do. They have agendas that are disconnected from the actual needs of those that will have to pay.
3. continue to raise questions - like "So when will XBRL International actually produce their own financials in XBRL?" If it is so easy and cheap, you'd think the very standards organization would use their own standard.
4. continue to wonder when, over a year later, the 'new' XII website will be announced
Rats! - I shouldn't have written that list, I think I need another holiday!
07 September 2011
25 July 2011
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.
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.
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.
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 |
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.
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:
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...
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.
22 July 2011
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.
12 July 2011
Do you REALLY want to violate SEC Reg FD?
 |
| Violate Reg FD here |
Okay, you've just finished your 10-K/10-Q. The final numbers are done, and the auditors have 'blessed' the document. Before the document is filed with the SEC, someone on your team creates an e-mail that attaches the draft 10-K/10-Q and sends it to an anonymous website that promises to let you see what the HTML version will look like. Congratulations, you've probably just breached SEC Reg FD and perhaps a host of other securities laws.
For all you or anyone knows, you've just sent your filing to a competitor, a newspaper, an analyst, a potential investor.
Exactly the same risk applies to the XBRL versions of financial statements that must now be provided by all filers. And indeed that is exactly what a website today suggests you do. A site that will allow you to upload a copy of your XBRL files and provide you with a viewer to see what your XBRL will look like once its filed with the SEC.
I tried the site today, using an XBRL document downloaded from the SEC (special thanks to the person who suggested this obvious way to test... so obvious I missed it). I wonder how many other people got to see the XBRL that I uploaded. Thank goodness it was not the XBRL of a real client or filer.
Broc Romanek, Editor of TheCorporateCounsel.net, notes: “If companies are accidentally selectively disclosing their financials, that appears problematic and they could be deemed to be violating Reg FD as well as be considered to have inadequate disclosure and internal controls.”
For all you or anyone knows, you've just sent your filing to a competitor, a newspaper, an analyst, a potential investor.
Exactly the same risk applies to the XBRL versions of financial statements that must now be provided by all filers. And indeed that is exactly what a website today suggests you do. A site that will allow you to upload a copy of your XBRL files and provide you with a viewer to see what your XBRL will look like once its filed with the SEC.
I tried the site today, using an XBRL document downloaded from the SEC (special thanks to the person who suggested this obvious way to test... so obvious I missed it). I wonder how many other people got to see the XBRL that I uploaded. Thank goodness it was not the XBRL of a real client or filer.
Broc Romanek, Editor of TheCorporateCounsel.net, notes: “If companies are accidentally selectively disclosing their financials, that appears problematic and they could be deemed to be violating Reg FD as well as be considered to have inadequate disclosure and internal controls.”
How innocent, and enticing - XBRL is complex, so to make sure your XBRL will be viewable on the SEC site, just upload it here and you can view it yourself.
But look closely at the site. There are no names, no contact individuals. A Who-is search comes back with no information. This should raise alarm bells to any IR professional, any CFO or any auditor. Just who will be accessing this information.
Last week, I went to their "Contact Us" page and sent a message asking who they are. I have not received an answer.
The "https" URL is a great red herring. It screams "we are a safe site, we encrypt to and from". But if you have no idea where the data is going, does it matter how safe the transmission is?
But look closely at the site. There are no names, no contact individuals. A Who-is search comes back with no information. This should raise alarm bells to any IR professional, any CFO or any auditor. Just who will be accessing this information.
Last week, I went to their "Contact Us" page and sent a message asking who they are. I have not received an answer.
The "https" URL is a great red herring. It screams "we are a safe site, we encrypt to and from". But if you have no idea where the data is going, does it matter how safe the transmission is?
In November 2010, after the leaks of Walt Disney and NetApp finanicals, Dominic Jones of IRWebReport wrote "IR Web Report’s view is that the recent incidents are due to management at the companies failing to put in place proper disclosure controls and web publishing systems, not because of any inherent weaknesses in website technologies." (emphasis his)
We're now moving into a new world of filing, with the addition of XBRL documents as part of the filing package. These XBRL "instance" documents contain all the information included in the primary financial statements and notes to the financial statements. These documents in XBRL require the same level of protection and control as they did when they were just the financials. Prematurely disclosing the XBRL documents should be conceptually the same as releasing the HTML version of the official filing.
So now imagine finishing your 10-Q, and the XBRL version of that 10-Q. Well, the XBRL certainly does not look like the HTML that you have put so much work into - maybe you should load it into a viewer to see what it will look like, at least to confirm that the numbers and labels and elements are correct.
It would be difficult to come up with a better example of an opportunity to demonstrate poor controls over the release of financial information
Of course, I do not believe that this is a cynical attempt by a company to gain nonpublic insider information, or to get companies to accidentally violate Reg FD.
I also do not believe that any company that is providing a public service has any reason to do so from behind a mask of secrecy.
04 July 2011
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.
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.
30 June 2011
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).
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.
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 |
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.
11 June 2011
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.
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.
08 June 2011
The SEC should defer "detail tagging" for smaller filers
Late last week raas-XBRL wrote to the SEC, recommending that they defer the "detail tagging" requirement for smaller filers. We believe the burden on smaller filers has not been offset by an adequate communication of the benefits that such additional effort will deliver.
We've talked about the burden of "detail tagging" XBRL on small filers. We've estimated that the second year requirement for filers could add up to $1.5 billion in additional reporting costs in the 2012/2013 filing year. We've also asked - where's the ROI on detail tagging?
Detail tagging while not particularly complex, is a significantly higher level of effort than the basic tagging required for all filers in their first year of providing XBRL to the SEC. Estimates that we have seen range from 6 times to 10 times the first year effort.
Strains are beginning to appear in total resources available for XBRL production. The phasing of the rule is in part contributing to this resource constraint.
For example, the increased workload to support the 1000+ filers who are entering their second year of XBRL (and therefore straining their internal resources and the financial printer / filing agent resources) is happening just at the moment when the remaining 8000+ filers are fighting for the same resources to produce their first XBRL for the SEC. We are hearing that some financial printers / filing agents are "closing their books" to new business. We've now heard about two that have closed their books, and have heard rumors of at least one other.
We expect this year to be resource constrained. Next year will be even worse. And that will impact prices. Not to mention quality.
As we said in our letter to the SEC:
We've talked about the burden of "detail tagging" XBRL on small filers. We've estimated that the second year requirement for filers could add up to $1.5 billion in additional reporting costs in the 2012/2013 filing year. We've also asked - where's the ROI on detail tagging?
Detail tagging while not particularly complex, is a significantly higher level of effort than the basic tagging required for all filers in their first year of providing XBRL to the SEC. Estimates that we have seen range from 6 times to 10 times the first year effort.
Strains are beginning to appear in total resources available for XBRL production. The phasing of the rule is in part contributing to this resource constraint.
For example, the increased workload to support the 1000+ filers who are entering their second year of XBRL (and therefore straining their internal resources and the financial printer / filing agent resources) is happening just at the moment when the remaining 8000+ filers are fighting for the same resources to produce their first XBRL for the SEC. We are hearing that some financial printers / filing agents are "closing their books" to new business. We've now heard about two that have closed their books, and have heard rumors of at least one other.
We expect this year to be resource constrained. Next year will be even worse. And that will impact prices. Not to mention quality.
As we said in our letter to the SEC:
It sounds like a joke, but it is not – we’ve seen a real case of a major US financial printer/filing agent’s Indian operations advertising for XBRL taggers – any university degree accepted, including veterinarian. Does this mean that Indian veterinarians may be tagging the financial statements of SEC registrants? And this is in the year when the SEC’s estimated 8700 third-year filers will be providing “block tagged” XBRL. Who will be performing the tagging when the workload for those 8700 filers is six to ten times the work to produce “detail tagged” XBRL? Do we care? Only if it impacts the quality of the tagged information, and we believe it will negatively impact that quality.
We also are still waiting for the SEC and the Wizards of XBRL to release real ROI calculations. And that means both sides of the equation, the costs and the benefits, not just the benefits. "Ignore the man behind the curtain" is not the right answer. The right answer is that the net benefit to a filing company will be $xxx,xxx over five years, and the net benefit to the SEC will be $yyy,yyy,yyy over five years. The net benefit to the investor would be a good thing to be able to quantify also.
Until that ROI can be quantified, we call upon the SEC to defer the additional onerous burden of "detail tagging".
03 June 2011
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.
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.
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.
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:
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?
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.
- 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...)
- Today the only assurance that can be provided over XBRL is through Agreed Upon Procedures - not an audit and not external assurance.
- The cost of assurance over block-tagged XBRL ranges from $25,000 - $50,000, a range that reliable sources have told me is 'conservative'.
- 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.
- Extension elements (in first year "block tagged" XBRL) are running in the 10s, not the 100s in block tagged XBRL.
- 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.
- 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.
- External assurance, for the same subject matter, generally required more work and quality assurance than AUP internal assurance.
- Auditor risk will be significantly higher for external assurance over XBRL than for AUP assurance.
- Auditors will have identified process improvements that will reduce a "cost per element", so to speak, or assurance.
- 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.
- Total effort (big assumption, please feel free to modify) will therefore be 8x the AUP (10x the XBRL, more QA, improved processes).
- 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.
- 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".
- 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.
- 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?"
- 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...
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?
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:
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.
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:
- There are 1500 phase-1 and phase-2 filers, and approximately 8500 phase-3 filers, for a total of approximately 10,000 filers.
- 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.
- 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).
- 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.
- 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.
- 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.
Subscribe to:
Posts (Atom)