SASB’s XBRL Taxonomy; Stepping forward by stepping sideways

SASB’s XBRL Taxonomy

Stepping forward by stepping sideways

The future of business reporting is incomplete without a significant increase in the quantity and quality of ESG reporting, ultimately mandated by regulators and included in the scope of the external audit. For ESG data to be of an auditable quality, a common standard is required, with a level of rigour equivalent to IFRS or US GAAP standards approved by the FASB (and for the US government, GASB). To meet the need for higher quality ESG (Environmental, Social, and Governance) reporting, the SASB has just released an XBRL taxonomy version of their standards.

Is the SASB XBRL Taxonomy an extravagance, a step sideways, or in a strange way, a step forward for ESG reporting? Is an(other) XBRL taxonomy required, and if so, why and what benefit will be achieved (and for whom)? After all, there is already a GRI XBRL Taxonomy for Sustainability reporting.

The foundations for effective ESG reporting are being laid, but there remains a lack of compulsion that will be required to force companies to deliver.

Instead of another XBRL Taxonomy, I would recommend the SASB (VRF) put their energies and limited resources into:

1. lobbying the SEC and regulators to require ESG reporting in quarterly and annual reports, and
2. request the SEC to provide further guidance on how ESP information should be provide under Reg S-K, including the 2020 “modernisation” of the Rule, and
3. lobbying regulators to demand that ESG information be audited, and
4. developing course materials to enable universities to train young accountants to audit ESG information, and
5. developing CPD materials for established professionals to audit (including Partner review training) of ESG information, and
6. work with the data aggregators to develop easy to use reporting tools to analyse ESG content.

Sustainability data will remain “nice to have” until it mandated and it is audited, and any number of XBRL Taxonomies will not make that happen.

The importance of SASB

ESG (and Sustainability) reporting is not new, although its importance has increased through the pandemic and the climate crisis. When the Club of Rome released their “Limits to Growth” in 1972, there was little understanding of sustainability as a national and business priority. Over the next decades, that changed, and by the turn of the century, the first ESG and sustainability reporting standards were introduced.

The problem with almost all sustainability reporting standards is the lack of auditability of the reports, and the lack of accounting-standards level clarity or exactness of definition. It was almost impossible to ensure like-for-like meanings of the reported sustainability or governance concepts. Most standards were built with the PR department in mind, not Finance and share market or Compliance Reporting.

The SASB (Sustainability Accounting Standards Board) was established in an already well-populated ecosystem of competing standards for ESG reporting. However, SASB is the first standards organisation of develop a set of sustainability and ESG reporting standards to the same level as traditional accounting standards. The IIRC (International Integrated Reporting Consortium) was founded in the UK to pursue the development and introduction of the “Integrated Report” to improve the quality of business reporting. The SASB and IIRC have merged to create the Value Reporting Foundation (VRF).

For a standard to be successful it requires three market drivers. First a need must be satisfied that exceeds the cost of implementation – a compelling commercial case for implementation. Second there must be natural users or ‘consumers’ of the product of the standard. Finally, there must be regulatory drivers that compel the recalcitrant to implement the standard.

Until now, Sustainability and/or ESG reporting has lacked the third of these, in that sustainability reporting has been optional. This resulted in a plethora of standards (the GRI, SASB, CDP, UNGC, etc)* each providing optional levels of compliance and limited, if any, assurance mechanisms. We shouldn’t forget the “Accounting for Sustainability” (A4S) initiative from the Prince of Wales, or the Task Force on Climate-related Financial Disclosures (TCFD) initiative.

All of these standards are voluntary. This means that Sustainability and/or ESG reporting have been, by the very option nature of such reporting, an opportunity for marketing and PR to put forward the best story, especially if it is not the whole story.

SASB’s standard provides one of the first ESG standard with the potential to meet regulator’s needs for an auditable and consistent content definition. Therefore, when the third driver is in place (regulatory mandate), the SASB standard is ready to be used to provide the level and quality of data mandated by regulators.

The XBRL Dream

In 1998 (long before the first iPhone), a group of accountants came up with an intriguing idea. What if they were able to create an XML based standard for the “tagging” of financial information, so that all consumers of that information would know exactly what each piece of data actually meant. Of course, it was not so easy, as any financial and later “business” “fact” requires an awful lot of contextual information to give it actual and consistent meaning. So the XBRL (eXtensible Business Reporting Language) Standard was born, extending the XML standard considerably.

