Laughing at the High Priests

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

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

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

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

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

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

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

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

Yet, how prophetic.

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

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

Implications of XBRL on Audit firms

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

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

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

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

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

Challenges

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

Resources

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

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

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

Software

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

Standards

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

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

Costs

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

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

The Market and tolerances

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

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

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

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

What to audit in XBRL

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

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

The list goes on...

What is XBRL

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

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

XBRL gets "competitive"

In the past week both XEU (XBRL Spain), XUS (XBRL US Inc) and XBRL Japan have announced "competitions" with prize money for the winning entries. Initially I was quite uncomfortable with these competitions, as they almost seem like a great way to get some good ideas into the public domain – crowd sourcing if you will, from people without the contacts or economic ability to bring fully fledged products to market.

Maybe I'm a social Luddite, but I've always been uncomfortable with the idea of "crowd sourcing" - get bunches of people to donate their time and brain power, only to have a very few actually be able to apply the capital required to exploit those ideas.

XBRL US is offering a single $20,000 prize, while XBRL Spain is offering 5,000, and XBRL Japan is offering Y100,000 in prizes.

The best ideas will win (and will receive prizes that are of a recognition level and not product level), the second best ideas (and third, etc) will still be great ideas, and will now be available to anyone with the pockets to actually take to market. It sounds like a wonderful way to pick and choose from the best and brightest, and to then take their ideas to market.

Yet on the other than, all participants know exactly what the deal it. There's no exploitation.
Campbell Pryde of XBRL US Inc recognized the difficulty in coming to the right balance, but said that all entrants thus far were made aware that their  entries would then be in the public domain, hopefully as building blocks for a new generation of software and tools exploiting XBRL data.  He also said 

“The intent of the competition is to stimulate interest and awareness in the developer community about the opportunities available to them with XBRL data.  The more open source applications available, the more ideas generated and the more applications companies can build on.  All this leads to quicker and broader adoption among investors, analysts, and other users of corporate financial data.”

Great ideas will be given an airing. Some will make it to market, others won't.

And the individuals who present the ideas will be demonstrating their knowledge of XBRL, and demonstration that they are innovators. Best of all, they will be showing their skills and knowledge to a plethora of potential employers, to the securities industry, and to the wider XBRL community.

