raas-XBRL

30 Days Grace anyone?

2011-09-08T08:52:00.000+02:00

Filing day has come and gone, and the number of XBRL filings has, as expected, exploded. But clearly the anticipated 8000+ have not filed. Now the question is: how many companies are availing themselves of the 30-day grace period for first time filers? A question all the 30-day grace filers must ask their vendor: how will their vendor change the vendor's processes to ensure they do not miss the filing date next quarter?

It now seems that up to 45% of year-3 filers missed August 15th filing date and are taking advantage of the 30-day grace period.

That is a significant number of companies, in the thousands, that have yet to provide their XBRL to the SEC. This also means thousands of companies that should be demanding that their vendor clearly demonstrate wat process changes will be made to ensure that do not miss their filing dates in future quarters.

Of course the numbers are evolving quickly, with the 30-day grace period coming to an end next week.

Okay, I've been away a while

2011-09-07T10:50:00.000+02:00

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

And it has been a wonderful and liberating month off.

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

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

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

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

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

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

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

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

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

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

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

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

Implications of XBRL on Audit firms

2011-07-25T10:50:00.014+02:00

The growing requirement for companies to produce financial statements in the XBRL format is now beginning to impact auditing firms. Audit firms need to plan for the coming wave of additional effort required to provide assurance over XBRL documents, and need to be building the cadres of skilled individuals who will provide such support to audit teams. The phase-in periods are quite different by jurisdiction, as is the expected total additional effort.

Audit and assurance firms should be exploring the potential impact and planning exactly when and how they will build the skills and acquire the tools that they will need to provide assurance over XBRL documents produced by clients.

The potential cost of audit could have a negative impact on market acceptance of XBRL. We must be looking beyond the depth of the pockets of Megaconglomacorp, and understand the impact of XBRL audit on smaller filers and smaller (non Big-4) audit firms.

Go to Non-Sequitur to learn more about Megaconglomacorp: http://www.gocomics.com/nonsequitur/2010/07/21

XBRL is not a "new" standard and is being used around the world, primarily by regulators, to improve the quality of data collected, and to improve the quality and efficiency of analysis of that data. In some cases the information is converted to XBRL by the regulator, and in other cases the reporting companies produce the XBRL. It is company produced XBRL that will be audited.

Challenges

As with any "new" technology or process, audit firms will face challenges as they come to terms with new audit requirements. Certainly an initial challenge will be deciding if and when to develop a cadre of skilled individuals with the knowledge to be able to audit XBRL. Too early and these skills will not be required, too late and the rush will impact operational efficiency. Yet moving beyond the simple “do we / don’t we” question into a time when audit of XBRL is performed, there are three challenges that audit firms and the audit profession needs to consider.

Resources

As we know, the resource requirements of the audit process are not "smooth" through the year - there are clearly definable peaks of resource requirements, falling at quarter-ends and annual reporting events. These peaks vary from country to country depending on the distribution of financial year-ends and the amount of audit activity that gets squeezed into short periods of time.

I use the image of a wave moving toward the beach - the total resource required at any time represents the sea, and the increased time sensitive resource represent the wave. Consider how that wave approaches the shore (the mandatory reporting event) and the way the resource wave grows as it approaches the shore. At that last moment before breaking on the shore, the wave reaches its highest point - the most resources are being applied in that final short moment to ensure a final report.

XBRL reports are, in most cases today and for the coming three to six years, produced "after" the primary report is finalized, as an additional output format. This means that the audit of the XBRL (at least the "final" XBRL) report represents an additional set of highly specialized skill sets added to the top of that resource wave.

Software

Of course auditors mitigate the total resource required through the use of sophisticated software tools. Certainly in the XBRL space, tools are now available that help reduce the total incremental effort, and these tools are evolving quickly. Today however, most software is an extension to validation software and requires the user of the software to be an XBRL "expert".

Standards

Finally there is the problem of auditing standards. As yet there are no standards for the auditing of XBRL. There is guidance (from the American Institute of CPAs - AICPA) for the performance of "Agreed Upon Procedures" (AUP) examinations and reviews of XBRL documents. This assurance however remains "negative" assurance and for internal use only. The XBRL International Assurance Working Group continues to discuss issues around provision of assurance, but does not have the remit to produce an auditing standard. It is probable that the AICPA's AUP guidance will form the base of any future standard for providing assurance over XBRL.

The lack of an international auditing standard for XBRL will not remove the need for auditors to provide some level of assurance over the XBRL being produced. Audit firms will need to consider their own thresholds of tolerance when providing assurance, and should be lobbying the IAASB and IFAC to fast-track the development of an auditing standard for XBRL documents.

Costs

While my purpose is not to suggest how Audit firms perform assurance, or to indicate the effort involved, it is worth noting that in the United States, AUP engagements for provision of assurance over XBRL documents have resulted in total auditor time of between 50 and 100 hours for the first basic "block tagged" XBRL (tagging of financial statements), and significantly higher for "detail tagged" XBRL (tagging of all financial information throughout the financial statements and notes to the financial statements). Subsequent quarterly "reviews" will take take, but should not require the full 50+ hours. Expect the total hours to quadruple for "detail tagged" XBRL.

The primary cost drivers are the time required to perform the engagements, and the software used in the engagement. Subsequent engagements should see the total time commitment reduce, and enhancements in XBRL audit software over the coming few years should also reduce the total time required.

The Market and tolerances

This may seem simplistic, but I think it is fair to say that the average auditee will not lightly accept an additional 50 - 100 hours of audit time added simply to audit the XBRL. Those in the XBRL space that are focused only on the Fortune 1000 or FTSE 100/250 do not see this as an issue - these hours will simply be folded into the already thousands of hours and many millions of Dollars or GPB that makes up the total audit cost.

But we must look beyond the depth of the pockets of Megaconglomacorp, and try to understand the cost to the vast majority of other businesses. These are the companies, public and private, that will be paying first to create XBRL and then paying to have the XBRL audited. Therefore we must be looking for ways to reduce the incremental cost the cost of production and audit of XBRL. While process improvements and reductions in reporting time will reduce the cost of producing XBRL, the additional cost of auditing XBRL must also be reduced.

I fully expect software to audit XBRL to improve significantly over the coming couple of years, to the point where the total complexity and cost can be brought down to 'reasonable' levels. Of course, "my" reasonable and an auditee's reasonable may or may not be the same thing.

What will not change will be the need for auditors to gain a working understanding of XBRL, and the need for audit firms to have this additional expertise available.

What to audit in XBRL

Some (but only some) of the XBRL audit issues include:

Use of extensions – if allowed, why were they created, and is there already an existing element?
Confirmation that the information is the "same" – This covers more than simply “are the numbers the same”.
Parentheticals – is all the information appropriately tagged, including information include within labels.
Calculations – are all calculations appropriately constructed
Dimensions/Tuples applied
Label over-rides – have the taxonomy standard labels been used, or company specific labels, and do all labels match the non-XBRL documents
Taxonomy selection – obviously the correct taxonomy must be used

The list goes on...

What is XBRL

XBRL (eXtensible Business Reporting Language) is an open standard for the interchange of business information between computer systems, by mapping information to entries in logical dictionaries (taxonomies) of business terms, thereby ensuring that the provider and recipient of the information share the commonly accepted meaning of each piece of information. XBRL also allows the creation of custom dictionary entries (extension elements and taxonomies) to allow the reporting or provision of company specific information.

In effect, XBRL allows a “wrapper” of information to be placed around any business "fact", be it a number, a date, or text. In XBRL terminology, this is called "Tagging", or to "Tag" a piece of information. That “wrapper” then ensures that the provider and recipient are referencing the same definition of the information, significantly improving the usability of information by reducing potential errors and confusion over the meaning of any individual piece of information.

XBRL gets "competitive"

2011-07-22T12:23:00.000+02:00

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.

Do you REALLY want to violate SEC Reg FD?

2011-07-12T14:52:00.001+02:00

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

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?

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.

The Corporate Counsel: Inside Track - July 5th

2011-07-06T13:12:00.000+02:00

You can listen to the podcast here.

Broc Romanek and The Corporate Counsel (www.TheCorporateCounsel.net) have done a great job of making sure that the SEC's XBRL mandate remains at the front of mind for Corporate Counsels across the country. After speaking last week, Broc invited me to interviewed for their "Inside Track with Broc" podcast, this instalment talking specifically about the third phase of the. It was a pleasure to speak with Broc, and I hope you will find it equally interesting.Broc told me that his initial interest in XBRL dates to 2000, almost making me a "youngster" in XBRL terms, with my 2003 debut.

We covered four questions provided by Broc:

What phase of XBRL recently took effect?
What implementation issues are smaller companies facing now?
What can smaller companies do to overcome these issues?
How does raas-XBRL help clients overcome these issues?

You can listen to the podcast here.

My thanks to Broc and the folks at The Corporate Counsel dot net.

XBRL and Banking - the coming boom

2011-07-04T09:19:00.001+02:00

I am very positive and hopeful (no - expectant) about banks using XBRL for credit analysis, and the Dutch are leading the way.

The coming deluge of filing in the US, with an additional 8000+ companies financial statements being available in XBRL, will have two very real impact in relation to banking and XBRL.

1. No smaller accounting or financial reporting software will be able to 'ignore' XBRL, and I fully expect XBRL to be a standard output format for all within the next two years.
2. There will be a steady flow of new applications to analyse the information, with some of those applications being natural applications for bank.

Where will this lead? Directly to Banks using XBRL for corporate client credit analysis and monitoring of non-public clients. It is only a matter of time, and not very much time, before banks will be requesting XBRL versions of financial statements from non-public clients - statements that today are provided in Word, Excel, PDF or even fax/printed.

The changes that this will drive include, but certainly are not limited to:

1. Better XBRL production software, either as out-sourced services, SAAS, or built-into already in use accounting and financial reporting systems.
2. A massive increase in the pool of XBRL data - although the vast majority of that data will not be publicly available.
3. Assurance over XBRL will take on even greater importance, and tools and processes to make that highly efficient will be needed - soon.
4. New taxonomies for financial reporting - in most cases "closed" taxonomies sponsored either by individual banks or by banking associations and industry groups. Why "closed"? Because extensibility is great is you are the SEC and you want anyone to report anything. If you are a bank, a million extension elements is simply unrealistic and of zero additional value to your analysis.
5. Better quality credit analysis, leading to more efficiently scaled cost of capital for non-public companies (lower for the better credit risk companies, higher for the higher risk companies).

So I am actually extremely bullish about XBRL for banking. It is not here now, but the market conditions are finally coming into place to make it almost inevitable in the next few years.

I remember my very first XBRL meeting

2011-06-30T11:29:00.001+02:00

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

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

Who benefits from XBRL - 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

You can have your XBRL in any color...

2011-06-21T21:27:00.002+02:00

"You can have your XBRL (or is that 'Model-T') in any color you want as long as it is black"... Remember when you could only buy your Model-T in black. Probably not, but my grandmother can. Imagine also that, while black is the only available (or allowable) color, you can buy your Model-T from any of a number of dealerships that offer a range of prices and services. Is price now your only factor? Is the fact that you buy your grain for your horse from the same dealer your only factor?

2011 XBRL Vendor Selection Checklist

Selecting an XBRL solution or vendor should not be a "one dimensional" decision: lowest price, existing financial printer, or any other single factor makes for poor decision-making. This is not to suggest that one factor or another will not have a higher priority, but it does stress the point that there are a number of factors going into the buying decision.

Of course, a good long term "relationship" certainly should factor into the decision, but buying your Model-T from the grain store does not automatically make sense.

While we certainly are ready to talk price, we like questions, and think there are plenty of questions that should be asked. Some of the questions we like to hear include:

"How long have you been involved with XBRL?"
"How much of our time is this really going to take?"
"How much XBRL do I really need to learn?"
"How much "pencils down" time will you need?" - or what we think of as "Check-in time"

We've also heard questions such as:

"How much time do you need to convert or produce the XBRL?"
"Who owns the mapping - someone told me they did, and that we would need to start all over if we changed vendor or took this in-house"
"What are your 'extra charges' and do you have 'change fees' or 'last minute change fees'?"

Which leads us to... Oh no, a checklist...

But wait, don't despair, or ignore. The purpose of the checklist is to help you to select the most appropriate option for your XBRL production needs. Used with the 2011 XBRL Buyer's Guide, this checklist with help you decide based on your priorities, which options are best for your needs.

We've kept the checklist to one page, and to as few a number of questions as possible. Just rank your responses by the vendors that you select, potentially including your existing horse-feed provider (oops, financial print vendor).

XBRL: Flight-time vs Check-in time

2011-06-17T11:28:00.003+02:00

Some years ago (1995 if I remember right) we arrived in London from the US, took the train to Paddington, had coffee with a friend, and then took the Stansted Express to Stansted Airport. If ever a product description lied about the actual product, it is the Stansted "Express". Needless to say, we arrived at Stansted exactly 45 minutes before our flight-time. That's at the train station at Stansted, not at the counter.

By the time we reached the check in counter, it was 39 minutes to the flight time. The flight was closed. We were not going to be on that flight, and had to rebook on another flight. So, yes, we missed our flight, because we did not leave enough time.

What does this have to do with XBRL?

Well, one constant refrain we've heard for a couple of years now is the question of how much time before the filing deadline do companies have to make changes to their official filing, and still have time to have the changes reflected in their XBRL. "We make changes right up to a few hours before filing" is a common statement, followed by "Why can't we continue to do that with XBRL?" The onset of "detail tagging" for year-1 and year-2 filers has exacerbated that question, with some XBRL production houses (filing agents, financial printers, outsource producers) requiring up to a 5-day "pencils down" requirement.

We are even hearing the same five-day "pencils down" time being quoted to year-3 filers who are providing XBRL for the first time.

Is this reasonable? Will filers accept or comply?

Well, the reasonableness depends on the acceptance of the idea that there is a difference between the Flight-time and the Check-in time.

SEC's Filing deadline = Flight-time

"Pencils down" time = Check-in time

Consider the number of passengers that need to board the plane, and the amount of time that takes. Queuing for those wonderful people at TSA, then queuing at the gate, then in the boarding ramp, and finally, waiting for that nice person who really should have checked their F***** huge bag, and then the final shuffle into your seat. Well, now you are on board and buckled in, we can take off, right?

Well, yes, you can now fly.

But unless you are willing to buy (or lease) the airplane yourself, you are probably sharing that resource. Your XBRL production is no different. Unless you are paying for resources to be dedicated to your company alone (which with the potential size of the effort for 'detail tagging' you might be) then there is the possibility that you are not the first person on the plane.

And we need to make the point, XBRL is not HTML. This is not a simple conversion of output formats - Word vs PDF vs HTML vs XBRL. It may well be in the next two to three years, but it is not today.

(A parenthesis here: If you have purchased software that integrates the XBRL production into your financial reports processes, and have re-engineered your processes to make the production seamless, then you might have 'simple' conversion. There are options that enable this, and if they are within your price range, they are worth considering. Provided of course you also choose to use a financial compliance issue as the justification for a systems re-engineering and potential replacement exercise. Then again, if your company if large enough, you probably do lease the jet.)

So the question is not "why can't we arrive and board at Flight time" but "How reasonable do we consider the Check-in time that we are being told".

Associated with those questions is a simple statement:

Unless you own or lease the airplane, it is your responsibility to get to the airport by Check-in time, to ensure that you do not miss the flight. You cannot blame the Airline if you miss the Check-in time, and you cannot blame the train or the cab (Accountants or Auditors). You are responsible for getting to the Check-in counter on time. We were, and we missed our flight, and it cost us.

2011 XBRL Buyer's Guide r2.1