With XBRL, it was possible to state with certainty that one company’s reported “Cash and Cash Equivalent” actually defined the same accounting concept as another company’s reported “Cash and Cash Equivalent”. In addition, the “eXtensible” part of the standard meant that if you require a more granular concept than already exists in the taxonomy, you could add a new element.

Business reporting would be simplified, consumption of like-for-like information would transform analysis, and companies, through the (modest it was hoped) use of extensions elements, could “tell their story their way”.

Now it was simply a matter of developing a taxonomy of business terms, and convincing software makers to develop the tools required to support what had become a very complex standard.

The XBRL Reality

Unfortunately, the complexity of XBRL meant that for the first decade, all three of the major drivers for adoption were missing. There was no economic case for developers to create software or for companies to spend their money to produce financials and business reports in XBRL, because there were no consumers of XBRL (and little or no software to consume and use the XBRL). Finally, no regulator had mandated the provision of XBRL versions for key reports. Certainly, there were niche software houses that bought into the dream of XBRL, and a few companies that chose to produce XBRL. Some of the financial reporting aggregators even said that they could or would support XBRL.

In 2009 the SEC’s mandate for the provision of parts of the 10K (annual reports) and 10Q (quarterly reports) in XBRL came into effect. But they have yet, more than a decade later, to mandate that the XBRL content be audited, nor have the expanded the coverage of content adequately to the full reports.

Across Europe, regulators have mandated XBRL for everything from company reports to insurance solvency reporting. Companies House in the UK receives XBRL version of company financials from all companies. But as these files are, in effect, produced from templates, the dream of high-quality business data has not been met.

XBRL remains a cumbersome and limited standard, and one that is used only (other than very few exceptions to prove the rule) by companies that are required to produce reports in the XBRL format. There remains virtually no voluntary uptake of a complex and expensive standard that delivers unaudited data for which there is no consumer driven demand.

The best-mangled metaphor I’ve ever seen was used to describe XBRL. It is “like using a dinosaur to crack a walnut”.

Implications of the SASB XBRL Taxonomy

Now SASB has, with the assistance of one of the Big-4 who has supported XBRL from the very beginning, developed an XBRL Taxonomy for their reporting standard. This is good news. It will now be possible to “tag” the ESG data in XBRL for automated consumption by XBRL capable regulators and reporting systems. 

Furthermore, when a company tags an ESG “fact” in XBRL, consumers of that data will know that the underlying meaning and concept associated with that “fact” is exactly the same and the underlying meaning and concept of that “fact” reported by any other company using the same taxonomy and taxonomy element.

SASB’s XBRL Taxonomy will neither derail nor spur ESG reporting

Realistic and meaningful ESG reporting will not happen until regulators mandate not only the reporting but that the information is audited, and a dedicated XBRL Taxonomy will have little impact on the uptake of ESG reporting.

Only then will reporting companies provide information that investors can trust (Google “Greenwashing”).

The provision of ESG information tagged in XBRL (and audited) might be an improvement. However, the XBRL standard is so old and cumbersome that only a limited number of people will ever have the skills required to exploit data provided in native XBRL.

If SASB really wants ESG adopted…

SASB (or the Value Reporting Foundation as it is now called after merging with the IIRC) is probably the best standard for real, auditable, ESG information. If they really want companies to be providing ESG reporting, and using SASB as “the standard”, I would recommend that instead of playing with the Big-4 and XBRL, that their energies go into the list of activities listed at the beginning of this arlticle.

I would also challenge for any reader to add to that list. What else should the SASB/VRF be doing to encourage the uptake and use of ESG reporting?

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

*  “GRI, SASB, CDP, UNGC”. These are four of the multitude of ESG “standards”: Global Reporting Initiative, Sustainability Accounting Standards Board, the Carbon Disclosure Project, and the UN Global Compact.

The Author: Daniel Roberts served as Chair of the XBRL US Steering Committee in 2005 and 2006, a time when XBRL US was working closely with the SEC to advance the use of XBRL for corporate disclosures. 

Saving the SEC’s XBRL Program

