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.

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

I remember my very first XBRL meeting

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

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

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.

Guest Post: Using XBRL for Solvency II reporting

XBRL is a global standard, and while Random Comments tends to focus on the US and the SEC Mandate, it is important to look well beyond, and see the range of other applications and projects that will leverage the power of XBRL. When we survey the landscape of business reporting, Insurance is clearly an area of significant information exchange that would benefit from the unique strengths of XBRL for business reporting and information interchange.

Gideon Benari is the editor of Solvency II Wire [www.solvencyiiwire.com], a website dedicated to news and insights on Solvency II, the European insurance directive which is due to come into effect on 1 January 2013. He recently wrote an article posted on the XBRLBlog. Here he provides us a summary (with link to the full article). 

Using XBRL for Solvency II reporting

Solvency II, the new regulation for the European insurance industry, will use XBRL as its reporting standard. Solvency II is a risk-based regulation that will affect capital adequacy requirements, governance and reporting standards across Europe.

The eXtensible Business Reporting Language format, essentially a sophisticated form of text mark up, facilitates the transfer of data between financial organisations in a standardised way. This will allow regulators to make like-for-like comparisons of data from insurers across Europe.

One reason XBRL is suited for Solvency II reporting is that the taxonomies can be extended to local level. According to a study published in the Journal of Financial Regulation and Compliance (2010)* examining the use of XBRL for Solvency II, “Once a taxonomy has been created at the European level, extensions can be added to cover the particular features of national regulatory frameworks, thus ensuring the homogeneity of the system of information while giving it the flexibility that the framework requires.”

Solvency II is due to be implemented in January 2013. Currently the European Insurance and Occupational Pensions Authority (EIOPA) is working out the finer details of the regulation.

Commenting on EIOPA’s decision to use XBRL, Anthony Fragnito, CPA, CEO of XBRL International, said, "The EIOPA mandate for XBRL in the pension and insurance sector is a critical step toward the transparency and process improvement benefits of XBRL to insurance and risk management, and expands the XBRL footprint across the financial services and capital markets sectors."

The full version of the article “XBsRoLvency II: Say it with XBRL” can be found on the XBRL Magazine Blog. Further details on Solvency II and XBRL can be found at Solvency II Wire.

References

*    Enrique Bonsón, Virginia Cortijo, Tomas Escobar, Francisco Flores, Sergio Monreal, (2010) “Solvency II and XBRL: new rules and technologies in insurance supervision”, Journal of Financial Regulation and Compliance, Vol. 18 Iss: 2, pp.144 – 157.

Who is Your Audience (CSR/ESG reporting)?

This article is a response to an online e-mail discussion askingIs there any point putting together a CSR report?" The resounding answe ris "Yes, provided you communicate with your intended audience"

It is all a matter of defining your audience, and in particular, the audience for you CSR / sustainability / ESG report, which I'll collectively refer to as the CSR report.

Lets think about a few primary audiences, because each has different needs:

1. General public / retail customers
2. Supply chain partners
3. Investors
4. Employees
5. Regulators

1. General public / retail customers

There is a growing and general acceptance that retail customers will purchase based on the perceived social conscience / "green" credentials, as long as the produce is also competitively priced. That is especially true today. This means that it is important for a company to burnish its CSR credentials through any medium possible, and that include the CSR report.

There is also the need to be seen to be pro-active, just in case they are "caught out" by some bad PR. When (if) that happens, the company is then ready to pull out all its good works, and make the appropriate noises about how they are doing everything to make certain is does not happen again.

2. Supply chain partners

This includes both their customers and their suppliers. Customers want to know that the company is following sound business practices, acting in a sustainable manner, and fundamentally reducing risks that may travel upstream. After all, when the bad stuff hit the fan, it get spread far and wide. So CSR / Sustainability / ESG reporting that provides comfort to commercial customers focuses in demonstrating how the business is also protecting its customers from potential PR risk. It also demonstrates that sustainability practices are being applied to drive down costs, thus being able to deliver future cost advantages that competitors may not be able to deliver.