2011-06-15T17:36:00.000+02:00

Today is X-Day, the day the SEC's XBRL mandate comes into full force.

From 15 June 2011 (today), all remaining filers are required to provide XBRL with their next quarterly fling with the SEC, and all 20-F and 40-F filers will need to provide XBRL with their next filing (once the SEC approves the IFRS taxonomy for their use). We continue to hear that companies are searching for solutions, and wondering what to do.


Download the latest release of the 2011 XBRL Buyer's Guide (release2.1).

We're hearing that CFOs, Controllers, Directors of Investor Relations, Filing Agents and even Lawyers are being deluged with calls from XBRL vendors. We're also hearing from companies that have received their invoice for the coming year, and are experiencing "sticker shock". We shouldnt' be surprised. After hearing non-filers say things like "$25,000 is a reasonable amount for a company to pay to be compliant" - we wonder just how many CFOs of filers they people actually are talking to.

Equally, we are hearing rumors of XBRL providers "closing their books", cancelling contracts, or renegotiating contracts at higher rates. At the other extreme, we hear things like "I know a guy in India who says he can do it all for $500. He tells me its just XML". Oh well.

So with the mandate coming fully into force today (X-Day), we decided it was time to release an update to the Buyer's Guide. Not a full new release, but an update to "release 2", with additional vendors and some modifications in scores.

Welcome to release 2.1 of the 2011 XBRL Buyer's Guide. Why is there a new release? We've also received suggestions for changes in specific scores, and we've identified additional vendors that should be included (or received e-mails from vendors asking to be included).

We are also releasing a Check List for Vendor Selection - that uses the four factors and a few questions to help filers determine the best selection to meet their needs.

As always, we look forward to hearing from you, and are ready to answer any questions, or provide any additional guidance.

Guest Post: Using XBRL for Solvency II reporting

2011-06-11T18:25:00.001+02:00

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.

The SEC should defer "detail tagging" for smaller filers

2011-06-08T15:52:00.001+02:00

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:

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

SEC's askOID - 2 Thumbs Up

2011-06-03T16:34:00.000+02:00

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

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

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

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

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

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

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

XBRL: Meeting the Needs of the Financial Analyst

2011-05-31T11:58:00.000+02:00

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

XBRL: Meeting the Needs of the Financial Analyst

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Don't fear the XBRL

2011-05-25T22:15:00.000+02:00

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

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

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

1. XBRL is SOX all over again.

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

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

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

3. XBRL will take 120 hours of people time.

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

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

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

5. The taxonomy is huge.

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

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

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

But there are a few things to worry about:

7. Year-2 Detail Tagging.

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

8. Assurance costs.

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

Summary -

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

Assurance over XBRL: the potential cost for American business

2011-05-23T08:08:00.000+02:00

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.

Time heals? Assurance avoids

2011-05-19T15:34:00.001+02:00

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

We should remember why.

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

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

Only Commissioner Aguilar had the courage to vote against the rule, declaring that this was the first time in history he has seen the SEC weaken protections for investors:
I am not prepared to reduce the level of protection that I believe investors are entitled to. Using new technology to improve disclosure is a good thing — but not when it dilutes investor protection. In these times of market turmoil, investors need to know the SEC is looking out for them.
Let me quickly say that I have always been, and remain, deeply convinced that XBRL can and will revolutionize business reporting, both internal and external, and that XBRL has the ability to deliver incredible efficiencies across the business reporting supply chain. And let me add that, in the long run, the SEC’s action last Wednesday represents a major step forward toward the full implementation of XBRL for financial reporting in the United States.

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

Lets look again at Commissioner Aguilar's final comment:

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

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

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

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

Putting a price on XBRL for American Business

2011-05-14T13:21:00.001+02:00

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

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

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

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

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

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

What are my assumptions?

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

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.

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

2011-05-09T12:18:00.003+02:00

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

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

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

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

Forget the Myths

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

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

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

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

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

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

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

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

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

Chickens and Eggs

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

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

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

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

What will this allow?

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

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

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

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

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

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

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

Will Indian resources save XBRL?

2011-05-06T10:00:00.000+02:00

Over the past couple of years I've been asking the question - "Where are all the XBRL experts?" Apparently they are all in India. Does this mean India will be the XBRL "back-stop" for SEC registrants? The best answer I can give is "maybe". On the one hand, the news from India is good news in relation to the pool of resources and experts. On the other hand, I fear an over-reliance on India is going to cause some real headaches.

India is of course famous to all of us these days as the land that outsourced American services, just as China is the land that outsourced American production.

In the XBRL space, the largest US filing agents have been quite busy setting up their operations, and estimates of total numbers of individuals employed range from 1500 to 2000. All the major filing agents are represented there, with some having quite significant operations. We've heard of famous names in the XBRL world making repeated trips to India to run basic XBRL training courses for their outsource infrastructure.

In addition, the UK operations of the Big-4 accounting firms have all set up BPO operations in India to support the UK's iXBRL program. At least one of the UK firms (and possibly more) have refused to expand their Indian affiliate firms, and have created "Big-X UK, India" offices, reporting directly to London.

We are now hearing that it is becoming increasingly difficult for the the BPO operations to find skilled resources with the required experience in preparing and understanding financial statements understanding and background. Our favorite example is the very large US filing agent (you know who you are) that advertised for anyone with a degree, even a veterinarian degree, to apply to going join their XBRL team. We could only speculate that they have a large number of pets or other animals at their facility that might need looking after.

The issue of staff-poaching between filing agents is real. This is driving up their costs of business, while at the same time reducing the already limited longevity of their staff. Considering that these are new facilities, one might question the use of the word "longevity" in the first place..

But there is an additional problem arriving very soon, that will further reduce the available pool of resources that can provide XBRL support for US filers - the introduction of an XBRL filing mandate by the Indian government. This will result in significant local demand for XBRL expertise, and further cost pressures on the BPO providers who have set up in India.

Of course, in addition to resource issues, there are the "standard" cross-cultural communications issues. These can't be helped, but they can be managed, and will be. One strange example happened when I received a "LinkedIn Connection Request". While that is not unusual,at least one of the profile pictures was. I had to stop and remind myself that what I was seeing was a cultural symbol meaning good luck, not the meaning that is seared into most of our "western" minds.

My underlying concern remains the total volume of XBRL expertise that exists, and matching that volume of expertise to the demand for XBRL services. While India looks like a solution today, there are real pressures on the total resources available, and those resources are already being stretched.

Light a candle today, and remember!

2011-05-02T08:31:00.000+02:00

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

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

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

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

2011-04-28T21:24:00.001+02:00

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

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

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

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

But now, back to the my stream...

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

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

So what are the "situations"?

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

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

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

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

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

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

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

Looking back, looking forward - the SEC's XBRL program

2011-04-26T14:34:00.000+02:00

(This was originally posted on the Insitutional Risk Analytics weekly newsletter by Christopher Whelan on 12 April 2011.)

The US Department of Homeland Security now requires all airlines to provide a list of all US bound passengers before the airplane takes off from its originating airport. Why? Because waiting until the plane arrives to screen for potential terrorists or threats is wasteful. The information upon arrival may be accurate and complete, but it is no longer timely.

Financial reporting to the markets is much the same, with audited annual reports and quarterly reports being provided to the SEC (and through them to the investor community) - in effect after the plane has landed. By the time the information is provided to the SEC, it may be accurate and complete, but it is no longer timely. The immediate buy-sell-hold recommendations and actions have already taken place at the time of the earnings release, and sometime before. In fact it is difficult to find anyone that actually looks at a 10-K in detail.