Some years ago I promised myself that I would not write about XBRL again. I’m breaking that promise. eXtensible Business Reporting Language was a major conceptual breakthrough when it was first developed in 1998. But that was over 20 years ago, and XBRL has progressed little beyond a regulator-demanded user-unfriendly standard with little (voluntary) uptake by report producers, and less evidence that anyone actually consumer and uses native XBRL. There are financial analysts in university (and possibly beyond) who were not born when XBRL was developed. 

At the heart of displeasure with the SEC’s XBRL program at the core of XBRL, the “eXtensible” concept, or as the XBRL community liked to sell the concept, “tell your story, your way”. Thankfully there is a “simple” fix that will save the SEC’s XBRL program, save filers time and money, enable to (almost) pain-free expansion of the program, and increase the likelihood of uptake by consumers of financial information.

Unfortunately, the complexity of XBRL has been a problem from day one. My all-time favourite condemnation of XBRL goes all the way back to 2008 when someone said that XBRL was “using a dinosaur to crack a walnut”.

But first some background:

There are uses for XBRL and XBRL-type reporting technology, but if you are considering going down that route, beware.

The idea was simple; each piece of information in a financial statement/report could be tagged in such a way as to enable the machine to machine communication of financial and business information. The use of a common taxonomy of elements ensured that a piece of data (a “fact”) tagged would mean the same thing to any consumer of that piece of data. Anyone producing financial or business data that was to be shared would be able to ensure that the consumers of that data would know exactly what they were consuming.

Soon, the FDIC (Federal Deposit Insurance Corporation), the US banking regulator, had incorporated XBRL into the Call Report process, ensuring as early as 2004 that all reporting banks in the United States were reporting using a common taxonomy.

All “successful” XBRL implementations share one key factor; they use “closed” taxonomies and do not allow filers or providers to add extension elements.

Today, around the world, XBRL is required by various regulators are the standard for data tagging of financial statements. And in virtually all of those implementations, from the UK to Singapore to Japan and the Netherlands (to name a few), financial statements are provided to the accountant or service provider who then converts Excel into XBRL and then submits that file to the regulator. The regulator then gets to convert the XBRL back into Excel for analysis. Why? Because XBRL is complex and resource-hungry, where the equivalent benefit can be achieved from a spreadsheet.

In the US, the SEC (Securities and Exchange Commission) requires that financial statements in the 10Q, 10K and a range of other filings, be filed in HTML and in an XBRL version. The SEC is also moving to require “Inline-XBRL” filings. Unfortunately, the SEC’s XBRL program remains a burden for which there has simply not been adequate, or even partial, buy-in from the producers or the consumers of companies SEC filings.

Fundamentally the SEC’s XBRL program has been a failure.

Producers of filings to not like it, and consider the production of XBRL to be costly and time-consuming. Don’t take my word for it, read the recent article following the SEC’s roundtable on short-termism from July 2019.

In listing the bullet points from the discussion of how to improve the 10Q process, the final bullet point stated: “And then, what about XBRL? (It was noted here that many issuers find XBRL expensive and very time-consuming and highly doubt its usefulness, not to mention that the SEC has just increased the XBRL burden for companies. Another panellist quoted an issuer as describing it as the “worst part” of the process.)” (emphasis mine).

The SEC itself is a lukewarm user, and if they have ever announced that it was the XBRL that allowed them to spot a case of fraud or financial misstatement then I missed that announcement. 

Data providers such as Yahoo Finance do not bother to provide a “download XBRL” button, and if you want the data, download it in Excel. If you want to XBRL, you’ll need to go to individual filing companies’ websites and download the files from their Invest Relations page, or you will need to go into the SEC’s EDGAR system and search on the company and download the XBRL from the SEC’s site.

While iXBRL (inline-XBRL) will be a boon to consumers of XBRL, at least those reading documents through their eyes, and wondering if the XBRL-tagged facts actually match the information on the printed form, this does little or nothing to solve the main problem; the difficulty of producing the XBRL in the first place.

The “FIX”

The US GAAP Taxonomy, the “dictionary” of allowable tags for financial statements contains over 18,000 elements. Or, as the AICPA said, “The US GAAP Taxonomies contain over 15,000 elements representing commonly reported financial concepts for US GAAP financial statements”. That was a number of years ago. But really? 15,000 “commonly reported”. And this number does not include the plethora of company-specific extension elements that are created every year. 

Fundamentally, every significant implementation of XBRL for the past 15 years (as long as there really have been any implementations of XBRL) has been based on a “closed” taxonomy in which filers are not able to create company-specific extensions.