Equally, effective reporting sends messages to suppliers about expectations, and gives suppliers key messages about what might endanger the existing business relationship, especially any potential situations in which a suppliers PR problems might impact the company. Clearly stated supplier CSR policies put suppliers on notice that they will need to maintain the highest CSR standards themselves in order to retain their position as suppliers, or to gain an advantage by becoming preferred suppliers. WalMart's actions recently are a great example of establishing expectations in their supplier community.

3. Investors

Investors, including the actual shareholders (the owners) and the investor community (those that advise existing and potential owners) are a legitimate audience. They want metrics; detailed information that will support and enable investment decision making. They want comparative information that is multi-year, and that can provide insights into the company's performance against other key players in the same industry. Frequently reports that focus on the first two audience groups fail to provide adequate information for this audience, and are dismissed as "fluffy bunny bullshit" by the analysts. Analysts want tables of information that span multiple years, and that clearly show future objectives and how those objectives will be achieved.

Recently the DVFA (the German Institute of Investment Analysts) release a set of KPI (Key Performance Indicators) for ESG. This set of KPIs is broken out by major industry groups, but also contains a core set of KPIs that that they expect to see regardless of the industry.

4. Employees

Sometimes the primary audience is right there in front of you, the employees of the company. CSR / Sustainability / ESG reports for employees are and should be focused on what the company is doing, and the role of employees in individually making it happen. There reports are motivational, and should serve to bring employees together for the effort. They also provide an opportunity for communication of changes that might otherwise be buried in a staff bulletin, or not communicated at all. A classic example was came from the results of the "Talk Back" process at New Zealand Post some years ago. One mail centre specifically spoke about the quality of lighting. This lead to a review, and improvements in overall lighting, improving both performance, quality of work environment, and costs.

5. Regulators

Finally companies communicate with regulators, both directly and indirectly through public messaging. The use of the CSR / Sustainability / ESG report to communicate support for and compliance with various standards is one such way. Reading the CSR reports for the building industry tends be like reading a prose version of how the reporting company is ensuring compliance with various health and safety legislation, or preparing itself for compliance with incoming GHG emissions standards.

In in the United States, the ability to demonstrate a strong legislative compliance program, complete with effective risk management processes, can be used as mitigating factors in sentencing for any crimes that the organization might be accused of being involved in. Communication of these programs in CSR reports is one way that companies, in effect, are using CSR reporting to communicate indirectly with regulators.

Summary:

Before judging a company's CSR report, consider what primary audiences are being addressed. As a company, before creating a CSR report, carefully consider who you want to be speaking to, and what are the key messages that you want that audience to take away. Finally, companies might consider creating multiple CSR reports, targeting specific audiences.

I hope this is helpful in addressing the question in the subject line of this e-mail stream.

The Logic of the Logical Cave Wall (iXBRL)

Summary

XBRL (eXtensible Business Reporting Language) started life as a dream of freeing information from the tyranny of the logical cave wall, also known as the printed page or computer screen. Now we discover that the information is going to be read by humans after all, so lets make a logical cave wall version of XBRL.

Um, isn't this where we started from, and if so, why not just stick with something simple like, oh, XML, CSV, PDF, Word, or even a web-based form? Because iXBRL will merge the benefits of the logical cave wall while also freeing the information.
 

A dash through history
 

Once upon a time there was a cave wall. Someone drew a picture on that wall. The picture said “There are deer here, cows there, other people (competitors) over there”. So business reporting began.
 

Then humans discovered mud (well, at least for "writing"), and suddenly we could make business reports on mud tablets, dry them in the sun or fire them, and store them in our library. Much of what we have learned about Ur, Ebla and other ancient cities has come from their mud libraries, which were preserved when the libraries were burned, either accidentally or as the result of conflict and invasion. In the case of Ebla, more than 15,000 cuneiform tablets were preserved when the library was burned. These tablets include some of the earliest references to biblical figures and places, provides us with names of cities yet to be discovered, and histories and relationships long lost. Just read this, it’s fascinating.