In 2008 the SEC proposed a rule requiring registrants to provide XBRL (eXtensible Business Reporting Language) versions of their annual and quarterly reports (10K and 10Q) and for foreign filers to provide XBRL versions of their 20-F or 40-F filings. In 2009 the final rule was passed (33-9002) ( http://www.sec.gov/rules/final/2009/33-9002.pdf ) that created a three-year phase-in based on market capitalization and filing status of each registrant.

This new reporting requirement was sold by the SEC as a step forward for the investors, by reducing the effort required to consume information (no more parsing of HTML or text documents) and improving quality of information reported (by removing manual re-keying errors). After all, if information can be consumed at the data element level, with a 'tag' telling the consuming computer what that piece of data is, then the entire process becomes quicker, cheaper and more accurate.

The dream is great, the reality is additional reporting burden and cost for little visible benefit. And this is where the SEC can and should be focusing its efforts - demonstrate and communicating the benefits of XBRL, and push for greater adoption earlier in the reporting process. Because "Interactive Data" as the SEC calls XBRL, can deliver real time and cost saving, companies should be looking for ways to exploit the additional reporting power that XBRL provides, and the SEC should be fine tuning their program.

A Short History

To find the origins of the SEC's XBRL program we need to go back to the grim days after Enron and Worldcom and the introduction of the "Full Employment in the Accounting, Auditing and Consulting Professions Act", also known as Sarbanes-Oxley (SOX). Numbers - 302 and 404 - became the newest form of torture out of Washington. CEO/CFO certifications of the effectiveness of Internal Controls ensured that no matter the economy, the auditors (and consultants) would be busy, for at least a few years through implementation and the first couple of years of operations.

But buried in SOX was another number - Section 408 - which requires the SEC to review all filers not less than one every three years, and many filers every year. The highly manual (all right, manual takes on a new meaning when it means copying and pasting data from documents into spreadsheets, but none the less, by today's standards that is manual) processes at the SEC meant that these review requirements were simply unachievable. Something was needed, and the idea of tagged data, directly consumable by systems to automatically populate analytic engines looked, and still looks like just the answer to this problem.

As an aside, when I asked a senior SEC official what they would say if Congress asked them if they were complying with section 408, he answered "Dan, we would look them in the eyes and say 'Yes, of course we are complying'." Then he smiled.

Of course, the SEC didn't need SOX 408 to know that they needed to do something. They wanted to find the next Enron or Worldcom before a whistleblower or counterparty discovered it for them, the hard way. They knew they needed to do something, and the forward looking leadership began to press for improving the use of the information they already receive, or changing if necessary the format of the information received.

As SEC Chairman Christopher Cox can into office, with budget constraints and a system that was moving too slowly, he found an existing program in place exploring the concept of "tagged" data. Conrad Hewitt was an early supporter of the concept, and Jeff Naumann had already been brought over from the AICPA to explore the concept and if possible, provide a set of recommendations on how to move forward.

At the same time, Jon Wisnieski at the FDIC (in conjunction with the FFIEC and OCC) was developing the new CDR project to upgrade the Call Report process. This project pushed XBRL out into the Call Report production software used, at that time, by 8200 banks across the United States for their quarterly reporting.

The XBRL component of the CDR project went live in late 2005 and saw immediate benefits in terms of the quality of information reported to the FDIC, and dramatically reduced the overheads at the FDIC for analysis of banks. Reporting times dropped, data quality jumped almost overnight, with the number of banks that received queries from the FDIC each quarter dropping from around 35% to 5%.

The same information, or a subset of that information, was then made available to the investor community through feeds from the FDIC, in one of three data formats, two compact legacy formats as well as the full XBRL document. IRA uses those feeds from the FDIC (but not in the XBRL format) to populate their database and feed their bank analytics and ratings. The key here is that the fact of XBRL in gathering, characterizing and validating the bank reports enables a multiplicity of data output choices for consumers.

And the SEC could only have been watching the FDIC with envy.

Mandate

So in the heady days after the successful FDIC implementation, Barry Melancon at the AICPA received a call from Chairman Cox asking for a letter outlining the steps the SEC could and should take to implement an XBRL program.

The timing could not have been better, as on the day of the call, an internal meeting at the AICPA took place in which one of the discussion items (informal of course) was when and how to wind up the AICPA's direct involvement in XBRL and when to sack the AICPA's Director of XBRL. It does not take much to imagine a possible change in tone, from "how do we reduce this overhead" to "how do we maintain control over the XBRL movement".

As Chairman of the XBRL US Steering Committee at the time, the change was easy to see. One week the question from the AICPA was "can we spin off XBRL in 6 to 9 months?" Soon that had morphed into "we think it might take a couple of years to spin off XBRL into an independent entity." So a letter was written to Chairman Cox outlining the steps that the SEC could take to position itself to implement XBRL.

The first and most important step was completion of the US GAAP taxonomy, which at the time was being built by dedicated volunteers, and simply was not ready. As Liv Watson of EDGAR Online said, an "Industrial Strength Taxonomy" was required.

And so it was.

In September 2006 Chairman Cox again called Melancon and this time asked how soon an independent XBRL entity could be established to be the contractor to build that industrial strength taxonomy, and could that new entity provide a proposal to the SEC for the development of the taxonomy.

I've left out a number of steps that took place in between the letter and the call, including a meeting at the SEC in which I was asked how much the taxonomy would cost. My answer then was that I had been told by the Taxonomy Working Group that it would cost $4.5 million. The answer I got was "That's too bad, if it was a hundred million it would be easier to get appropriated than $5 million - that's just the way Washington works."

None the less, as part of an EDGAR system upgrade program, the SEC budgeted $5.5 million for the XBRL US GAAP taxonomy, with the contract to be fulfilled by the newly created XBRL US Inc.

With the coming change in administration at the White House, or at least an assumption of a coming change, it was clear that if Chairman Cox was going to get the credit for modernizing the reporting environment, an XBRL proposed rule would be needed, and a final rule voted on by the Commission by late 2008.

The clock was ticking.

At the same time, the Pozen Committee, while supporting the introduction of XBRL, recommended a phased in approach. The Committee's concerns turned out to be spot-on. Was there adequate software available in the market to use pure XBRL documents? Were there an adequate pool of resources that understood XBRL file creation? Most important, would the cost to filers be comensurate with the benefits and thus acceptable? But the ghost of SOX haunted the program.

In 2008, the proposed rule was issued and subsequently voted on to become the final rule, with it's three year phase-in. In 2009 the first XBRL instance documents began to arrive at the SEC. Giving the SEC credit, the estimated cost of implementation per company for first year (non-detailed tagged data) was up to $80,000. A review after the first year found the experiences of companies to be very close to that level of cost. The SEC had no idea what the cost of detailed tagging would be. In the two years since the first companies provided XBRL, costs have come down, the software has become much better, but there remains a chronic shortage of skilled XBRL specialists.

Who benefits?

So now the largest 1500 public companies companies across America are producing and providing XBRL versions of their financial statements to the SEC. In addition, some companies are using XBRL as the opportunity to improve their internal reporting processes, pushing XBRL farther back into their reporting systems. United Technologies ("UTX") is a good example, having used XBRL as the catalyst to improve their external reporting processes, saving over 800 person hours per quarter (before the detailed tagging requirement, but that is a different issue).

The other 8700 companies (the number estimated by the SEC in the "final rule") will be providing XBRL for the first time with their second quarter 2011 filings - their 10Qs due on August 15th. Foreign filers filing in IFRS will be providing their 20-F or 40-F filings in XBRL starting with their 2011 annual reports, provided the SEC approves the IFRS taxonomy.

So other than those companies using XBRL to re-engineer their external reporting process, the primary beneficiary today is the SEC. As mentioned in the introduction, the investor community has yet to demonstrate significant interest (other than pockets here and there) in XBRL, simply because the information while complete and accurate, is not timely. It is timely for the SEC, as their analysis is based on the audited and reviewed financial statements, not on the earnings release. Of note, a separate mandate requires Mutual Funds to provide the risk and return summary in XBRL, beginning January 2011. These filing are already arriving at the SEC.

2011 XBRL Buyers Guide (release 2)

2011-04-25T12:04:00.000+02:00

After the wide interest shown in the first edition of its 2011 XBRL Buyer’s Guide, raas-XBRL is pleased to launch the revised and updated second edition, the definitive and industry-endorsed guide to XBRL service and software providers, complete with the raas-XBRL scorecard.

With so many smaller reporting companies yet to make a decision about how they will meet the US Securities and Exchange Commission’s (SEC) looming deadline of August 15 for filing the second-quarter 10-Q, the raas-XBRL Buyer’s Guide serves as an indispensable aid to help them navigate their way through the XBRL vendor market. The updated Buyer’s Guide has increased the total coverage of vendors to 26, covering four categories of filer options. A copy of the Buyers Guide can be downloaded here: http://www.raas-xbrl.com/2011-xbrl-buyers-guide

Every SEC registrant company’s priorities are different, and to take this into account, the guide identifies a framework of four main criteria which may be weighted accordingly to structure decision-making when selecting an XBRL preparation solution.

The four key criteria are:

1. How much time will this really take? - The time spent on XBRL preparation will vary significantly depending on the solution, and time estimates must necessarily include time spent by both internal and external resources.

2. What is the estimated cost by solution? - Every vendor will quote a price, but it is important to clearly identify what is included in that price. Is it a “total” price, or are there additional costs that will be added during the XBRL preparation process?

3. How much XBRL do you actually want to learn? – Do you want, or need, to become an expert in a data standard? What is the right balance for you between in-house and outsourced knowledge of XBRL?

4. What is the vendor’s history with XBRL – Just how much experience does a given provider have with XBRL, and how important is that to you? Some vendors have been around almost from the beginning, while others have “appeared” in the last year or two.

raas-XBRL is one of the 26 vendors evaluated in the Buyer’s Guide, and while every effort has been made to ensure objectivity and accuracy, raas-XBRL CEO, Daniel Roberts, admits that raas-XBRL cannot claim total impartiality. However, he firmly believes that the Buyer’s Guide accurately reflects the reality of the XBRL vendor market. “At raas-XBRL, we've selected what we believe to be the best XBRL preparation software available on the market; not just the best, but a true paradigm shift. We’re talking about software that has been producing high quality filings to the SEC, including detail tagged filings, with error rates at or below the average of all SEC filings. What really sets us apart is that we substantially reduce, to the point of almost eliminating, the learning curve and lost time clients’ internal financial reporting teams would otherwise have to cope with – and at a very affordable price."

Recent XBRL myths

2011-04-17T21:50:00.001+02:00

Over the past weeks and months even, there has been a growing pool of myths about XBRL. Some of these are, frankly, uninformed while others provide justification for the high prices that some vendors are charging. Here we present some of the fallacies that we are hearing that are being passed off as hard fact.

1. 30,000 - 40,000 or more elements in the taxonomy

More and more websites are cropping up with warnings that with 30,000 or 40,000 elements in the 2011 US-GAAP taxonomy, XBRL is a really complex problem that will require experts to help solve - even if it’s just to wade through all those elements.

Fact: the FASB says that there are around 15,000 elements, and that the 2011 release has not resulted in any meaningful increase in the total number of elements. Now, we're not suggesting that 15,000 elements is not a lot, from first hand discussions with the FASB, we have been told that the 30,000 - 40,000 number is just plain wrong.

Fact: there have been a huge number, easily over 100,000, Extensions. but extensions are not a core part of the taxonomy, and may be contributing to the confusion.

2. 80 hours or more of client-side (filer) time

First-wave filers (the top 500 companies) did take an average of over 120 hours to create their first block-tagged XBRL (57% of respondents to an AICPA/XBRL US Inc survey of first time, top 500 filers). Additionally, as recently as December 2010, one of the major filing agents told an audience that they should expect their block tagging to require 125 person hours, *plus* internal filer time and expertise.

Fact: We think this is madness because we have been producing quality XBRL that requires an order of magnitude less total time, on our side and on the client-side. Opinion: any process that requires that much time (80+ hours for block tagging of Wave-3 filers) is simply inefficient or uses inefficient software.

3. Complexity

Yes, XBRL is a complex standard but then so is PDF. If there is one common comment we keep hearing it is, "How can this be so complex, our financial statements are not that different from our peers or even from most other companies. We do nothing exotic, so why is this so difficult?"

It does not need to be, and again this is Opinion, but anyone who tells you how complex this is, is simply ensuring that you are too scared to either do it yourself (with the right software) or engage someone to make the problem go away at a fair price. Consider your options. We've heard the president of one software provider say that they will not be satisfied until XBRL (with their tool) is "as easy as Word", and from what we've seen, they are well on their way to accomplishing that goal.

4. Cost

There are plenty of vendors charging from $15,000 to over $30,000, and some that are charging as low as $995 for software. These are not myths. The myth is that to get it done right by someone else you either need to pay that those exorbitant amounts, or that if you buy the $995 software you will not need to spend a huge amount of time becoming an XBRL expert.

5. It can be really really cheap

Well, that's not really a myth either - it can be really really cheap. Remember though, you only get one grace period, and if your service provider is not resourced for the peak time, then you will use that first grace period, and be stuck worrying about your provider’s ability to actually get it done on time next time, when you have no grace period.

6. FPIs are getting a deferral

As yet, Foreign Private Issuers have NOT been given a deferral. The SEC has said that they cannot file in XBRL until there is an approved taxonomy, and the IFRS taxonomy has not yet been approved by the SEC. That is very different from a deferral. Of course there might be a deferral, but that is not what the SEC has said.

Opinion: We fully expect the IFRS Foundation to release an updated taxonomy (they have already announced that they will), and for that taxonomy to be approved by the SEC which means that FPIs will indeed have to file XBRL versions of their financial statements.

Summary of articles for 2011 first time XBRL filers

2011-04-10T11:53:00.000+02:00

Over the past eighteen months at the Random Comments blog, we have posted a number of articles and comments that we think are relevant to the Group 3, or Year 3 filers - those that must provide XBRL to the SEC for the first time in 2011. Instead of making you search and wade through the other stuff, we thought it was time to publish a quick directory.

The following is a quick directory of articles broadly grouped by topic. Over the time it seems there have been some consistent themes, including the cost and burden of XBRL, the availability (or otherwise) of experts, background type posts and some predictions. We hope this is helpful to anyone faced with their first year of XBRL.

1. Don't expect the SEC to delay the XBRL program for Group 3 filers

Cost and Burden

2. Is XBRL Expensive? (Costs range from Under $8,000 to over $30,000).

3. Why is XBRL so Expensive (Cost Factors) Mainly people time and software, and the interaction of the two.

4. So how much effort is really involved?

5. More on estimated costs How the SEC estimated the cost of XBRL com(January 2010)

6. Never confuse cost with quality (Quality vs Price 1, Quality vs Price 2)

7. Detailed tagging, just how big is the burden? Answer: Ouch!

8. Detailed Tagging explained: a descent through Dante's inferno Or, the first 4 levels of Hell?

Availability of Experts

9. Over 10,000 companies to create XBRL this year - expertise will be in short supply

10. After a decade of the standard, where are the experts

11. Cost of (voluntary) assurance over XBRL today

Options for filers

12. As published in IRWeb Report - the 2011 XBRL Buyers Guide

13. Should you replace your entire external reporting framework to produce XBRL?

14. 5 Questions filers should ask any prospective service provider or software vendor.

15. Outline of first time filer options.

Background

16. Why did the SEC mandate XBRL? Remember SOX?

17. Observations about recent filings (March 2011)

18. XBRL and the audit and assurance industry How some auditors are using XBRL as a marketing tool.

19. A conversation with David Blaszkowsky of the SEC (Part 1, Part 2)

Predictions

20. Prediction time (detailed tagging)

21. Assurance anyone? It will happen, but first the auditors need to figure out how to.

Guest Posts

22. Dennis Santiago of Institutional Risk Analytics (XBRL Usability - Part 1, Part 2)

23. Neal Hannon:XBRL Conventional Wisdom Might be Wrong

XBRL will be vital for CR reporting - but not by itself

2011-03-25T17:39:00.000+01:00

Last night (24th March 2011) CorporateRegister.com announced the CR Reporting Awards for 2011 (results here). They also provided for a "debate" which, while I was unable to attend in person, I had the pleasure of participating in.

There were two topics:

Topic A: In future, all good CR reporting will be integrated
Topic B: XBRL will be vital for CR reporting

This second topic matched Liv Watson against Daniel Roberts (me). Liv's bio on the site reads: "Liv Watson is a Director and leads the Research and Development function at AccountAbility. She was one of the original developers of the XBRL standard, as well as a founder of the XBRL International consortium." I have had the pleasure of knowing Liv as a friend from many years. Her contributions to XBRL rank above virtually everyone else.

Liv's (and my) full arguments are here, and comments are invited.

I thought I would also publish my arguments here. They stand alone form the general argument, and reflect my belief that we must do more to make CR (or CSR or Sustainability) reporting more effective, and that XBRL is only one way to accomplish that goal.

------------------------------------

There are more important issues to be addressed in CR reporting

Let me begin by stating that I believe that CR (Corporate Responsibility) reporting is no longer a nice-to-have – it is vital for capital markets to perform their primary function; the efficient allocation of capital for optimal return to investors. That means taking into account the true cost and impact of business, and that requires far more information than is currently reported.

The “Efficient Market” theory is well and truly dead, and in its place is recognition that more effective communication is required to approach even a facsimile of an efficient market. That additional communication needs to clearly demonstrate how each company impacts the “commons”. XBRL by itself does none of this, it is a boundary standard for the exchange and provision of data-level information that can be ‘trusted’. XBRL is important. But there are more important issues that must be addressed in CR reporting.

So if I (regretfully) disagree with the statement “XBRL will be vital for CR reporting”, then what do I consider vital?

1. Mandatory reporting
2. Against a regulator defined standard
3. That integrates financial and non-financial measures
4. That is audited
5. And finally, that is tagged, preferably in XBRL

1. Mandatory Reporting:

As long as CR reporting is optional, all reporting will be subject to the test: “Are we getting a better return for our money by producing this report than spending that money on other marketing activity?” Optional reporting ensures that forward looking businesses will report, cynical businesses will report what they want to report, while cost-sensitive businesses (which means most businesses) will provide limited or no reporting.

Mandatory reporting by all listed companies will ensure that the markets can view reported results from all companies by sector or size, or any other combination. Mandatory reporting is possible, requiring only the political will to make it so.

2. A Regulator Defined Standard:

Multi-stakeholder-created standards produce reporting requirements that are, by their very nature, the negotiated product of, well, stakeholders. This makes the standards malleable, with the reporting company invariably having the option of what to include and exclude. This makes CR reporting fundamentally a marketing issue. I call this the “Windmills and Daisies” syndrome, designed to create a good feeling while deflecting the reader from deeper issues.

Only when the regulators define the standard (with none of this “Core” and “Additional” stuff) will the standard be able to be applied equally. Ideally, such a standard would be the work of a consortium of regulators. In effect, an IASB for CR reporting.

3. Integrated Reporting:

Mike Krzus and Bob Eccles make the case for integrated reporting in their fine book “One Report”. They cite examples, and show how it is possible today to provide a more complete picture of a business for the investor community. Such reporting, in conjunction with a regulator defined standard, will ensure that what we now call “extra-financial information” or “externalities” can be and are reported alongside the range of information we currently use.

4. Audited CR reports:

When the external auditors review the financial statements, they do not ask the client what is in and what is out of scope, or what is material. They decide the scope and materiality. Until CR reports are subject to the same standard of assurance, the content and information provided will be viewed with skepticism. Such auditing standards already exist, so no additional standards development is required.

5. Report content tagged for easy consumption:

Once financial and non-financial information is being provided in a single integrated report, complying with a regulator approved standard, and containing audited information, it will only be a matter of time before providers and consumers of the information seek mechanisms to make it “easy” to consume. I want the information to be provided in XBRL. I am a huge proponent of XBRL, and chaired the XBRL US Steering Committee.

But only once organizations like the GRI (and others) stop paying lip service to XBRL, and build a real taxonomy, will the information be tagged in the XBRL standard. As a supporter of XBRL, my personal fear is that something “simple” will be used as a substitute, reducing the value of the information and benefits that can be achieved.

In summary, CR reporting requires meaningful, complete, accurate and trusted information that communicates a company’s true impact in a manner that allows rational decision making based on a holistic picture of the business. Certainly that information tagged in XBRL will be helpful to consumers of that information. Most important today is that the information is being collected and made available.

Observations from the (XBRL) Cloud - 15th March

2011-03-21T13:48:00.001+01:00

As more XBRL is produced and provided to the SEC, what can we say about the instance documents as a whole, and with limited information, what general observations can we make?

The first observation I would make is that the SEC's validation and acceptance of instance documents probably needs to be tightened up a bit. Arguably, the SEC should not be accepting a filing with over 95 SEC Edgar Filer Manual (EFM) validation errors. Likewise, when some of the largest filers are providing XBRL with 67% of elements being extensions, it suggests that detailed tagging might produce an awful lot of data, but precious little comparable data.

From a software or vendor perspective, there are also some interesting observations. The first, of course, is that the name of the software used to produce the XBRL may or may not relate to the actual parties that produced the XBRL. Certainly the software provider is named, but the filing agent or outsource provider (for example) is not. Still, even the information that is available is illuminating.

So before I jump in to some of what I've seen, I'd like to thank Cliff Binstock for producing and providing the XBRLCloud Report online. This is a fantastic resource for performing a simple 'health check' on the current state of XBRL filings with the SEC. On 15th March 2011, I visited the XBRLCloud report and copied it into Excel - the report currently is limited to around the 1500 most recent filings, due no doubt to the size of the downloaded information. For my purposes this is fine (although I would love to see all the data) as it roughly covers the first filing season of this year, with most of the first and second wave filers reporting.

Key findings

In terms of the results, I've picked out some specific information, and run some averages. For each of these, I deliberately don’t mention the specific company or software solution that was used to create the instance document, as I'm sure all the software vendors will be pointing out their successes (be it the most filings, the cleanest filings, the fastest or the cheapest). There is no need to point out the software vendors or filing agents (where they are the same) whose tools produced the instance documents with the most errors, warnings or inconsistencies (I call these the dirtiest, though that's probably a bit unfair), or the most extended filings.

One interesting observation is that it seems easier to get an SEC EFM Error accepted than a Warning. For example, the instance document with the most Errors (EFM) had 96, while the instance document with the most Warnings had only 8. Of course, when we look at inconsistencies, the largest had 775. Now that's impressive. I could well imagine a conversation after seeing a list of 775 inconsistencies: "But will the SEC accept it?" - "Yes" - "Then just file the damn thing and move on."

Errors (EFM)

As already mentioned, the highest number of SEC EFM errors in a filing was 96. But there were an 90 examples of instance documents with EFM errors. The good news is that means there were over 1400 instance documents with zero (0) EFM errors. Furthermore, no vendor is over-represented in the EFM errors category, with some having no EFM errors in filings created with their software. However, while some vendors had zero Errors, no vendor had zero Errors, Warnings or Inconsistencies.

Moving into Warnings and Inconsistencies, the numbers become a little more interesting, with the highest "scores" (so to speak) being 8 and 775 respectively. As mentioned above, it is remarkable that the highest number of Errors in an accepted filing is 12 times the highest number of Warnings.

Errors (GAAP Architecture)

Looking at GAAP Architecture errors, the numbers are also a little disturbing, with the highest number of errors being 382. That's a huge number of GAAP Architecture errors in one filing, and again, suggests more of a "running out of time" than an acceptance that errors are acceptable.

As with the EFM Errors to Warnings ratio, there is a similar ratio in the GAAP Architecture errors, with the highest number of Warnings being 26 in a filing. Again, there is no specific pattern across the vendors.

Extensions

The biggest issue visible to all is the percentage of extensions. 23 of the filings in the list 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.

The entire point of an extension is to provide the capability to report information that represents a unique aspect of a company's operations or reporting. As David Blaszkowsky said to me some months ago ""Well, the number of extensions is being seen, or presented, as a bad thing. Actually, I could not disagree more. I'm quite excited about extensions. Thinking about it, extensions will reveal unique differences in substance between companies. Isn't that the whole point?" Unfortunately the level of extensions in some filings simply makes a mockery of that idea

Why so many extensions? Who knows? Could it be that the US GAAP taxonomy is inadequate for some types of organization? Could it be that it was simply faster to create a new extension for each item than to search for and use the appropriate element? Was there a desire to "be transparent while ensuring opacity"? It certainly suggest that the FASB has its job cut out updating the taxonomy with elements to enable comparability.

I do not know the answer, but "I'll tell you what I know - England Prevails". (Oops, sorry about that - 10 "attaboys" to the first person who correctly identifies the movie that is from).

But back on track; I do not know the answer, but I cannot imagine that XBRL tagged information that is two-thirds extensions actually adds any value to the analysis of an individual company, or provides any assistance in sectoral or industry analysis.

Observations

I said that I would not discuss individual vendors and their results. The averages across vendors/software are not significantly different, with some highlights and some, well, low-lights in the data. In addition, for some of the software solutions there are too few filings to make analysis and discussion meaningful. One "high error" report where there are only six filings using that software does not prove a trend, especially when the other filings using the same software all look clean.

Equally, the XBRLCloud report does not let us see what filing agent or provider produced the instance document (except of course in cases where the filing agent and the software provider are the same).

However, it is possible to see what software is not included in the Cloud Report. That said, with a "free" offer I'm confident that they will be back on the list soon. Then again, is it possible that after their first filing (and the client subsequently moving to a different provider) a "free" offer will be a good way to attract new clients? Never mind that an audience recently heard at a show-case presentation that the actual cost of the solution would be $12,000 or more...

Summary

The XBRLClould report contains a wealth of information about filings with the SEC, and it is well worth taking a wander through the results. At the same time, it is also possible to use that information selectively. After all, we can be pleased with the number of filings and the smooth progression of the mandate but the XBRLCloud Report certainly raises questions.

Regardless, my own conclusions include:

There are still too many errors getting through (or being accepted) by the SEC's own validation.
Extensions are out of control. Is this because companies wish to create extensions (thus reducing comparability) or because the elements do not exist. Or is there simply not enough time?

Why is XBRL so Expensive? (Cost Factors)

2011-03-14T10:53:00.001+01:00

This might sound trite, but the primary purpose of a listed company is not to spend money on preparing reports for the regulator, no matter where they are in the world. Reporting to regulators is an overhead, and distracts resources from accomplishing the primary purpose of the business. XBRL reporting for the SEC (or any other regulator) requires additional software and people costs. From what we are seeing and hearing in the market, we think XBRL related costs are running at or above $27,000 for most per SEC registrants. Some are paying very much more. Really scary numbers, and this is for first time filing. We are hearing that detailed tagging is increasing costs by up to 6 times.

So why is XBRL so expensive?

Because too many of the software solutions are overly difficult to implement and require expensive (and rare) specialists - people who must have the costly dual skill sets that combine both XBRL knowledge and accounting/financial reporting expertise. Like SOX, expect gouging. Why? Because the software is complex, the standard is complex, and the skills are not readily available.

Of course the question "Why is XBRL so expensive" contains within it the answer to the question "Is XBRL expensive". I addressed this in my most recent article, where I point out that the perception of the cost of XBRL (in terms of it being "expensive") is an assessment that only the paying company can make, not the consultants or other external observers who stand to gain from a company's pain. The $25,000 quoted is not the highest price, and in too many cases does not include the time commitment required of companies.

Blatant commercial interjection: It does not need to be like this. Visit us.

So, accepting that spending money on reporting to regulators is an overhead, then any additional costs of such reporting can only be described as expensive.

Let’s look at the components of the cost of XBRL compliance. Basically there are two costs - People and Software.

People

People costs fundamentally are made up of cost of peoples' time (and the lost opportunity cost of that time) coupled with external time-based fees such as training costs or consultant fees. We'll use a benchmark of 60 hours for our cost estimates here. The highest estimate I've seen was 125 hours, not including internal resources. I don't know if this was scare-mongering, but it certainly scared me. But for "group 3" filers, I won't estimate more than 60 hours:

40 hours consultant time

20 hours internal time

Consultants: The SEC calculated an average of $250 per hour for consultant support for production of XBRL reports. So those 40 hours will cost $10,000.

Internal staff: If we calculate an internal cost (full on-costs, not just salary, and excluding any training) at $100 per hour, we add an additional $2,000 to the cost.

And what will these people be doing? The first thing some of the external providers and filing agents will do is try to convince you just how complex this is. Expect to be told about "arcroles" and "hypercubes", "linkbases" and "schemas". Prepare to be "baffled with bulls**t" as the old expression goes.

Then they (certainly internal people) will be learning XBRL (the first time through anyway) and the tools. They'll be mapping the financial statements to the taxonomy and identifying where extensions will be required. They'll build a company specific taxonomy, and mess around with labels, presentation orders, and worst of all, calculation linkbases. Oh, and did I mention negation? Sorry about that, negation is another one of those wonderful aspects of XBRL that I've heard referred to as "TTS", or "Terrible Technical Stuff". The SEC also has an extra wrinkle called "parentheticals" - the numbers that appear between parentheses.

Software

Now comes the software. XBRL software is expensive because the XBRL standard is complex. The full XBRL standard (and associated but required additions) exceeds 1200 pages of text. That's before the SEC's own requirements on top of the basic standard. 1200 pages provides a lot of scope for complexity, both in the software and in the potential output.

Prices for software seem to run from more than $20,000 all the way down to as low as $995 (but expect the 125+ hours, 40 of which will be learning enough XBRL to use the software, and the rest simply ensuring the they didn't miss something in the 1200+ pages, as I've seen in one offering). Some vendors are offering a software-only option (usually around $15,000) with an a-la-carte menu of consulting support - expect the times and costs mentioned above. These vendors also offer a "full service" option at around the $25,000 price level, which excludes internal costs.

One vendor offers a $5,000 price to "convert your input files" into the XBRL format. I'm waiting to hear what the actual client side effort will be to get to the point of being ready to provide files ready to be 'converted'.

Summing it all up

So there are people costs of $12,000 to start with, and an average software cost of $15,000, and you are now running at $27,000 to prepare your XBRL for the SEC.

That's why one of our "5 Questions" is "What is this really going to cost?"

Is XBRL expensive?

2011-03-09T13:20:00.002+01:00

At a recent XBRL meeting, a participant (a representative of a large organization - not a filer) opined that he thought $25,000 was a perfectly reasonable price for a public company to pay for the production of their XBRL - after all, these are public companies and as such have the resources to pay whatever is needed to produce reports demanded by regulators. Basically - "what are these people complaining about?"

Personally, I consider an additional $25,000 to be an expensive additional cost to businesses, especially if someone else gets the benefit (but that is a different topic). Perhaps it is not so important to the Fortune 1000 companies, but unfortunately it seems easy to forget that many of the other 8000 SEC registrants are not big companies, and some actually are quite "small".

I do wonder what the reaction would be from the same person if they had to go to their superiors and say "We need to spend $25,000 on a new reporting requirement that gives us no benefit, but might help someone else, someday..."

They would inevitably be asked "How much does this reporting cost us today?"

"Well, last year we spent about $5,000 on all our SEC filings with our filing agent."

"So what you're telling me is that this year, simply to report is going to cost us 6 times as much as last year?"

Suddenly that does seem a bit expensive. Six times the cost at zero additional benefit. Of course, there are alternative options that include pushing XBRL further back into the reporting infrastructure, but here we're talking about the specific cost of implementing a regulatory reporting requirement. After all, if your advisers have already come to you with demonstrations of how embedding XBRL deeper in internal processes would save money, then you would already have done so, and wouldn't be reading this.

Being fair, I've see prices ranging (external dollars spent, excluding any internal costs for resources) from as little as $3,000 to as much as $30,000. I do recommend that anyone considering a $3,000 solution ask our "5 Questions". Actually, I recommend everyone ask our "5 Questions" of multiple vendors, regardless of the price quoted.

Number 4 in our "5 Questions" is "How much will this really cost?" We recommend filers (and their filing agents and their advisers) ask what will be the expected total cost. After all, software alone is not the only cost, nor is time. Too frequently we're hearing pricing for software separate from consulting support. We are also hearing and reading about the additional time that could be required, both by external providers and by internal resources.

Again, here are our "5 Questions":

1. How much time will this really require?
2. How long must we budget for XBRL production after "pencils down" on our filing?
3. What is the quality of XBRL filed with the SEC using your solution?
4. How much will this really cost?
5. Do we need to learn XBRL?

Because $25,000 (excluding your internal costs) is expensive, especially when there are less expensive options that require significantly less effort on the part of the filer.

So the next time someone tells you that XBRL compliance is not expensive and that $25,000 is a reasonable price to pay, ask them how much of that they would like to contribute - after all, they will probably be one of the beneficiaries of that spend.

(To provide additional assistance, we have developed the 2011 XBRL Shoppers Guide.)

XBRL Usability Part 2: Checking the Extension Cord

2011-03-02T19:06:00.000+01:00

XBRL Usability Part 2: Checking the Extension Cord

(Re-posting of Dennis Santiago's recent article - originally posted 8 Feb, 2011. Dennis is CEO of Institutional Risk Analytics. You can reach him by e-mail at dsantiago@institutionalriskanalytics.com, at 310-676-3300, or you can follow him on twitter: @DennisSantiago)

In our previous installment of IRA’s testing of U.S. XBRL filings we reported that one only needs the EDGAR Accession file to be able to properly monitor and locate SEC filings both with and without xml exhibits. We are now confident enough to cease monitoring of the SEC’s experimental XBRL feed and begin using a true production version to process filings via the standard EDGAR system.

As we await the arrival of a new wave of filings in June 2011 we thought we’d check out the library of variables that will be available. In addition to US-GAAP data elements, filers are allowed to add “extensions” to their submittals. These extensions are independently defined by each company and do not require external coordination or rationalization at this time. The way extensions are added to a filing is via the xsd file, an XBRL definitions file that starts with statements to bring in standardized taxonomies followed by the company’s independent extension set. Every SEC filing with an XBRL exhibits file set has an xsd file. Not all of them have extensions.

We instructed our computer to count up the population of 10-K, 10-Q and 20-F filings for the past year and rummage through the xsd’s. On the particular test run we did there were 36,136 SEC filings meeting our test run criteria in the Accessions tape. Of these 3,880 included XBRL exhibit attachments representing 1,488 Central Index Key (CIK) SEC Registrants. This was roughly one fifth of the population expected to start submitting in June 2011.

Of the 3,880 filings, we found that 3,039 (78%) contained extension elements. The remainder only used primary taxonomies in their construction. The number of extensions in these documents ranged from a low of one extension to a high of nine hundred twenty-two extensions in a single filing. The total number of extension elements created by the sampled filings was 183,846.

Extrapolating this to an estimated 8,100 companies submitting beginning in June 2011 (8,100/1,488 = 5.44X) says that we are looking at an annual extension library to keep track of just over one million independently created elements in addition to the US-GAAP set. Wowie!

This actually doesn’t bother us that much. We have expected for a long time now that the extensions work around for the taxonomy architects not being able to anticipate every possible data element would create this type of algal bloom in the data. It merely points out two things.

First, unless one is doing merger and acquisition work, one can probably ignore most of these extensions and do most first and second level screening analytics just using the US-GAAP subset. This replicates – if not surpasses – the detail coming out of the best of the fundamental feeds. Besides if you are doing M&A diligence, you are looking at more than just financial reporting filings anyway.

There’s always been the notion among analysts that the first true use of XBRL filings exhibits would be based on subset analytics as opposed to extreme diligence tracing of every nuance item in a filing. From what we see, the June 2011 filings population should provide the first near-census test opportunity to do aggregate and sector analysis on U.S. public companies where the data goes directly from SEC’s EDGAR system to the research department without needing to pass through an intermediary processor. And it is chain of process traceable to the government evidentiary source. We like that!

___________________________________________

Dan's Postscript: The issue of the number of extensions, coupled with versions of taxonomies, leads to questions over the costs of being able to easily consume and use the XBRL that is provided. This is an issue that the XBRL community will need to address, and doing so will help demonstrate and deliver the benefit that XBRL promises.

Hoping for an XBRL break? Don’t hold your breath

2011-02-25T17:19:00.001+01:00

Hoping for an XBRL break? Don’t hold your breath

By Anne Leslie-Bini on February 20, 2011

(This is a re-post of an article written by Anne Leslie-Bini for IR Web Report)

AMERICAN businesses affected by Sarbanes-Oxley legislation still vividly remember the days leading up to the deadline for SOX 404 compliance back in 2004/2005, and the vast army of internal control specialists that were mobilized — at sometimes eye-watering rates — to help filers meet their Section 404 requirements.

The SEC estimated that the average cost to business would be $91,000 to implement SOX section 404, although in reality the bill was often a lot steeper. At the end of the day, the burden on business was seen to be so overwhelming that the requirement was deferred for the smaller filers.

Now, here we are in 2011, Year 3 of the SEC’s phased-in XBRL program, which will see an estimated 8,000+ companies filing their 10Qs and 10Ks for the first time.

US companies have had other priorities

In Susan Kelly’s recent article in Treasury and Risk, Campbell Pryde, CEO of XBRL US Inc., is quoted as saying, “Everyone’s known about [the XBRL mandate] for the last three years, so a lot of the vendors have been ramping up to do it.”

Even if that’s true, let’s not forget the economic backdrop of the past three years: the financial system just about collapsed; the economy was brought to its knees; and a stream of changes in accounting policy came in. The reality is that companies have been largely preoccupied with other things: most have experienced severe difficulty retaining access to the credit markets, and simply surviving has been as much as many have been able to do.

Respectfully, it is not unreasonable to assume that American business has had “other priorities” these past three years, and as XBRL was not seen as a matter of urgency amongst so many other pressing concerns, it simply passed to the back of the mind and all the way out the back door.

But 2011 is now upon us and the Tier-3 companies are staring down the barrel of a mandate that the FEI’s member survey (PDF 437 KB) says will add significant additional effort to the production of 10K/10Q filings, while at the same time adding time after “pencils down” to prepare and review the XBRL filing.

In view of this and other reported findings such as Grant Thornton’s 2010 survey, it is frankly unsurprising to see a definite reluctance to engage and a growing disenchantment with the SEC’s XBRL program amongst registrants. But is this in itself sufficient justification for the SEC to instigate a deferment for smaller filers?

The short answer is “no.”

XBRL important to SEC objectives

The SEC embarked on the XBRL program not purely for “transparency” and improved information access for the investor community. One of the key, though less publicized, reasons behind the XBRL program is the fact that XBRL acts as an enabling technology for the rapid identification of companies that require review by the SEC. After all, while smaller filers managed to escape SOX section 404, the SEC cannot escape its own responsibilities under SOX section 408, which requires a review of all filers not less than once every three years, and every year for filers meeting a pre-defined set of criteria.

Protecting investors and the wider capital markets remains the primary function of the XBRL mandate and given its importance, this effectively trumps filer discontent at the extra burden that XBRL preparation lumbers them with. There is nowhere for filers to hide and they should not expect safe-harbor protection from the SEC when they encounter escalating costs for their XBRL production because the necessary resources have become scarce.

So indeed, Campbell Pryde is right when he says that Tier-3 filers have had three years to prepare for the looming XBRL deadline, at least in theory. Equally, the vendor market has had three years to build the skill sets needed to deliver the services that XBRL preparation demands; and the services market has behaved like all efficient markets should; it has matched supply to demand.

Cost may spike, but less expensive than betting on deferment

However, it is an undeniable fact that demand is about to surge, and the reality is that XBRL supply, in terms of fully-trained XBRL-savvy individuals, is relatively inelastic, implying a longer adjustment phase on supply-side capacity. What this means for filers is that a “supply crunch” is imminent, and it is likely that we will witness a substantial, maybe even SOX-like, hike in prices.

Unfortunately for filers, limited supply of XBRL expertise is not sufficient reason in itself for the SEC to defer the mandate. Visibly, many Tier-3 companies have yet to secure a vendor relationship or to develop internal capabilities for producing the XBRL the SEC mandate requires them to file and post on their company websites. However, any filer betting on a deferment of the XBRL filing requirement for 2011 is taking a very dangerous, and potentially, very expensive bet.

Given the current climate, where investors are demanding that companies be squeaky-clean and über-transparent, can any SEC filer reasonably run the risk of being non-compliant?

--------------------------------------------------

Anne Leslie-Bini

Anne Leslie-Bini is COO of raas-XBRL, a service provider specialized in high-quality, cost-effective XBRL preparation for SEC filers. With a background in Capital Markets, Anne formerly worked as a consultant, focusing on leveraging technology advancements to optimize the business information supply chain. Anne has been active within the wider XBRL community since 2009, participating in a number of international working groups and conferences, and is also well-known on Twitter.

Christchurch, again

2011-02-23T10:52:00.001+01:00

Our thoughts, best wishes, and prayers go out to all in New Zealand, and especially those in Christchurch. Such a beautiful city, with the lovely Avon River, Cathedral Square, and so many individual places to note. The photos just make me want to cry.

But just like Napier after 1931, Christchurch will again be a beautiful city.

Tony and Anne Gibling - wonderful people, Cantabrians, friends, and safe.

I have been to Christchurch many times. In the winter you can see the mountains covered in snow in the distance, while in the summer the hot northeasterly can make the city dry and warm, with wonderful long evenings. While there has been massive damage, and there will be emotional scars to last for centuries, Christchurch is still a wonderful place.

Lasagna, or where are all the XBRL Experts (II)?

2011-02-21T07:49:00.001+01:00

There's nothing like a really good lasagna - well, I think so. So much so that I also like to have it the next day. A nice, thick lasagna with lots of meat, cheese, and tomato sauce. I also like to add onion, and lots of garlic, which goes with just about everything (except creme caramel of course). I've even been known to enjoy my lasagna the next day cold, cut into thin strips. But that was probably too much information.

Sometimes a message can be the same. If it's an important message (with lots of garlic etc) then it may need to be said again. And again.

Which brings me to the message. Over a year ago I wrote "Where are the XBRL experts? I pointed out that one of the first things I said when I became Chair of the XBRL US Steering Committee was that if thousands of companies were going to produce XBRL, then we would need thousands of XBRL Experts, not the 10s or 100s that existed at the time. Well, it is more than five years later, and we still need the 1000s, not the 100s that there are today.

So what is happening? Simply put, not enough.

This year 8000+ companies in the US will provide XBRL versions of their financial statements and notes to the SEC. Over the past two years approximately 1500 - 1700 companies have provided XBRL to the SEC. Last year the first 500 or so provided additional data in the form of Detail Tagged XBRL. This year, all 1500 - 1700 companies will be providing detailed tagged financial statement and notes.

Anecdotally, the vendors are getting stretched for resources.

What does this mean?

Bluntly it means that filers who wait will pay. And they will pay top-dollar for resources that will be learning on the job, just like in those wonderful SOX days.

Does that mean the XBRL Mandate should be renamed the "full employment in the Accounting Profession Act II"? No. But it does mean that filers need to get active in their selection process.

Also, filers need to be asking the basic questions - how much of our time will this take? do we need to learn XBRL (and if so, where is the "real" training)? How much will this really cost?

In the UK there is such a shortage of resources, and some of the software is just coming on stream, that there has been an almost Cairo-like rebellion against the HMRC (Her Majesty's Revenue and Customs - their IRS equivalent). HMRC has stood firm, and has pointed out that they fully expect the iXBRL provided to be a minimum set of data, and that errors are expected this year.

The SEC has made no such statement, although from the very beginning they have said that companies get a two years window of litigation relief.

Still, the message is clear - there simply are not enough experts. There weren't enough last year when I said this (and was chastised for saying it).

Now the Blame Game

So who is to blame? Well, no one actually. With no demand, there has been no groundswell of training available, few people learning (because there are been few jobs asking for XBRL skills) and confusing messages. XBRL International has been too busy trying to keep itself afloat through under-subscribed conferences and flat jurisdiction revenue, to be running real training or adequately supporting real training. XBRL US Inc has been too focused on the taxonomy and other projects, but finally is beginning to push the importance of training.

So back to the message - where are all the XBRL experts? The unfortunate answer is - they don't exist, yet. Searches for XBRL-savy resources will become more difficult. Software and services that limit the amount of XBRL a filer actually needs to learn will be important. Also important will be the amount of time required to actually create the XBRL - because more time will almost invariably mean more knowledge required, and more work.

Companies will face the choice of building expertise internally, or outsourcing to those firms with world class processes and software - and hopefully finding companies that will do so at a fair price. After all, the trade-off will be in the cost (in dollars and time) of training someone to use what can be complex tools and processes, vs outsourcing where the prices/time/quality/effort equation delivers a more cost effective result than building the skills internally.

A secret - in my lasagna there are only two things I use "pre-made"; the lasagna pasta and sometimes I use a jar of sauce as my base. I know my limitations, and creating a great tomato based sauce is beyond my expertise, so I "outsource" that. It's still a very good lasagna, if I do say so...

Old building, wrong solutions

2011-02-13T09:39:00.000+01:00

A friend was telling me about a co-op meeting in his building, quite an old building. The roof needs cleaning. After much to'ing and fro'ing, the building managers came back with four proposals. The first two were to clean to roof. The other two were to put four new windows in the roof that will facilitate future access, for future cleaning and repairs to the roof, oh, and to clean the roof. There's no indication that repairs are needed now, but just in case, here's a proposal to make it easier when they do repair the roof.

It seemed really sensible, until they thought about it, and realised that the requirement was to clean the roof. Certainly future repairs will be required. In fact, as an old building, there is a constant stream of repairs required, the trick being to phase and plan the repairs, not to react to each requirement by trying to solve a different problem.

Now I know the analogy has problems, but it got me thinking about the SEC's XBRL reporting mandate.

In effect the SEC has added a requirement that reporting companies provide a "cleaner" version of their 10K/10Q filings. After all, isn't that one of the core benefits of XBRL, cleaner data, fewer errors, greater confidence that what is tagged equates to a common taxonomy element clearly defined and understood by all.

And now we get to the co-ops options: provide cleaner data in the XBRL format, or replace their existing consolidation and financial reporting software with a new system and environment that will also enable them to provide XBRL to the SEC. Certainly that old building of consolidation reporting probably needs a number of repairs, and I'm willing to bet it is out of date, inefficient, etc etc. Is the new reporting requirement an adequate level of problem to provide the justification and ROI for replacing the roof?

In some cases, absolutely.

In others, maybe a second, or even third (not to mention a first) careful look at the business case would be a good idea.

At the building, they've asked the building manager to come back with a multi-year strategic plan for maintenance and eventual roof repair. They've also accepted one of the two bids just to clean the roof. Seems a sensible approach to me.

CSR reporting made "easy"

2011-02-11T14:43:00.000+01:00

The level of effort required to create a CSR report can seem quite excessive, especially in these times of control over all corporate expenditure. The value proposition must be carefully considered, and frequently the overall cost of the process serves as a real impediment. That is about to change. It took a quantum leap in ease of use, ease of construction, and numbers of users for the "website" to move from "expensive with a dubious ROI" to being an assumed part of corporate reporting.

So to with CSR reporting. The required leap is here or literally just around the corner. The ROI will soon not be judged based on the cost of construction, but on the accuracy and completeness of the content (but that is a different article).

I've been working closely with a start-up in Boston called Gaia-Metrics (www.gaia-metrics.com) which is bringing to market a range of tools designed to assist with sustainability from creation of a report to embedding sustainability into the strategic planning of the business.

At the core of the company are two very smart people - Erik Thomsen (Mr OLAP and former "Distinguished Scientist" for Hyperion) and John O'Conner, former head of the World Bank's program of defining the wealth of countries person who managed the creation of the PPP "Purchasing Power Parity" measure of national production.

They have joined their knowledge to build tools that enable to rapid and very cost effective creation of a GRI content index (for an Application Level C, B or A), with linkages to the underlying documents or sections of documents that contain the relevant content. From here a company can either produce their GRI report, or simply provide a GRI content index.

Gaia-metrics is also working on a range of products specifically designed to bring CSR and Sustainability into the strategic planning and strategic financial planning area of the business.

The pricing is, bluntly, disruptive. And the quality of the product is outstanding.

Some months ago I said there was a revolution in CSR reporting coming. I think this is that revolution.

Visit Gaia-metrics at www.gaia-metrics.com.

5 questions filers should ask about XBRL

2011-02-10T17:42:00.001+01:00

In this, the third year of the SEC’s XBRL mandate, the SEC estimates 8000+ smaller filers are required to provide XBRL versions of their 10K/10Q filings (or at least the financial statements and notes sections). Filers coming to XBRL for the first time are being presented with a plethora of options, too frequently delineated by price. Of course, price is not the only option, and just as a higher price does not ensure quality or worry-free compliance, so too a lower price does not (automatically) determine the quality of the resulting XBRL.

So here we present 5 key questions that should be asked by any CFO, Director of Investor Relations, or other person responsible for the 10K/10Q filing:

How much time will this really require?
How long must we budget for XBRL production after "pencils down" on our filing?
What is the quality of XBRL filed with the SEC using your solution?
How much will this really cost?
Do we need to learn XBRL?

1. How much time will this really require?

The time required is made up of your time: internal preparation; for some products or services, the mapping and element selection, extension element creations and documentation, label linkbase overrides, calculation linkbase debugging (yes, it really is required, regardless of what some people are saying); validation error resolution, etc. Some service providers and software include this in the process or tool. Others use expressions like "we will convert your input file". Ask them exactly how much time it will take to get the "input file" ready for the "conversion" process.

2. How long must we budget for XBRL production after "pencils down" on our filing?

Producing XBRL is frequently a post-all-other-reporting set of steps. Some offerings on the market allow for the creation of the XBRL as a direct output, integrating all SEC report preparation work into a single package. Most other tools require some period of time for conversion, or simply to schedule and manage the process of final version. The recent letter from the FEI to the SEC highlighted the need for additional time post "pencils down" to complete the XBRL. Ask your potential providers how much time you will need to budget.

3. What is the quality of XBRL filed with the SEC using your solution?

Quality of XBRL filings varies significantly. The best measure is the average number of Errors, Warnings, Inconsistencies and Extensions across the full set of fillings submitted to the SEC. Ask you vendor or service provider how filings produced using their software or process compare to the average. If no filings have been provided to the SEC, consider your appetite to be a “beta” site (or near “beta”) for your SEC filings. We have heard of one example where filing agent is stating that the software they use does not create a calculation linkbase “because it is optional.” The calculation linkbase is not optional, and the current lack of accepted SEC filings using this software highlights the potential coming problem for filers making use of that service.

4. How much will this really cost?

Ask the vendor for their expectation of the true total cost. Some vendors have a set price, others have component prices, for example splitting software from consulting. In these cases, check to confirm how much consulting will be needed, and at what price. Also, remember that there could be a trade-off between internal resources fully trained in XBRL (see the next question) and external resources. For offerings that say "Starting at..." confirm what is actually included in that price. You may find that this is the "without consulting or other support" price.

5. How much XBRL do we need to learn?

XBRL is a complex standard. So is PDF. But how much do you need to know about PDF to be able to construct a PDF document? Ask your software supplier or filing agent how much you will need to learn about XBRL. The amount you need to spend learning about a reporting standard (in time and/or money) will increase your costs, and the resources that you will be expending at the critical time in your reporting cycle.

Linking the questions to your options

At raas-XBRL we look forward to answering these questions. We have a long history in the XBRL world, and are proud of what we bring.

Contact us. Ask us the 5 questions. We are ready to answer the questions, and to answer all your SEC-ready XBRL needs. raas-XBRL takes the complexity out of compliance with the SEC’s XBRL mandate.

Ask us for a copy of the “2011 Group 3 Filer XBRL Options” scorecard.

Also, you can download a copy of this as a PDF here.

ISC Governance update - Jurisdictions prepare for their own irrelevance

2011-02-06T19:25:00.007+01:00

In February, the ISC (International Steering Committee) will vote on the first set of changes to the XBRL International governance model. This vote will be to authorize the creation of the Direct Member category of membership. The assumption is that with that first step, the rest of the proposed governance changes can then be voted on. After all, the self-emasculation of the ISC and jurisdictions (while XII continues to milk them of $25,000 minimum per year) is predicated on the existence of a class of member called the "Direct Member".

Lets be clear, I support the creation of the Direct Member category of membership. It is an important step forward, and will help attract those companies that wish to be involved globally, and not limited to individual jurisdictions. That should be plenty to attract companies that currently pay multiple jurisdiction fees (or would if they were members).

As readers will know, the first attempt at ramming through the (completely one-sided) changes to the governance model of XII ran into some opposition - especially once jurisdictions read past the Orwellian language and understood what actually was being proposed. Following that, some important changes in the proposals were made, allowing those jurisdiction members that have been active over the years, locally and at the international level, to continue to participate at the international level.

The revised changes now protect jurisdiction members, and provide a phase-in of the new funding model.

But that is also part of the bad news. Having provided that concession, and changing the phase-in period for the GDP function model, XII gets the best of all worlds:

"We heard, and revised the model, so now you can vote 'Yes'".
Direct Members get in at a lower than previously discussed rate (estimated at $20,000 for the largest instead of $50,000)
Jurisdictions will continue to pay the full rates until a funding threshold has been reached
Jurisdictions cede all their current authority immediately.
The by-laws can then be amended by the new Board of Directors by vote, with the Direct Members votes carrying the day.

Lets take a closer look at the funding changes. Direct members will sign on at $20,000 (the largest companies, I don't know the fee for smaller firms), and for that $20,000 will get a vote at the Member Assembly.

But, as they say, read the fine print. Jurisdiction fees do not drop until XII reaches a pre-defined threshold of revenue from Direct Members. I certainly do not have any issue with that, it makes sense to protect XII's revenue as it transitions. But authority should transition with fees paid.

Jurisdictions will continue to pay the full $25,000. But wait, you say, the GDP model will result in lower Jurisdiction fees. Well, you're quite right, once XII reaches a threshold of $400,000 in revenue from Direct Members, the first reduction in jurisdiction fees will take place - to $20,000 per year. At $600,000, Jurisdiction fees will reduce to $15,000.

And (arms waving in the air while we all sing together "Hallelujah, Hallelujah") at $900,000 the jurisdiction fees drop to $12,000.

Let's put that in context - XII will need to attract 20 of the largest category of members before the Jurisdictions see any reduction in fees. And so if there are 19 direct members, each will be paying less than a jurisdiction for their vote. Nice if you can get it.

And who are these 20? Well, so far XII has an example list of 12 (see blow). But that is only an example list. And those 12, if they are all at the $20,000 level, get XII a little over half way to the first hurdle, and it doesn't include the Big-4. So, if XII gets the Big-4, that would be... ummm.. let me do the maths here, ummmm. 4. Then lets add IBM, SAP, Microsoft, Oracle - that's 4 more. Now how about the other 8, and now we are up to 16.

And the Board of Directors will have the real authority, and will make the real decisions, including re-writing the By-laws to postpone final implementation of the fee reductions for jurisdictions until XII has its Tunis or Cairo moment.

I know, there's all sorts of fluffy speak about the Member Assembly "ratifying" the proposed board, but really, forget it. Oh, and "evaluation the performance of the board" based on the assessment report prepared by the Nominations Committee. Management of XII will then be answerable to only a small cadre of semi-engaged individuals who will rubber stamp what is proposed - after vigorous discussion of course...

Wow, what a deal for XII. I can understand why XII management is fully behind it.

When my jurisdiction discussed the governance changes, I asked what might be the unintended consequences. Being unintended, we couldn't think of any right away.

But then, I'm guessing that the intended consequences are:

Confirmed revenue for XII
That pesky ISC emasculated
Jurisdictions cut out of decision making
Authority vested in a self-selecting board of directors
Revenue leaching from the jurisdictions to the center.

Don't get me wrong, I fully support the Direct Member model - at least a model that includes direct members. But to lump the rest in and call it wonderful is simply Orwellian at best. But, have no fear, I'm confident the jurisdictions will vote for their own irrelevance, if simply because it is easier than actually working through other solutions.

Recommendations:

Jurisdictions should vote "Yes" to the creation of a Direct Member category
Jurisdictions should vote "No" to the proposals that will see them continue to pay while stripping themselves of control over management or the future of the standard.
All jurisdictions should be paying the full jurisdiction fees, or they should recuse (definition #2) themselves from all votes.

Of course, if I was XII, I would push for the changes, then I would ensure that I had 19 Direct Members for a year or two, so I could milk the jurisdictions for $25,000 per year, with absolutely no fear that hey could do anything about it. My funding issues would be solved, and there would be no voting block that could actually challenge me.

Re-post - SEC Interactive Data: Approaching Usefulness in 2011

2011-01-30T11:05:00.003+01:00

This is a re-posting of an article by Dennis Santiago, CEO of Institutional Risk Analytics (IRA - http://www.institutionalriskanalytics.com)

Monday, January 24, 2011

Dennis Santiago of Institutional Risk Analytics is a user of the call report data that is made available from the FDIC, and that is collected in the XBRL format. Dennis however dos not take an XBRL feed form the FDIC. As he has said to me on numerous ocations "Why would I take data in a format that requires me to do more work, more computer cycles, and more cost. The FDIC provides the data in other formats that are much easier for me to consume, so I do".

Yet Dennis has been a "friend" to XBRL for a number of years, always ready to point out opportunities and suggest improvements that will enable him to actually use XBRL data.

He can be reached at dsantiago@institutionalriskanalytics.com or at 310-676-3300

-----------------------------

Monday, January 24, 2011.

SEC Interactive Data: Approaching Usefulness in 2011

By the second quarter of 2011, we will see another wave of machine-to-machine interactive financial data become available directly from the U.S. government. In June 2011, approximately 8,700 companies will begin to file supplementary “xml” files accompanying their quarterly and annual financial statement filings with the Securities and Exchange Commission. XML files can be read directly by computers allowing instant absorption by the analysis programs -- institutional and individual – to evaluate public companies. At its most grandiose, it means that investors, litigants and policy makers will be able to examine and assess the official legal version of these filings as fast as Regulation FD (Fair Disclosure) will allow.

This latest technological jump in financial information transparency is the result of a number of years of work by the SEC. The process included having to develop a specific sub-dialect of xml called XBRL, a many year exercise to turn the free form reporting of the U.S. Securities Act into a workable codified set of data construction rules. Because it blends management statements, the legal requirements of speaking about both “Financial Statements” and “Safe Harbor” discussions, and numerical precision of form-like data enhanced by company unique extensions, it is the most complex attempt of this type to date.

Not that the SEC is a stranger to XML. It originally started the process by requiring the relatively simple Forms 3, 4 and 5 that report on company ownership to be submitted per an XML specification via an online form. Hundreds of thousands of these documents have been filed and machines capable of reading them are able to render who has what at the most complex companies transparent. The SEC is also working on the XFDL specification that will codify many more form types submitted to the SEC.

Prior to this the most complex government financial data collection exercise took place in the parallel universe of the U.S. Banking Act. The FFIEC had brought the reporting of FDIC Call Reports into a Central Data Repository (CDR) and pioneered a three tongued publishing methodology that delivered perfect synchronization among a human viewable HTML file and two computer readable data files, one in xml format and one in CSV format thus covering 99.99% of possible downstream analysis interfacing cases. It set a high standard for all direct government-to public dissemination to follow.

Getting Ready for Prime Time

One of the true tests of a new idea is whether or not it still works when one shuts down all the “experimental versions” of the process. The U.S. government version of this is beginning this phase now. Being analysts who use filings data to assess companies as opposed to XBRL developers seeking to make a living by filing documents with the SEC, we decided the time has come to do a “production acceptance test” of things as we wait for June 2011 to arrive.

Test number one was to ignore all experimental filings data feeds from the SEC and ask the key question, “ Is it possible to find and catalog these documents using only the official EDGAR Accessions file?“ And our favorite follow up government accessibility and transparency question, “Is what it takes to do that sufficiently low hurdle that anyone can do it for free or near free?” This is a critical operational issue because in the end, if it doesn’t work via a truly publicly accessible librarian pathway it isn’t soup yet.

We are happy to report that the answer is yes and yes. One needs nothing more than the SEC Accessions Catalog file to generate a complete table of the URL pointers to every xml filing. It’s implementable as a lights out program and we plan to create a look up utility with the link pointers to all the xml support files that will be incorporated into our IRACorpFilings.com site. Each filing has a set of xml files that together constitute the XBRL submission supplement to the main filing document.

The SEC’s implementation of downstream transmission support does not presently have the CSV check file version of the data alongside the xml as is done by the FFIEC. For one thing that makes it slower to process back into an RDBMS but that’s just an inconvenience and not a show stopper.

What bothers us on this one is that we would like to see the CSV check file accompanying the xml file set – or at least the main xml file with the blocked data elements in it -- because having two machine readable versions of the same output file from the evidentiary source will help immensely for downstream users who need to automate testing for internal consistency in the incoming reports. We recommend that SEC OID look into this as a production feature to come online hopefully by the end of 2011.

We did note that the earliest 1,503 companies from the first and second wave of these filings did something odd … to us anyway. They prefixed the filenames of their xml files with their stock ticker symbols, an identifier that is not an internally verifiable construct – CIK is the real U.S. Securities Act legal identifier and is already in the header of the filing. You have to look up the stock symbol using an external “private” source and we flagged it as something that will become a “human reader” issue later on. There will come a point when the filers reach beyond just the major exchange traded public companies to what we like to refer to at IRA as the remainder of affected SEC Registrants.

It’s not an issue for machine-to-machine reading by the way. Computer programs don’t read and any unique string of text constituting a valid filename is sufficient. The bottom line is that locating usable URL links to XBRL xml file sets in an SEC filing is not a make or break issue requiring any sort of global Legal Entity Identifier. The xml files accompanying each filing could be named “Fred” and can still be successfully targeted by any well programmed computer. The SEC Accession Catalog is dandy and we look forward to our program – and ones written by others -- reading out and data basing the links to xml from these filings as they continue to appear.

Next installment, we’ll talk about what’s in the files themselves and what we think about using them to do surveillance and assessment analytics.

Once you know where the files are the next question is, “Can you do anything with them besides print them out?” The real value after all is in the distillation.

Why did the SEC mandate XBRL?

2011-01-27T15:24:00.000+01:00

Earlier this week I witnessed a very interesting discussion. A room of people were speculating on why the SEC had actually imposed their XBRL mandate. Was the SEC's focus on the "retail investor" just a marketing ploy? If the analysts weren't using it, had the analysts missed the point? What is the benefit for the company creating the XBRL? Who is using the data, anyway? This is all great speculation, but I think misses the point, and the what I believe to be the original driver for the SEC's program.

I am convinced that the real genesis of XBRL can be found in the financial scandals of the early 2000s (and in... hushed silence.... SOX 408).

I believe the SEC has mandated XBRL because they need the data, and that provision of that data to the investor community, while part of their mandate, is and was secondary. It is difficult enough to perform analysis of companies with semi-manual processes, no matter how much data you have. To improve efficiency, you need to import the data, and run it through your analytics before any human sees the data. The FDIC has demonstrated this with their XBRL based Call Report upgrade in 2006 (but that is a different story).

The big difference is that the SEC is not (we all hope and assume) making buy and sell decisions based on the data. they are doing what they are mandated to do: protecting the capital markets. That does not require split-second buy-sell decisions, but careful analysis, identification of outliers, and dare I say it, wondering why companies choose to not be comparable.

So getting back to the main point - the scandals resulted in that wonderful paragon of legislation: Sarbanes-Oxley, also known as the "Full Employment in the Accounting Profession Act". Of course, the world focused on the now (in)famous Section 404. And, after years of documentation, testing and (the dreaded Section 302) certifications, oh, and probably billions of dollars in auditor and consultant fees, internal controls actually are better.

But look a little further. Look at Section 408 (kindly extracted here by The University of Cincinnati College of Law: separate link).

c. Minimum Review Period. In no event shall an issuer required to file reports under section 13(a) or 15(d) of the Securities Exchange Act of 1934 be reviewed under this section less frequently than once every 3 years.

Of course, there's more. Paragraphs "a" and "b" increase the scope to include "Regular and Systematic Review" of a large number of filers.

Basically, Section 408 requires the SEC to review all filers not less than once every 3 years. It also requires that all companies meeting a set of conditions be reviewed every year (a set of conditions that I think would probably cover close to 10% of filers).

To do that, the SEC's manual (or near manual) systems would have had a difficult time coping. Section 408 in effect is the source mandate for XBRL, a mandate on the SEC that requires a data standard that can provide the SEC with computer to computer data for 'easy' consumption by computer systems. Those systems can then perform the pre-processing and analytics, flag up the outliers, and even identify some of those that should be reviewed every year. That, I believe, is the primary original driver for the adoption of XBRL by the SEC.

Protecting the capital markets by rapid and frequent review of filers, enabled by computer to computer provision and consumption of data. Apply that argument, and the requirement for XBRL becomes self justifying. All other additional uses of XBRL become an added value to the economy and investors.

The next question is: What does this tell us about the SEC's probable next steps?

First, get use to XBRL, its not going away. Second, expect the SEC to accommodate filers enough to make provision of XBRL as 'easy' as possible. After all, if the SEC needs the data for their purposes, then if concurrent provision to the markets as critical a requirement.

Finally, if the program is critical to SEC success (which I believe it is) and they will work to make sure filers do not attempt to derail the program, I fully expect the SEC to defer detailed tagging for "group 3" filers. The burden will prove to be heavier than the benefits that they will already be achieving simply from the consumption of the primary financial statements. But these are guesses only...

Detailed Tagging - A descent through Dante's Inferno

2011-01-20T17:48:00.004+01:00

Dante's Inferno is such a cliche, but hey, I'm willing to go there. Come along with me for a quick ride down through levels 1 - 4. The levels are Limbo, Lust, Gluttony and Greed. (there are five more, but for our purposes, we'll stick with the four levels of Detail Tagging - sorry, Inferno). And my goodness, don't they, in a dark sort of way, almost match.

I recently received a flyer offering Year-2 XBRL creation at a very very reasonable price. So reasonable that I simple did not, and do not, believe it. I can only guess that this is:

a loss leader specifically designed to bring in clients and recover the actual cost on other services, or
the filing agent betting that the SEC will defer Detail Tagging for "Group-3" filers.
carefully crafted messaging that will push the hard work back onto the client, so there really is no benefit in using this particular "low cost" provider.

So I thought that maybe the thing to do is to remind people of what Detail Tagging really means. Now, instead of writing something new and fresh all by my self, I'm re-printing something written by Neal Hannon a couple of years ago. At the time it stuck me as the best explanation I had seen, and it remains so in my mind.

As you read his four levels (I've shortened them a little here for speed) consider the amount of effort involved. Is it double the first year's tagging, or more. Especially when we are seeing estimates of the total number of tagged elements jumping from around 150 - 200 to over 2,000 in some cases. And remember that getting to the 2,000 meant reading and sentences, extracting numbers (1, 2, 3) and numbers (one, two three) and then also tagging the relevant explanatory text associated with the numbers. dissecting

Notice that as you descend into the four levels, it is almost like descending through various levels of Dante's Inferno.

So here is Neal Hannon's description of the four levels of tagging.

What is Block Tagging (Level 1)?

According to the SEC proposed rule, Level I tagging means tagging each complete footnote tagged as a single block of text. Block tagging may also include the embedding of HTML tags for formatting purposes.

Using block tagging, XBRL tags are placed around an entire block of text and numbers. The simple process of block tagging a note to a financial statement would involve the following steps:
Select the block of text you wish to tag. This could be the note explaining a company’s application of fair value or their disclosure of investment securities.
Select the text block tag from the XBRL taxonomy and create your text block in your XBRL tagging tool of choice.

Okay, seems simple enough. Almost like being in Limbo - no huge strain, certainly some work to do, but thank goodness there are good tools and service providers out there.

Level 2 Tagging

Level II tagging requires that each significant accounting policy within the significant accounting policies footnote be tagged as a single block of text. The tagging methodology for level II will be the same as level I.

Well, this is a little more interesting. Someone is lusting after a more granular breakout of the accounting policies. That should be do-able.

Level 3 Tagging

Level III tagging should be considered as part of Level IV. As written in the proposed rule, Level III requests that each table within each footnote be tagged as a separate block of text and be combined with all level IV requirements as detailed below. See the Level IV description below for more details.

Now this is getting to be a meal, a very big meal. There are filings out there with more data in the tables embedded in the notes than in the financial statements. This is beginning to look a lot like external help will be required, or a new hire - great, more headcount.

Level 4 Tagging

At Level IV, which is applicable to all companies after their initial year of block tagging, the proposed rule requires companies to deeply tag every footnote. Within each note, any monetary value, percentage, or number will need to have an XBRL tag applied, however, it is not necessary for that level of tagging to exactly preserve the original formatting or layout, because it is assumed that if the level 4 tags are available then the level 1 tags are too.

Here’s what the SEC’s proposed rule says about level IV tagging:

(IV) Within each footnote, each amount (i.e., monetary value, percentage, and number) separately tagged and each narrative disclosure required to be disclosed by U.S. GAAP (or IFRS as issued by the IASB, if applicable), and Commission regulations separately tagged.”

If the company is following IRFS, as issued by the IASB, the IFRS disclosures will also need to be tagged. Companies may also want to expose additional information contained in detailed footnotes that go above and beyond US GAAP requirements.

So level IV tagging means preparing an XBRL tag for:

Each and very number, monetary value, percentage, etc. contained within a footnote;
All GAAP required disclosures; and
Company-specific disclosures that go beyond GAAP requirements

The third item hasn’t been specifically asked for in the proposed rule but preparers may want to include them in their XBRL exhibits.

Now wait just a minute - that's just plain greedy. It takes our lawyers months to craft all those sentences just right, and decide which numbers to spell out (to make them less visible) and which to put as numerics. External help will definitely be required, and more headcount. This is going to be expensive.

With total tagged elements growing from the 150 - 250 range all the way up to 1,500 - 2,500, and having to deconstruct sentences, this is a lot of work.

Summary:

Frankly, having re-read Neal Hannon's discussion of the four levels of tagging, I simple do not believe that we have any real idea of the true cost or impact. I desperately hope the SEC will defer this for smaller filers, or face a serious backlash once true costs are known.

And anyone who buys services that include a quote for year-2 detailed tagging - read the fine print. Look carefully at the wording of the offer. Be careful. Be very careful. The four levels of tagging could well be your descent into the inferno.

------------------------

Note: I'm grateful to Neal Hannon for his carefully considered and written analysis. You can find the entire document here: http://hitachidatainteractive.com/2008/10/15/level-1-block-tagging-vs-level-4-deep-tagging-an-xbrl-illustration/

XBRL Conventional Wisdom Might be Wrong

2011-01-18T15:59:00.000+01:00

I am pleased to present this guest post by Neal Hannon. Neal is one of the foremost thought leaders in the XBRL world having written and consulted in XBRL for over ten years. He is the former XBRL Editor of Strategic Finance magazine, and former Director, Financial Reporting Technologies for the Financial Accounting Foundation. Neal can be reached at nhannon@gmail.com

By Neal J Hannon, WebPro XBRL Consulting (nhannon@gmail.com)

Conventional XBRL wisdom says companies facing the SEC’s XBRL filing mandate should start their planning early and prepare several test documents. They also say that the biggest decision will be whether or not a company prepares their XBRL in house or hire an outsourcing firm. Although I agree that you should plan early and prepare test files, the biggest factor in creating excellent XBRL will not be your choice of in house vs outsource, it will be how well you integrate XBRL seamlessly into your internal close-to-file process regardless of who does the tagging.

The SEC rules for XBRL, spelled out the EDGAR Filing Manual, provide the technical baseline or submission acceptance criteria to have an XBRL filing accepted by the SEC’s EDGAR system. It does not, however, check your filing for accounting errors. Some companies have recently submitted valid XBRL to the EDGAR system that was improperly aligned from company financial information to XBRL submission causing the entire submittal to be technically correct according to all the EDGAR and XBRL rules, but 100% wrong on matching the accounting in the form 10Q.

Hardly anyone is talking about all the hard work companies should be doing on the management processes needed to be in place to ensure that both the correct XBRL to company data choices are made and that those choices are properly applied to the actual SEC filing.

An exception to the rule is International XBRL Chairman Mike Willis and Jon Rowden who recently put the issue very succinctly:

Standardization, defined processes and carefully devised and operated controls are often applied rigorously to general ledgers, trial balances, journal adjustments and consolidation systems to culminate in a group profit figure, a group balance sheet and supporting financial information. Under legal requirements in both the U.S. and UK, CEOs and CFOs take particular comfort …. when they ask themselves “how do I know these numbers are right?” before presenting the results to investors. So far, so good.

Then the disconnection occurs. Unlike the process automation and systems controls that reside in company ledgers and sub-systems, preparing the full financial information – the 10-K filing or the UK statutory accounts reflects a different type of process, a largely manual process. This “Manual Last Mile” reflects highly pervasive manual assembly and review processes that in many respects have not fundamentally changed in decades; only the report format has migrated from paper to electronic documents; most notably Word and Excel. (1)

All companies are responsible for the content in their XBRL filings. No exceptions. Errors in XBRL filings have already caused several companies to file amended 10Q’s. Best in class companies are taking the XBRL mandate as an opportunity to significantly improve their “last mile”. The risks associated with XBRL filings go even further than an occasional amended filing to correct a small error.

In addition to catching validation errors, companies should be aware that the SEC is using XBRL filings to make an initial pass at each company’s accepted submissions. Yes, full liability resides with the HTML version of the filing until the initial two year grace period runs out, but anomalies in the XBRL submission can and will be used by the SEC to trigger additional scrutiny into the HTML filings. No longer will the Enron’s of the world fester in the inbox at the SEC because they simply didn’t have the time to review the submission. Every submission is reviewed by the SEC’s EDGAR analytical software. When the program finds exceptions to normal filings the suspect filings can be singled out for further human review.

World-Class Process Control

So how does a company go about making their XBRL submissions mistake proof? Here are a few guidelines. First, it is wise to have the process that creates the SEC filings run in parallel with the process that creates the XBRL. XBRL service providers who allow companies to tag XBRL in the same environment as the creation of the legal version of the filing have an edge over solutions that add tagging after the official reports are complete.

If the XBRL tagging activity is sent to a third party, plans and procedures must be put in place to check the accuracy of the outside activity. I’ve heard stories about companies whose last minute changes didn’t get into the filing, or worse, items that were corrected on earlier versions and verified were changed back to the mistaken entries. With submissions growing to thousands of tagged elements when second year detailed financial notes are required, the process for making correct changes must be rock solid. Developing a solid relationship with a vendor you can trust is crucial.

Reputational risk for a bad XBRL report is great. Outsource XBRL software companies who promise a very low price should be questioned very carefully about their quality control procedures. How tightly will the last minute changes be controlled? Will you impose a “shut down” period of time when I can’t make any changes? How sure can I be that my changes will get into the filing without error? Will I be charged extra for normal changes? How can you assure me that the changes I submit to you will be accurately applied to my filing? These are just a few of the questions you should ask your outsource XBRL vendor.

Companies selling internal solutions should also be questioned closely on support issues. How often will the software be updated? How will new taxonomies be incorporated into the software? What are the security issues I need to consider? Will the customer service people be available during filing season when needed the most?

XBRL solution companies who deliver quick and accurate rendering of tagged data will be sought after. In addition, companies who provide not just acceptable SEC filings but full audit trails and other verification tools will be providing a valuable, sought after service. Internal auditors, external auditors, audit committee members will all want to see and verify the XBRL choices to ensure that accurate filings have been submitted. SEC filers who install verifiable processes control the creation, verification and submission of XBRL will be glad they did. Stock markets do not favor kindly amendments to SEC filings.

Summary

Conventional XBRL wisdom says plan early and prepare test filings. Good advice, but conventional wisdom falls short. Companies today also need to substantially improve the processes they use in the close to SEC acceptance cycle. Regardless whether a company chooses to in-source or outsource their SEC mandated XBRL filing, they will need to install a solid, repeatable close to SEC filing process that ensures both a technically correct filing and an accurate reflection of their EDGAR HTML filing. Those companies who do not radically improve their controls on this process face a huge reputational risk that could have both legal and stock market implications.

(1) Making sense of XBRL in the US and the UK, by Jon Rowden and Mike Willis, January 13, 2011, Financial Executives Research Foundation

You can contact Neal Hannon at:

Neal Hannon, WebPro XBRL Consulting

Pleasant Hill, Missouri
Cell: 660-888-8526

Office: 816-987-7695
Twitter or Skype: nealhannon

Quality vs price, part 2

2011-01-11T06:39:00.000+01:00


Not a real Pink Flamingo

Giving Campbell Pryde and the folks at XUS the benefit of the doubt (as Anon-6 did in comments on my previous post) there actually can be a linkage between quality and price - where price is the motivation, or where pricing is being used to buy market share (as in the $8,000 fixed price for detailed tagging that I've heard about). Buyer beware.

One year ago XBRL US Inc released a survey of actual effort required for creation of XBRL for submission to the SEC. The numbers were worse than expected. While a Journal of Accountancy article quoted estimates of 30 to 50 hours to create a first-time filing, the XBRL US inc / AICPA survey reported that "57% said it took them over 120 hours to complete their first submission". Detailed tagging will double to quadruple the effort, as people parse paragraphs of text looking for every number, and as total tagged 'facts' explode from 150 - 250 for first year filing, to estimates of 1200 - 2500 elements for detail-tagged filings.

And why does it take so much effort? First because XBRL is a complex standard. Second, because much of the software and services require significant support from XBRL and Accounting experts to create effective, high quality XBRL documents.

There are some very, very good (and very affordable) solutions out there. I know of one that absolutely drops the 120 hours required by a factor of 10 or more, yet still delivers the highest quality XBRL documents for SEC filing. In fact they are doing it already, and have been for over a year's worth of filings for some clients. The results are carefully hidden in the XBRL Cloud report. (Or you can ask me).

But that is for the financial statements and associate block tagged notes, an environment in which individuals are not picking numbers out of text, and then tagging the text as well so as not to lose the context. Parsing of blocks of text for number and associated non-numeric information, and linking the two, is a complex and human labor intensive exercise.

There are service providers and/or filing agents that are saying they will perform the creation of detail-tagged XBRL for SEC submission for $8,000. Along with that, I have heard that there are service providers and/or filing agents that have said "we will take your clients, even if we have to buy them". My take is simple, $8,000 for detailed tagging is buying business. And when you buy business, one of three things happen:

You recoup your actual costs somewhere else, so the client will pay what they would have paid, it will just be hidden in other services. Think "free banking".
You discover that you cannot actually cross-sell alternative services adequately to make up the loss, and you take a hit to your profitability targets. Great if you are a big player, company-destroying if you are not.
Most ominously, you (the service provider) skimp on the total effort taken, knowing that for the first year of detailed tagging there is no assurance requirement, so it doesn't really matter is you provide completely inadequate XBRL for your client to file with the SEC. That is, or should be, Campbell's quality concern.

So filers should take extreme care. $8,000 for first year is a good price for "full service" outsourcing. But $8,000 for up to four times the effort is buying the business, and the filer will pay the full cost somewhere down the line. The filer will pay through additional services, additional consulting support, or by the SEC (and market) kindly pointing out that the information that was provided was, well, ummm... "crap" (but that's a technical term, I'm sure they will use terminology that is more, ummm.... PC).

So how much effort really is required? In January 2010 I discussed this in detail. The only thing I would change is to say that some very good quality software and services have come to my attention since, that radically reduce the effort required.

Cynical interlude: Is it possible that the $8,000 fixed price for detail-tagged XBRL is based on a belief that like SOX, the effort involved with XBRL creation will be seen as so expensive and time consuming for smaller filer that the SEC is forced to provide an indefinite deferral next year? In such a case, that $8,000 looks like a fantastic way to lock clients in, while being confident that you'll never actually have to deliver.

My recommendation - Take extreme care when purchasing detailed-tagging services.

Does XBRL price equal quality?

2011-01-07T17:49:00.000+01:00

On January 6th, 2011, a message was sent to the XBRL US community, over the name of the CEO of XBRL US Inc. A welcome to 2011, followed by a throwing down of the gauntlet to those who think that it is reasonable and dare I say, possible, to build XBRL solutions that are intuitive, inexpensive (comparatively), and that create good quality XBRL documents that meet the SEC's requirements. But before I comment, here are his words:

"1. Focus on quality. There has been a lot of good discussion in the past month about ways to cut costs for small companies that will be filing for the first time this year in XBRL. While it's important to keep XBRL creation as affordable as possible, we also need to ensure that XBRL data is accurate. When service and tool providers are forced to compete on price with no floor on quality, the utility of XBRL data will suffer. If price becomes the driving factor for public companies in selecting a tool or service, then XBRL documents will produce subpar data and investors and analysts won't use it. We can't allow financial reporting managers to believe that XBRL tagging is as simple as passing the SEC validation rules. That is a disservice to the industry, the public company and most importantly, to the investor who is expected to use this data." (emphasis mine)

There are a number of disconcerting statements in this one paragraph, but I'm going to focus on two:

A. Does price really define the quality of the resulting XBRL data? "If price becomes the driving factor... ...then XBRL documents will produce subpar data..." Personally I consider this to be a slap in the face to all the XBRL US Inc member companies that for years have put in the extra effort to create inexpensive solutions that are intuitive, easy to use, and that take the complexity out of XBRL. Of course, the more complex the standard, the more expensive the consultant, and the more consultant time you'll need.

Further, the data does not support this statement. Using the information available at XBRLCloud which I downloaded in mid-December 2010, it looks like being less expensive does not equate to "subpar data".

There are examples of smaller, very much less expensive software, and in fact there are excellent choices from a price perspective. Furthermore based on an analysis of the XBRL Cloud data for one of those very much less expensive choices, the filing created with that software showed on average, lower Error, Warning and Inconsistency numbers than the averages across all filings.

Campbell is right, if we turn the concept around. Quality of information must be the primary consideration. The information in the XBRL documents must be the same as the information in the "paper" filing. But that is not automatically a factor of the cost of the tools or the services, but of the quality of processes and methods of creation and review.

When looking for software of a service provider, filers should ask how they will ensure that the information in the XBRL will be the same as in the "paper" filing. What processes or systems are in place to ensure that, if asked, the filer can confidently say that they made (as required in the SEC's rule) a "good faith effort" to ensure that information is the same.

B. "We can't allow financial reporting managers to believe that XBRL tagging is as simple as passing the SEC validation rules." That is a very interesting way for a standards organization to make a statement. Shouldn't that comment be made to the SEC? After all, if the XBRL passes all the SEC's validation rules, and is acceptable to the SEC, then how was the "financial reporting manager" possibly not doing their job? Is there any requirement in the rule to remove all errors? Even XBRL Cloud has a definition of error type that says "SEC will provide a warning upon submission. Also, might be an underlying XBRL 2.1 problem". Are financial reporting managers now responsible for identifying and weeding out a real "error" from a potential "underlying XBRL 2.1 problem"?

Where the standard is complex, and there is a mandatory filing requirement, it is understandable for companies to say "We've met the SEC's requirement, it passed the SEC's validation." This is absolutely the right answer, provided, as in A above, the information in the XBRL is the same as the information in the "paper" filing.

Finally

A quick read of almost any US newspaper or news website, on almost any day, should demonstrate the pain that American business is still struggling through. I was thunderstruck to read what seemed to me (in my mis-reading?) a suggestion that those companies, especially the smaller filing companies with the tightest margins, should be paying more than what the market will bear, in the name of quality - as if to suggest that there is a direct connection.

At the same time, filing companies do have a responsibility to ensure that the information is "the same", so filers should ask. Expensive does not equate to quality (or there would still be a steel industry in the United States) just as affordable or inexpensive does not mean poor quality. Yet all filers should use care in selecting their service provider or software. Ask about history with XBRL. Ask about the software's pedigree. Is the software being used to create filings, and if so, how is quality assured?

"When service and tool providers are forced to compete on price..." then they are living the same world as the companies that they are selling to, and that is a very good thing indeed.

The XBRL Mandate: Opportunities, And Threats, For Non-Big 4 Auditors

2011-01-04T18:55:00.001+01:00

I love Francine McKenna's blog "re:TheAuditors". One of the best parts frequently is the comments. When she offered me the chance to guest post, I jumped at the opportunity. So my thanks to Francine, and for your reading (and commenting) pleasure:

http://retheauditors.com/
http://retheauditors.com/2011/01/02/the-xbrl-mandate-opportunities-and-threats-for-non-big-4-auditors/

Or you can keep reading exactly the same content here:

---------------

For years now, every time someone complains about “auditor concentration” the stock response from the big firms seems to be “the smaller firms aren’t stepping up”, all the while the largest four firms are auditing approximately 98% of the market capitalization of the largest companies on the major exchanges in the US and the UK. While there is, of course, no single reason for this dominance, the ability to invest in technology and quickly adapt to new standards does contribute to smaller firms’ subordination.

Mandates such as XBRL provide an example of how the largest audit firms exploit new regulation to further market concentration for their advantage.

The SEC mandated that companies provide XBRL versions of public company 10-K and 10-Q filings. This year, 2011, is the “third year” of a three-year phase in. If we’re in the third year, why isn’t XBRL “old news”? Because this year – 2011 – the vast majority of public companies, those with market caps under $75 million, are required to file in XBRL for the first time. The SEC’s estimate is that 8700 companies are required to provide XBRL versions of their filings for the first time in 2011.

How does this “new” reporting standard further encourage audit firm concentration?

Until now, only the largest companies had XBRL on their radar. As a result, XBRL was also on the radar of the largest, global accounting firms. In fact, the Big 4 (and a couple of the next-tier firms) have been active in the development of XBRL for years. So the Big 4 have had more than two years to train a cadre of individuals who understand this new technology and can talk to current and potential clients about it. The smaller firms have been playing the eternal game of “Standards Overload” and catch-up. None of their clients needed to create XBRL (until this year) and, therefore, those firms did not invest in their own knowledge.

If I were a Big 4 business development executive, I’d be taking a very good look at the list of high quality companies – the ones with growth prospects and great audit fee potential – that are not currently Big 4 firm audit clients. New, complex, expensive and time consuming technologies are perfect for FUD: “Fear, Uncertainty and Doubt”. How can I use FUD to poach plum clients from smaller audit firms? I’d make a list of a couple hundred targets for the partners and give them a script. This is what they should say:

“Mr CFO, did you know that you are required to provide your 10-K and 10-Qs in XBRL? You have to create versions of your reports in this complex, expensive and time consuming standard. Are your current auditors briefing you on this requirement?”

And then they should reinforce the fright formula:

“It is very complex, with things like ‘arcroles’ and ‘linkbases’ – things that I don’t understand, but that we have experts that have been working on this for years. Oh, and did I mention ‘detailed tagging’? And, our experts are some of the only people in the world that have actually provided any assurance over XBRL.”

As a Big 4 business development executive, I don’t want the minnows, only the whales. Then the partners go in for the kill…

“We’ve already helped a number of companies just like yours. Maybe a bit bigger, and more complex, but that ensures that our experts will be able to help you through this difficult transition.”

Now the rest of the FUD:

“Of course, your current auditor is a great firm, we know them well. I don’t remember though if they have been involved with this XBRL thing. Maybe you should ask them.”

At this point, it really doesn’t matter if the client does talk to their auditors, the Big 4 partner has already undercut them. He or she has sown FUD and given the prospective client a great additional reason why the Big 4 just might be the firm for them now.

In summary, here’s how it works:

1. XBRL supported by the Big-4 for years

2. Limited participation by other firms

3. Assurance not well defined

4. SEC mandate not well communicated

5. Smaller audit firms might not be ready

6. Big 4 cherry pick the clients they want to poach, using XBRL readiness / advice as a way in

7. Big 4 cement concentration

And that is how something ‘new’, and, in reality, not that complex – and that does not need to be expensive – becomes another tool to expand Big 4 control. At a minimum, the largest audit firms ensure there is no erosion of Big 4 concentration.

But lets take a look at that FUD.

1. XBRL is not complex. Okay, it is a little complex. But we’re not building an airplane here. We’re producing reporting in a different format. There are lots of tools and processes to make it relatively easy. In addition, the SEC has a comprehensive site to help filers.

2. No human in the CFOs office (or anywhere other than a development shop somewhere) should be worrying about ‘arcroles’, and linkbases. They will be built automatically by any decent XBRL software.

3. Implementation of XBRL does not need to be expensive. The SEC’s estimate was $40,000 – $80,000 for the first year. It is very possible to outsource the production of good quality, SEC-ready XBRL for between $6000 – $9000. So shop around. With the right software, companies (smaller audit firm clients) can produce their own SEC ready XBRL for around $4000 – $5000 plus internal labor costs.

4. ‘Detailed tagging’ will be difficult, but is not required until a company’s second year of filing. By that time they will have more experience, and the software will be even better.

5. The smaller accounting firms have not been involved in the development of the XBRL taxonomies, but haven’t needed to be involved. However, there are people in those firms who do understand XBRL.

6. Finally, even the Big 4 have no real idea how to provide assurance that is cost effective, and today there is no requirement for assurance or an audit of the XBRL.

So while the SEC’s mandate for XBRL is real, and yes, all remaining SEC registrants really must provide XBRL this year, it is not a nightmare. Accounting firms other than the Big 4 have every opportunity to help their clients select the best options. Clients – SEC registrants – have a wide range of options, some very expensive and some very reasonable. The software has had a few years to mature and now is really very good.

But here is a real warning: The SEC estimated that 8700 companies will provide XBRL for the first time in 2011. If companies do not book the resources early, and if their accountants and auditors are not ready to give them options soon, this mandate will turn into a SOX-type cost. Companies – and their auditors – should be talking about, and planning for this, now.

2011 first time XBRL creation options

2010-12-27T12:25:00.001+01:00

Waiting for the "Mandate": Pompeii, 79AD

With so many companies being required to create and provide XBRL for the first time to the SEC in 2011, it is not a surprise that I (and others) are being asked about options. After all, while there are something like 8700 companies required to create and provide XBRL in 2011 (according to the SEC), there are still probably under 1000 "experts" at most. As I pointed out in an earlier post, the SEC estimated that compliance with their XBRL mandate would cost between $40,000 - $80,000. Some options certainly do seem to be priced in that range, while others are much less expensive.

There is so much confusion that many companies are saying that they have no plans to create and file XBRL. This baffles me, until I realize that there are some out there that assume that IFRS and XBRL are one and the same. I have had more than one person (who should know) tell me that "XBRL is not an issue because the SEC still hasn't told us when we must change to IFRS". While this certainly is a credit to the XBRL team at the IASB (International Accounting Standards Board), it is just plain wrong. It is remarkable that in May 2010, 49% of public company respondents to the Grant Thornton CFO survey actually said they had "No Plans" to report in XBRL. In November, the numbers were similar. So roughly 50% of public companies plan to ignore the SEC mandate? I very much doubt that.

But it does mean that 50% of public companies are in for a rude shock, and if they do not make their plans soon (very soon) then the costs are going to escalate, and they will be forced to pay the $40,000 - $80,000 for their XBRL.

So, for your reading pleasure (*), here is a very quick breakdown of the main options that first time XBRL filers have for 2011. The list is probably much longer, but for simplicity I've broken it in to these four categories. In a previous post I listed 3 options. In this one, I've added the "integrate" option.

1. Integrate into your consolidation software
2. Filing Agent / Financial Printer “Full service"
3. Third-party s/w, “Full service"
4. Third-party s/w, “Build your own XBRL"

So lets take a closer look at each option.

1. Integrate into your consolidation software

One of the most attractive options has to be integrating creation of XBRL into consolidation [and financial reporting] software, with the ultimate dream being a one-button creation of both the HTML and the XBRL for filing. Some see this as the beginning's of moving XBRL deeper into the operations of the company, eventually becoming the standard for all data exchange (and in some visions for all data management). There are advantages and disadvantages to this approach;

Building XBRL into the consolidation reporting process can streamline reporting, reduce errors, and allow the concurrent creation of standard filings and the associated XBRL.
Cost can be an issue, as this option may require the implementation of significant infrastructure, and in some cases may require a replacement of existing consolidation software. I've always seen this as the "lets use XBRL to drive sales of consolidation software and project management services" option.

2. Filing Agent / Financial Printer “Full service"

All the large filing agents / financial printers have built their own XBRL creation software or are in alliance with providers of such software. The SEC estimated between $40,000 - $80,000. Anecdotal evidence suggests that this is about right for the larger filers. I do not know what it will be for the smaller filers, though I'm hearing lower numbers. I'm also hearing that some of the smaller filing agents / financial printers have or are building their own capability. Those that cannot build there own have told me to their difficulty in identifying and licensing XBRL creation software. The good news is that there are options for the smaller filing agents/ financial printers.

Most SEC registrants are already using a filing agent, and outsourcing production of XBRL is a logical step.
XBRL creation does require agreement on the element selection.
Costs can range significantly between filing agents and ranges of services.
Many smaller filing agents make use of third-party software, so costs can include the cost of a license for that software.

3. Third-party s/w, “Full service"

The past decade of XBRL specification development and adoption outreach has spawned a (very) small industry of software developers who have build XBRL solutions. Some of these solutions are very good, some are very complex. Almost all require the support of XBRL "experts' or consultants. Consulting time required to support creation seems to range between 20 - 40 hours. One major vendor has recently announced services "starting at $7995", and one (mystery solved) is quoting $6500. There are some alternatives that require significantly less effort (and associated cost).

Some software has become very easy to use, and almost intuitive.
Vendors (non-filing agents) can produce your XBRL and provide it to you for you to file directly, or to provide to your filing agent.
Costs range significantly. One factor impacting cost includes the ease of use of the software (and therefore the level of XBRL expertise required).

4. Third-party s/w, “Build your own XBRL"

Again, this same software industry, in some cases, sells licenses for companies to "build your own XBRL". Again, some software is very intuitive, some very complex. Almost all (but not all) of the vendors do offer consulting support. All offer training in the use of their tool. The very best tools make it difficult for mortals to actually ever see the XBRL - sort of like never actually 'seeing' the HTML or the data-level of Word.

Some software has become very easy to use, and almost intuitive. You can build your own XBRL without being an XBRL expert.
Some software will require a certain level of XBRL expertise. Exercise care.
Vendors also provide consulting support.
“Build your own” can increase error rates, and only the first filing comes with a 30-day grace.

If you are a 2011 first time filer, there are many options, and bluntly, your pain threshold is the only thing that limits you. Be it cost pain, time pain, or the pain of learning a standard that is non-core to your financial reporting. There some will argue with me, but I simply do not believe that leaning HTML, for example, is core to financial reporting, so why should XBRL?

The other message is to shop around. From my own observation, some of the very best software and process is also some of the least expensive. This is because the tools have been built specifically with the intent of making certain that the user never sees the XBRL and does not need to learn that language in detail. Again, it is sort of like some of the best website builders (or blog sites for that matter) do not require mortals to actually learn anything about HTML.

I'll follow this post in the next week or two with a list of vendors and services. I do not think I'll be able to provide any detailed pricing information (unless the vendors provide that to me).

* While I have already written on this topic, but thought I would update as the number of options seems to change. Also, it is important to recognize that these are my opinions, and I do not represent this as a complete or 100% accurate description of the options. So I highly recommend you also seek independent advice and guidance, and do not rely on any single site for information. When I produce a table of options, I do not claim that this will be a complete list of options. Again, it will be my opinion. I am and will be happy to update and correct any mistakes.

And again, I would continue to make the same suggestion - book early. By May or June all that will be left will be the expensive options. Non-accelerated filers got a pass on SOX. They won't get the same pass from the SEC on the XBRL mandate. SOX costs were far above any estimates that the SEC provided. XBRL cost estimates are coming in at or even below the SEC's estimated range.

Be warned (again) - any filer that has not booked the resources by May or June should expect to pay SOX type prices, while getting junior level support. There will be a lot of "instant experts" out there.

A little mystery solved?

2010-12-17T16:16:00.001+01:00

Clearly the price of creation of XBRL is coming down, or at least a component of the price is coming down. All sorts of interesting things seem to be happening. Recently an e-mail was sent announcing $6500 for XBRL filing. Sounds like a great deal*. And sure enough, the website promises 4 filings for that price. There are some ambiguities, such as:

Does this include the "HTML" filings?
Who software is being used?
Who is this?

When I attempted to find out, through a simple "whois" search, that came back a blank. So I looked further, and sure enough, there was one name on the entire site: Site designed by "......".

So I decided to do a quick Google search on that names, and yes, found a LinkedIn entry, that matched the name, and location, and - the person works in the internal IT support unit for one of the major filing agents. Could this be an alternative "shop front" for one of the big names, at a lower price, but presented such that there is no danger of existing clients demanding the same low price as they are offering through this other brand?

So I wrote to the filing agent, being curious - "Is this you guys?"

"Nope, never heard of them."

So I sent along the LinkedIn URL.

"Oops, maybe one of our young IT people is doing a little moonlighting. Leave it with me."

So I've been back to the site, and sure enough, the name is gone, and now there are no names on the entire site. Sounds more and more like this is a "shop front" for the big-name filing agent. But I was still curious. It still just didn't seem right. I wanted to confirm, is this the big-name, or not.

So there are no names, but there is a toll-free "800" number. So still being curious, I started chasing that. Well, yes, eventually I arrived at an answer, I think.

It appears to be a long standing member of the XBRL community, and not a separate, lower priced "shop front" for one of the major filing agents: Snappy Reports.

Still, it was a fun little exploration, and for me anyway, I think it is mystery solved.

...That, or they really are messing with our heads...

----------------------

* Note: $6500 is not "cheap" for small filers, and while that is much less than we're seeing quoted by others, and by the big shops, it is still not where the price should be, in my opinion. I remain of the view that XBRL will truly take off once the benefits to the creator of the data are seen as outweighing the costs of creation of the XBRL - costs that currently subsidise a downstream data user's benefits. The good news for smaller filers is that prices are coming down, and that there are simple, intuitive solutions on the market that are more cost effective.

Will XBRL consolidate the filings market?

2010-12-13T21:47:00.005+01:00

Ironically, an unintended consequence of the introduction of XBRL may be a consolidation in the filing agent market. Already the market is dominated by a few key players, with a number of smaller filing agents supporting varying numbers of filers. The "Big-4" players of course are RR Donnelly (now including Bowne), PR Newswire (and their subsidiary Vintage) , Merrill and EDGARFiling. [Okay, I'm human, and I bet I've missed someone very important... you, gentle reader, will no doubt correct me]. Yet there are also much smaller filing agents - almost the proverbial "mom and pop shops" that cater for the needs of small groups of non-accelerated filers, frequently 'local' to the filing agent.

Yet the introduction of XBRL is impacting those relationships. For a couple of years I have had occasional communication with a few smaller filing agents, each time they have come to me asking where they can access affordable XBRL software for their clients.

Recently I've been hearing that some of the large filers are adding additional conditions to the use of their software, in effect further reducing the options for the smaller filers and filing agents. As one small filing agent told me - "it is almost as if XBRL will help them take my clients from me".

The good news of course is that there are options, and exploration will uncover these, for both filing agents and for individual non-accelerated filers creating their own and filing their own XBRL.

Now, this discussion does not relate to those companies that self-file. These companies continue to have access to a wide (ish) range of software tools and processes to create their XBRL. And there are some very good tools out there.

There is a strange irony here.

XBRL threatens to disintermediate the data aggregators. Free, detailed tagged, accurate and timely information is a threat. This will force them, in order to remain relevant, to improve the range of data provided, and the range of value-added services that come with the data subscriptions. The IRA (Institutional Risk Analytics) is a great example. They are taking Call Report data from the FDIC and adding value through bank analysis (and multi-bank analysis), and selling subscriptions to that value-added data.

Unfortunately the filing agents might be using the mandatory provision of XBRL as a mechanism to actually contract the market for filers. The complexity and cost of XBRL creation actually serves to herd the filers into the arms of a smaller set of very large filing agents - the ones that can afford to provide XBRL services, either through self-developed XBRL software or through strategic alliances. The smaller filing agents find themselves with fewer options.

So disintermediation at one end, yet greater aggregation and fewer options at the other. And following the almost "natural order" of things, would it surprise me to see further aggregation?

With Friends like These...

2010-12-04T15:45:00.003+01:00

As we in the northern hemisphere enjoy the earliest days of (dare I say it) WINTER, a good friend in Wellington, New Zealand, sent this today. He noted that we are "enjoying" 3deg Celsius (37f) with clouds, rain, and yesterday a little snow.

He just wanted to let me know that it was 24deg Celsius (75f) there, and to send along this photo that he took, minutes before.

Or as his e-mail said, "Wgtn was 24deg, calm, and sunny today. Rather nice. Since the internet insists it is miserable weather there, I though this would cheer you up!"

With friends like these...