To fix the SEC’s XBRL program, they should consider the following:

1. Create a limited-set US GAAP Taxonomy. The original estimate was that at fully functioning IS GAAP taxonomy could be created with 4500 elements. While that number clearly is low, it should be possible to create a taxonomy that allows companies to report all “common” concepts in under 10,000 elements.
2. Where companies cannot find the “perfect” fit element, they should use the closest element, and/or revise their reporting to ensure that they are reporting information that is common to their industry of to US GAAP principles.
3. Encourage the development of “templates” for reporting. This will enable companies and service providers to produce XBRL as standard output, saving time and cost, especially for smaller filing companies.

Yes, this sounds simplistic, and it probably will not happen. 

Why not? Unfortunately, there are drivers for the retention of the complex system of company-specific extensions. Simply put, too many jobs are on the line. 

The FASB maintains a team whose job is the “maintain” the US GAAP taxonomy. This includes the annual release of an updated taxonomy in which new elements are added to cater for “common” company-specific extensions. Companies providing software will see their market disappear if the reporting process can be simplified. And of course, if XBRL is actually simplified, then it will become clear that almost anything that can be done with XBRL should be possible with learning engines and (gasp) Excel.  

After all, XBRL has been around for 20 years. That is 20 years of Moore’s Law improving the speed of processes, 20 years of improvements in systems and analytic capabilities, and 20 years in which IA and learning engines have, if not matured, then at least become mainstream.

It is time to fix the SEC's filing program. Fix it, or abandon XBRL.

Visualising government benchmarking data

The New Zealand government has released their most recent Benchmarking Administrative and Support Services (BAAS) data. What is interesting about this data is the ability to analyse spend, not at a highly detailed level, but certainly in more detail than previously possible. The information is provided in Excel. What is interesting is what you can do with the Excel data for analysis and, better, display of information graphically, to derive meaning.

I highly recommend taking a look at how this, relatively high-level, information can be presented.

http://zyanbass.appspot.com/

 

 "The New Zealand Treasury runs an annual benchmarking survey across 26 Government agencies in order to gather information on the cost, efficiency, and effectiveness of administrative services delivered by a sample of the state sector. The most interesting portion of the BASS data is about BASS agencies's spend on ICT and that's the data this website (mostly) explores."

 

Before discussing they need for a more detailed taxonomy, I'll make the following observation: The information is available in Excel, against a single set of line-item names, and columns for periods and spend. It is simple, it is easy to use and import, and absolutely ZERO specialist XBRL knowledge is required to import, analyze and gain meaning from that data. There is much to learn from such initiatives.

 

The need for a more detailed taxonomy

 

The need for a more detailed taxonomy of ICT and other government expenditure

Financial reporting and analysis provides value only when used to compare performance against either targets, benchmarks or competitors. Fundamental to the ability to perform effective analysis is the presumption that all reported line items are equivalent across reporting entities. Equivalence of meaning is the critical point, and without adequate definitions, there will be no clarity. Therefore, there needs to be an agreed taxonomy of reporting terms, at sufficient levels of deconstruction to allow the reporting of exactly the information that the entity wants to report, at the level of detail they want to report, linked to a definition that is accepted as the only definition for the reported level of information. 

 

Granularity is also required to ensure that there is minimal overlap between reported items, and little opportunity to report items in one of multiple categories or line items. When considering a Balance Sheet (for example) the first and most obvious question may be "is the reported item an Asset or a Liability?" It cannot be both, or either. Cash is not a liability (unless you are a bank), as is Property Plant and Equipment. Likewise, Accounts Payable and Long Term Debt are liabilities. There is no overlap, and therefore the information, unless you are Worldcom, should only be reported on one side of the ledger of the other. 

 

How does this relate to BASS? While there are over 800 line items in the BASS spreadsheet (many are either summation or calculated lines and not actual reportable line items) there can be overlap or alternative interpretation of how and where information will be reported. This reduced inter-agency or entity performance and expenditure comparisons. 

 

Too often interpretive differences in the meaning of scope of potential meaning of a reported line item can lead to multiple entities reporting the same line item, while defining the detailed content differently. For example one agency could include a software charge as 'Software' while another records it as 'Outsourced' because, while the agency licences it, it is only used to enable an outsourced service. Neither are necessarily wrong. Such use of a common element with slightly different interpretation increases the complexity of comparatives, and increases the amount of manual intervention required to gain meaningful insights from what is theoretically the same information. 

 

