Telling your story, your way - Or why extensions are here to stay

There has been quite a bit of discussion about the idea that XBRL filings should be comparable, and if they are not, that somehow is a surrogate indicator of lower quality XBRL. Yet this flies in the face of one of the key promises of XBRL - "Tell your story, your way".

Companies are different, and after years of attempting to create one-size fits all reporting. The SEC tried, and IFRS continues to think they have a one-size fits most (except SMEs). It remains clear that it is what is different about companies that enables them to be successful.

Three Motivations to Create Extensions

For years the example used was that of a major computer manufacturer and service provider, which included a negative expense line for 'IP expense'. The expense was negative because the company was bringing in over a $1 billion in revenue from patent licenses. The problem was that the data aggregators consistently aggregated (well, it is in the name) would combine all of their expenses into one 'other expenses' line, thus distorting the company's position, and message. They were (are) proud of their portfolio of patents, and reflect that in their business reporting.

We also see the example of the giant Zombie banks. Looking at their XBRL we see extension rates well above 50%. They are telling their story, their way - by intentionally making it difficult for simple Zombie to Zombie comparisons to be run. Difficult in fact, for anyone to perform automated analysis, including regulators.

There are also companies that have limited resources to spend on their external reporting, and XBRL has added to their burden. Sometimes creating a new extension is simply faster and easier than digging through 16,000+ elements, reading detailed definitions, and wondering why their exact concept is missing. Equally, as the US GAAP taxonomy evolves year on year, how many companies are reviewing their extensions, confirming that an extension created in a prior year is still required.

Three examples, three motivations, one outcome: more extensions.

1. Transparency if wonderful. We are different, and we want the investing community to know that we are different. We have unique line items and footnoted facts because we want to demonstrate why we are the better investment.

2. We'll happily pay for opacity. We are different, and exploitation of our differences enables us to be successful. Enabling easy comparisons between us and our 'peers' actually will reduce our ability to exploit our unique advantages - whatever they are. Transparency helps regulators and competitors, not us.

3. We are too busy and with no benefit from investing limited resources in XBRL, we'll get this done a quickly and cheaply as possible. If we can produce XBRL that passes the SEC's validation checks, then that is good enough for us.

One example uses XBRL to improve the quality of available information and increase transparency. The other harnesses the power of XBRL to protect their opacity. "Our 'black box' is what keeps us profitable, reduces competitors ability to match us, and keeps the regulators in the dark (without appearing to want to keep regulators in the dark)". The third simply does not have the resources to waste on XBRL, there's real work that needs doing.

They are not going away

There is simply too large a need for extensions, and too many different motivations. There are also over a million extensions already created. These are not going away. Some, possibly most, are either duplicates or are so similar as the make if difficult to differentiate. Yet these are not going away. If anything, expect the total number of extensions to continue to rise.

After all, even if the SEC, the FASB, the IASB, or any group, attempts to analyse extensions to identify a reduced set of new taxonomy elements, the three motivations outlined above will act as a 'headwind' to companies migrating off their extensions. 

So while we should see fewer 'errors', we will not see significant drops in extensions that are there specifically to influence comparability or reduce the 'auto consumption' of financial and business information. Controlling the message is what business reporting is all about, not providing transparent reporting. 

Only once they have driven down the number of errors will the SEC have the energy or resources to drive down the number of extensions - and for each one, the SEC will need to demonstrate that the filer did not, in the filers' view, have an adequate justification for the extensions created and used. 

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.

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.