Okay, I admit I cannot read it either, but if you look very closely, you can probably see the "angle brackets".

But lets move quickly forward in time - past papyrus, velum, then paper, and finally, to the computer screen and the high volume printer. Suddenly we have the opportunity to decouple each word, each concept, from the cave wall, or the mud tablet, or even the printed page.
 

Fantastic, if words and concepts are no longer tied to the page (or logical cave wall) then we can have the computer create the words - we'll start calling it 'data' here - and pass that data to other computers to read and use on our behalf.

But XBRL is just data
 

Enter XBRL, and the crowd goes wild!
 

For too long have we manually entered or computationally created data, printed that data, and then re-keyed or recreated that data in another system, putting human error right in the middle of our carefully conceived plans.
 

With XBRL, we can truly make the human interface redundant. We can create the data in any system we want to, provide that data to "the world" or any subset of “the world” we want to, and have the receiver automatically consume that data into their computer, producing content for decision making - wait for it - printed reports for humans to read. Printed in this context of course meaning anything from a cave wall to a computer screen to an actual printed piece of paper.
 

And here is the most important point, XBRL is data. It is data decoupled from the tyranny of the cave wall, freed from human error, and severed from the need for the human eye to provide the final quality control or audit check of the data.
 

But no one can read data
 

Okay, so we've made the great move. We are now data-centric. The cave wall is done, history, finished - efficiency is in front of us all the way.
 

So, just to remind you, you are sitting in front of your logical cave wall right now, reading what I've painted on that wall.

So now read this:

Okay, I admit it, I can’t really read this either.

Good isn't it. All that data. All that meaning, from computer to computer. We've cut out the person. No errors, fast, but with one small problem; people cannot read data. 

And in the end, if it does not pass the eyeballs test (actually, the brain behind the eyeballs, but lets not be picky), how can we give assurance that all that data is really what we thought it should be. Because assurance, whether by the creator of the data or by an external party, is based on human eyeballs looking at the information and interpreting that information through analysis and comparison with what the reading eyeballs think the information should be.

Lets make "readable" data

The answer - "readable" data, also known as "Inline XBRL" or iXBRL.

The idea is to create a standard that allows XBRL data to be imbedded into an HTML stream such that the HTML page can be displayed with the XBRL data. The XBRL data can then be extracted by the receiving computer(s) and the HTML stripped, leaving the XBRL ready to be stripped of the XBRL and imported into the receiving system. 

Well, I guess it makes sense

Being able to actually see (understandably) what is in an XBRL instance document is important. We use to assume that the software vendors would fill the gap with tools for easy viewing, and in particular that Microsoft would actually build XBRL into its product suite. Maybe they have and will.

But the software vendors simply have not stepped up to the plate adequately to enable ubiquitous and simple viewing of XBRL.

So consumers of XBRL, in particular HMRC (HM Revenue and Customs) in the UK have decided that Human Readable XBRL (iXBRL) is what must be provided, not XBRL. In order to enable this, the "Inline XBRL" specification has recently been approved.

The Cave Wall "wins"

Which brings us right back to the cave call, or the cuneiform tablet. Humans needs to see, with their eyes, the information that is being provided. XBRL is the answer for computer created for computer consumed information, provided there remains the ability to paint a picture on the cave wall.
iXBRL provides XBRL's logical cave wall.

But does that then undermine vendors efforts to actually create XBRL viewer software. I don't think so. Vendors will build applications to meet business needs, and the ability create a logical cave wall version of the information contained in XBRL instance document will not go away.

In addition, iXBRL does at least provide a recognition that the logical cave wall remains a critical part of the business reporting environment. Will iXBRL help expand the range of use-cases for XBRL? Quite possibly, by providing the logical cave wall integrating separable, non-human consumption of the data.