Any taxonomy does not need to be complex in and of itself, but it does need to represent an agreed set of line items and associated detailed descriptions. The ICT section of the BASS reporting framework have approximately 125 line items, many of which are summation items. 

 

What is required for effective reporting is not an ever expanding list of potential line items against which to report, but a set of line items elements with very clear definitions. For example, the US-GAAP "Generally Accepted Accounting Principles" taxonomy (in XBRL, which I do NOT recommend) has over 18,000 possible reporting elements, growing every year. In addition, companies can add additional custom items, only increasing the complexity and reducing comparability. Imagine if each BASS reporting entity could choose to add line items. 

 

Instead, keep the list as tight as meaningful, and clearly define the boundaries of each item. In this way is it is possible to reduce the ability to select from any of a number of items depending on your individual interpretation. The benefits? Simplified reporting, greater clarity, and easier comparability between entities, and greater value in the information reported and analysed.

Why Worry?

In 1985, Dire Straits released their their iconic album Brothers in Arms. While there are so many great tracks on that album, I keep finding myself singing "Why worry? There should be sunshine after rain, these things have always been the same, so why worry now". (You can listen in here)

So, sunshine after rain.

What on earth does this have to do with XBRL? 2nd quarter filings are flowing in to the SEC, including the associated XBRL versions of the filings. And what is notable about these filings? These filing represent at least the ninth XBRL filing for all SEC filing companies other than those spared by the inability of the IFRS to create a taxonomy acceptable to the SEC (although that really is a different, sadly disturbing, topic). That means that all filers have now left their period of "litigation relief".

The SEC was, of course and as always, very clear - there is no mandated requirement for XBRL to be audited. After all, Chairman Cox was famously worried that requiring audit or XBRL would spell "crib death" for the XBRL project. How right he was, yet how wrong at the same time.

After all, who would be supportive of the additional burden of having to pay for production of XBRL, and then have to pay for an audit of the XBRL. 

This left the SEC with a small problem when it came time for the Final Rule. How to require a new reporting format from filers with one of the stated purposes being to improve the quality of information provided to the investing community - while at the same time keeping to the promise to not require an audit of the XBRL?

The answer; give filers two years to learn how to get their XBRL right, then make the XBRL carry the same legal liability as the HTML filing, but without a requirement for an audit.

Here is the problem; the two year window did not give enough time for the development of a deep enough reservoir of resources that actually understand XBRL, and the development of enough skilled individuals within companies to produce XBRL that is "the same" as the HTML. Certainly not to any meaningful level of confidence.

Now CFOs should be asking themselves "Why Worry?" Our providers know XBRL, shouldn't they, even if we don't? Right? And the SEC isn't really serious about this stuff, are they?

Too many filers simply do not have the resources to have dedicated XBRL expertise in-house. And the increase in total XBRL resources required to support production of XBRL filings has grown by over 100 times in five years. So, in 2009, for every 1 "XBRL resource equivalent unit" then we now need almost 100 today. (I'm inventing a new unit of measure here - the XBRL resource equivalent unit (the XREU, but I promise to avoid using that). The XREU is a unit of measure equal to the person resources, trained in XBRL, required to produce the equivalent of a first year "block tagged" XBRL filing. So I'm assuming for simplicity that each filer required 1 unit equivalent for their first year of filing. I am also, from personal experience and wide discussion, that “detailed footnote tagging” (DFT) represents three times the first year effort, and therefore equals 3 XREUs. Finally, I am also assuming that assurance over the XBRL requires 1 XREU per filer. I know, a very blunt instrument of an estimate, but let’s go with it for a moment.)

So in 2009, we needed 500 XBRL resource equivalent units. And for estimation purposes only let's imagine that detailed tagging requires three times the effort, so in the second year, production of XBRL required the original 500 units (for the first filers) plus 1500 units for their detailed tagging requirement, plus another 1000 units for the second wave of filers.

For simplicity the following chart shows the growth in required XBRL resource equivalent units.

Oh, and just in case, I've also added the equivalent of 1 XBRL resource equivalent unit per filer for assurance starting in each filer's third year - the year they leave their litigation relief.