It has been my belief for quite some time that XBRL success requires two things; 1) a pool of XBRL data that is publicly available for use (which is now the case with SEC filings - but that was also available when the FDIC's program went live in 2006) and 2) the software to exploit that data. That software did not exist and was not developed after the FDIC program - and if it is not developed now, then the XBRL dream will suffer.

So in the final analysis - well done to both XBRL Spain, XBRL US and XBRL Japan for initiating these competitions. Soon there should be some pretty fantastic examples, open source all, of just what can be accomplished with the XBRL data that is available today.

Breaking News: Time for a change?

First, congratulations to Mark on his new role, and our wishes for all possible success. Next, congratulations to "the new boss" (Campbell Pryde) who I am confident will make the lie of the "Who" song.

This is a great change, with leadership that understands the technology at as deep a level as possible, yet with the skills to enunciate the value proposition. Add to this the possibility of changes to membership options, and I think we might see and "XBRL US Inc" that I'll be happy to go back to calling "XUS".

Unfortunately this will not solve the funding crisis, and sadly we will probably see total staffing numbers at XBRL US Inc shrink. But then, I guess that comes wtih the job...

The best news of course will be the opportunity for a "fresh start" and for XUS to get back to its roots and mission.Some of the needed changes will probably not look good, but I'm confident that new (known) leadership will deliver the change needed, and will be able to reach out to the wider XBRL community, reinvigorate the membership (and even focus on members) while also progressing the Labs and other initiatives.

In addition, it can only be good for the international adoption of XBRL, to have the largest jurisdiction, hopefully, on the way to growth and prosperity. I expect the range of changes will also improve the financial situation. It is worth noting that even though as a US Not For Profit, with requirements of transparency, the Form 990 does not have to become public for over a year after the close of the period. So if there was a hemorrhaging of money and members, we might not knowuntil probably February or March next year, and then for 2009 only.

Hopefully the years of a flawed business model will be behind XUS, and with new leadership and new direction, the future will be nothing but success after success.

Good luck, we're behind you all the way! (Yes. really!)

So the fizzy white wine stays in the bottle for now...

Well, it looks like we were all enthusiastic just a moment too soon. No sooner does it look like a XBRL in the United States was making a huge leap forward - at least in terms of mandating - then the rug gets pulled out from under. It seems the "Data Standard" amendment has been dropped from the financial reform legislation.

And through the weekend I actually thought that the biggest danger was a stalling of the whole vote due to the illness of Senator Byrd (the longest serving member of the US Senate - the "Upper House" of the American congress). Senator Byrd (now deceased as of 3am US time this morning) was a **Republican** (No he wasn't - thank you Bob for pointing that out so quickly, and my apologies to all who read this and believed my error. Here is from CNN "Byrd, a nine-term Democrat, was known as a master of the chamber's often-arcane rules and as the self-proclaimed "champion of the Constitution," a jealous guardian of congressional power.")  and one of only 4 who were voting with the Democrat on the overall law that was being propose. With him being taken ill, the worry was that the law would stall if there were not enough Republicans voting in favour.

With his death, the Governor of West Virginia (his state) will select his replacement to serve out the remainder of his term in office. As the Governor is a Democrat, we can expect a Democrat to be appointed, yet there will still be a delay.

Well, that was my worry, until the e-mail from the CEO of XBRL US Inc. Pity.

Then again, as pointed out in his earlier e-mail, there was still some way to go through the process of "reconciling" the two versions of the law that were before Congress. The American system requires a single version of a law to be passed by both the House of Representatives (the "lower house") and the Senate (the "upper house"). This makes for an arcane world of deals and counter-deals. Swapping favours and influence, and in the process buying votes - both in Congress and from the electorate. It also allows various constituencies see how hard congressional representatives are working for their various constituencies.

It seems in this case that the XBRL constituency was trumped by something bigger.

So the fizzy white wine stays in the bottle for now, and Moet stays in the cellar. Hopefully we'll see both bottles come out again soon.

"Bugga" is about all I can say

A great step forward for XBRL in the US

This e-mail came from XBRL US Inc yesterday (June 26). I'm certain that almost everyone in the XBRL community has seen it. Clearly this will be a great step forward for the adoption of XBRL for business reporting, certainly in the United States.

When this passes and is signed into law, the entire community should collectively open a bottle of fizzy white wine. When the OMB (Office of Management of Budget) says that the Data Standard is XBRL, then the entire community should collectively open a bottle (or two or three) of Moet (or better).

A huge amount will have been accomplished, and the leadership of XBRL US Inc will have a tremendous accomplishment to be proud of.

Basically going forward all recipients of grants from the US Federal Government will be required to report in a "Standard Data Format" - defined in such a way as to make XBRL the logical candidate for such reporting. The opportunities for improving the transparency of reporting of grants expenditure will be fantastic, and could lead to the US government and people actually knowing how their money is spent.

===

Dear XBRL International Members:

Just a few hours ago, 12 amendments to H.R. 4173 (the “Dodd Bill” for financial regulatory reform) introduced by Rep. Darrell Issa of California were approved and added to federal legislation.  All 12 call for the use of data standards for a wide range of financial regulatory reporting.  The criteria for data standard is that drafted by XBRL US at the request of committee staff and used in previous bills HR 2392 and SB 303:

The data standards required by subparagraph (A) shall, to the extent practicable, –

(i) incorporate a widely accepted, non-proprietary, searchable, computer-readable data format;

(ii) be consistent with and implement—

(I) United States generally accepted accounting principles or Federal financial accounting standards (as appropriate);

(II) demonstrated best practices; and

(III) Federal regulatory requirements;

(iii) improve the transparency, consistency, and usability of business and financial information;

(iv) ensure interoperability and appropriate reuse of information;

(v) reuse, enhance, harmonize, and integrate existing standards as possible and appropriate; and

(vi) be capable of being continually upgraded to be of maximum use as technologies and content evolve over time.

...

===

I hope nobody but me remembers ADA, or ever watched "Yes Minister".

Passage of the bill will be a great step forward, but it is only the next step. Endorsement by OMB will be an even greater step, but it is only the next step along the road.

ADA was mandated for all programming in DoD (Department of Defence). Unfortunately companies writing programs to run on DoD computers had an option called a "waiver". Those companies spent untold time and money writing waivers, then getting on with writing the COBAL, PL/1, C etc programs that they were writing. After 10 years of mandatory use of ADA, the DoD quietly scraped the requirement.

The XBRL community can learn a lot from the ADA experience. Some basic lessons include:

• A mandate does not equal adoption
• Without enough skilled resources, it was too expensive to implement
• Waivers provided a way out, and were used extensively
• The "Sir Humphry"s of the world always get their way, so make sure their way is your way (or the other way around)
• Continue to look for successes, like the recent AGA report on Creating an Interactive Single Audit Database

None the less, this is a great accomplishment and congratulations to XBRL US Inc for helping get this through Congress.

It is time for XII and XUS to "eat their own dog food"

It is a great expression: "eating your own dog food". It conveys that wonderful idea that if it is good enough for others, it should be good enough for you. It is also a litmus test of the validity of a concept or idea. Imagine if Oracle used SAP for its internal and external reporting, supply chain management, etc. Imagine if doctors refused to take the drugs  they prescribe.

Imagine saying that something is easy and will improve transparency, yet then not using it yourself. Wow, imagine already being required to provide all that information in another format, lets say an IRS Form 990, yet not even bothering to provide the same information in the standard that you create. Not even to prove that you can.

Come on guys, we keep telling the markets that XBRL (eXtensible Business Reporting Language) will deliver significant business reporting benefits to the creators of the reports, and to the consumers of the reports in XBRL. How long will it be before the markets question the validity of our assertions that this will improve business reporting efficiency, effectiveness, quality and speed, if two of the key groups advocating for XBRL do not (cannot?) even do it themselves?

The last time XII produced their financial statement in XBRL was for the 2004 results. So, did XII find it too difficult? I hope not; it is their standard. XBRL US inc has never published their results in XBRL. And doing it once, they can both look forward to an easy second, third etc round of XBRL creation, needing to do little more than change the contexts and the numbers next time.

Isn't it time that XBRL International (XII) and XBRL US inc (XUS) actually ate their own dog food?