So why worry? Because a close look at the chart above shows a growth from 500 XBRL equivalent units in 2009 (basically, one filer's basic tagging of face financials equals 1 XBRL equivalent unit in this analysis) to over 50,000 XBRL resource equivalents this year; 2013.

Most CFOs, even if they have not see the chart above (or one like it) instinctively know that they are exposed. There simply has not been the time to train and retain the skill sets and individuals required to actually produce over 50,000 XBRL resource equivalent units. The additional small problem is that this pool of resources are needed simply to meet US SEC registrants only. There are many other XBRL implementations around the world, including India, that are competing for the few existing and established resources.

And knowing that the resources simply are not there, then it is only prudent of those CFOs to worry about their XBRL, and the liability that they now carry.

Why worry? There should be sunshine after rain. But for now, it is still raining brand new, freshly minted XBRL resources.

Put bluntly - the CFO that does not worry about their XBRL is a worry.

We are a year or two away from sunshine.

The Future of XBRL

I've been watching the rise of "big data" and have seen analytic tools that are simply mind-blowing. Tools that do not care about the format or content or meta-structure of data, yet can perform analysis across massive datasets, with speed and ease. It has made me think hard about the future of XBRL. 

XBRL has come a long way, from its humble roots to a self-fantasised future of business reporting. Unfortunately, XBRL has, through its life, performed a sort of inverted Moore's Law - doubling in complexity as it doubles in self-proclaimed benefit.

In 2000 someone said that XBRL would be fully implemented 'within a couple of years'. Sadly though, an idea that is a fast approaching it's 15th birthday is now looking like the old dame of an idea - still lingering at the dinner parties, still hoping that the limelight will finally shine on her, still dreaming of the red carpet.

The good news for the old dame is that she has a great future, just as do all those wonderful old black and white films that she was in when she was young, alluring, sexy and oh so much 'the future'.

Her future now is as the example of perfection, to be studied and emulated, even though the 'real world' has long passed her by.

XBRL's place in the future is in the universities, as a tool that can be used to teach students about the fundamentals of business and financial reporting. In an age when we are becoming disconnected from the inner components of the world around us, it is important to have educational tools that require the student to dig deeper than the superficial concepts, and into the nitty gritty of actually constructing financial statements, and the analysis of those financial statements.

The beauty of XBRL for accounting education is that is molds both accounting standards and 'almost' programming. The deconstruction of individual 'facts' and the need to effectively and fully define the 'fact'. XBRL documents are logic puzzles as much as anything else, and the process of construction (and use) of these logic puzzles provides a playful way of learning and exploring financial and business reporting.

But just like the dame's days as the beautiful young star of every screen are well past, so are XBRL's days of being the future of business reporting and analysis.

Maybe it is time for the dame to be a little more graceful, recognize that there are new stars, new methods, and new media. Maybe its time for the old dame to put her skills to use helping ready a new generation of stars.

The alternative is to continue to flash the same old jewelry, the same low cut dress, while continuing to expect the call. The call that will not come.

Okay, I've been away a while

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

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.

Do you REALLY want to violate SEC Reg FD?

Violate Reg FD here

Okay, you've just finished your 10-K/10-Q. The final numbers are done, and the auditors have 'blessed' the document. Before the document is filed with the SEC, someone on your team creates an e-mail that attaches the draft 10-K/10-Q and sends it to an anonymous website that promises to let you see what the HTML version will look like. Congratulations, you've probably just breached SEC Reg FD and perhaps a host of other securities laws.

For all you or anyone knows, you've just sent your filing to a competitor, a newspaper, an analyst, a potential investor.

Exactly the same risk applies to the XBRL versions of financial statements that must now be provided by all filers. And indeed that is exactly what a website today suggests you do. A site that will allow you to upload a copy of your XBRL files and provide you with a viewer to see what your XBRL will look like once its filed with the SEC.

I tried the site today, using an XBRL document downloaded from the SEC (special thanks to the person who suggested this obvious way to test... so obvious I missed it). I wonder how many other people got to see the XBRL that I uploaded. Thank goodness it was not the XBRL of a real client or filer.

Broc Romanek, Editor of TheCorporateCounsel.net, notes: “If companies are accidentally selectively disclosing their financials, that appears problematic and they could be deemed to be violating Reg FD as well as be considered to have inadequate disclosure and internal controls.”

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.

XBRL and Banking - the coming boom

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

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

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

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

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

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

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