Summary

XBRL (eXtensible Business Reporting Language) is the One True Standard for business reporting; or is it? It is long past time for the XBRL community to be considering what are the situations where XBRL will make a qualitative difference in business reporting, and stop declaring that every reporting problem can be solved if only it was XBRL’ized.

Two hypotheses:

For sake of argument lets start with two potential hypotheses:

XBRL is the standard for business reporting from creation of any individual concept of business information through to the reporting and consumption of that individual or aggregated piece or pieces of business information - that XBRL satisfies and is the most effective standard for all points along business reporting supply chain.

XBRL is a specialized standard that can and should be used for specific applications and situations where the use of taxonomies and the complexity of XBRL will solve business reporting issues.

Unfortunately sometimes questioning the first statement is not welcome. Yet accepting it leads to some pretty interesting ideas of what XBRL can do or where it should applied.

The first hypotheses is difficult to support in a world where software vendors, accounting firms, individual companies and standards setters have yet to fully embrace and build the standard into their core products and services. After all, belief in the efficiency of markets would suggest that something as obviously beneficial as XBRL should have been fully embraced and implemented by markets years ago. Yet we still require the support of regulators to create demand and products.

In every case where XBRL has been voluntary, where companies have had to make an investment or expenditure decision, participation rates have been, well, unimpressive. This does not in any way disprove the value of XBRL, but it does indicate that in its first decade, the value proposition for individual companies required to make an expenditure decision has been inadequate to propel XBRL into ubiquity.

And companies will not "just realize the benefits and implement XBRL", which has been said to me a number of times. People and companies do not work that way. If they did, "we would all just realize [...fill in the blank...]" and we would actually have World Peace.

Does this mean then that XBRL is not an effective standard for efficient and effective business communication? Absolutely not. From my perspective it simply demonstrates that XBRL is not a panacea, and that we need as a community to be supporting the most effective use-cases, and promoting the value proposition to investors and decision-makers associated with those use-cases.

Taxonomies are Very Expensive:

We must also remember that every implementation of XBRL will require a taxonomy, and taxonomies are not cheap. When I asked the XBRL US Domain Working Group in 2006 to tell the Steering Committee how much was needed to develop the US GAAP taxonomy, I was told $3 million. I asked for a justification of that, saying “I can spend $3 million, but what would it be spent on?” The Domain Working Group came back with a plan, and I took that plan to Washington. I said, “Okay, realistically we might need more like $4.5 million”.

In the end, the numbers that I have heard for the actual cost of the US GAAP Taxonomy range between $12 and $18 million. That is 4 to 6 times the Domain Working Group’s estimate, and these were the taxonomy development experts. Even the higher number ($4.5 million) was low by 3 to 5 times.

The costs of the NTP (Netherlands Taxonomy Project) are not public, but also probably significant exceed common assumptions. It certainly took longer than expected.

The FDIC, one of the most successful XBRL projects to date, imposed a one-year postponement on their go-live date to ensure everything had been adequately tested.

So every time someone suggests that “this is a great application for XBRL”, consider the cost and time, and ask them who will fund the taxonomy development.

Some examples of XBRL for Everything:

Over the years there have been some interesting suggested use-cases for XBRL. I think my favorite was from earlier this year, when it was suggested that XBRL tagging of information in containers could be used to help thwart Somali pirates. If you take a look at this site (), you'll see where a huge number of ships are at any moment in time. Notably missing is any information from the Arabian Sea and Indian Ocean. My guess is that ships passing through this area do not want their location known, and they certainly do not want to broadcast their cargo to pirates or land-based handlers of the pirates.

Another is the idea, long held and promoted, that XBRL can be used to at or near the transaction level. Of course, this potential use-case is strongly defended in the XBRL community, because to fail to support this use-case would be a de-facto acknowledgement that XBRL is not the right answer to every question. When you are a hammer, everything looks like a nail. Now, I know that saying this will result either in angry responses, or pouting grumpiness from a few proponents of the concept of XBRL-GL. Get over it. XBRL as an international organization has paid lip-service to XBRL-GL for a decade, yet not a single ERP vendor of any market size has indicated any intention to implement (if any have, the XBRL world certainly is keeping quiet about it). If any smaller ERP vendor has indicated such an intent, we as a community have not made enough noise about that.

Today, to accomplish the dream of using XBRL-GL for internal (and external) audit analytics, the user must first convert the data into XBRL- GL, or import into an analytic tool that supports XBRL-GL. How much easier to simply import the data based on the file formats provided by IT or by the client.

So the alternatives are?

XBRL proves itself most valuable as a boundary standard, where multiple reporting entities need to provide information to a common consumer or consumers of that information.

The FDIC provides a great example XBRL as an optimal standard for data collection. The FDIC collects quarterly "Call Reports" from approximately 8000 (and falling) banks in the United States. In October 2005 the FDIC went live with their XBRL enabled CDR (Central Data Repository) system. The software vendors who provide the front end software used by banks to create "Call Reports" were required to build the FDIC's taxonomy into their applications, and to use the XBRL to pre-validate the information provided by the banks.

The FDIC was able to use this improved process to dramatically reduce the numbers of errors, and to increase the numbers of banks per FDIC analyst. The FDIC has gained significant efficiency benefits from their XBRL implementation. In this case, XBRL is being used very specifically to enable a many-to-one boundary reporting process and content improvement.

The FDIC provides access to the collected information in three formats, each of which contains the same data.  Downstream consumers of the information may take XBRL, SDF (Structured Data Format - basically a CSV/flat file) or human readable PDF files from the FDIC.

IRA (Institutional Risk Analytics) is a user of FDIC data. IRA performs analysis of banks and runs its own "stress tests", and provides a score for each bank, along with comprehensive analysis driven by their models. IRAs banking data is used by a number of significant entities to analyse bank performance, and by a very large number of individuals who purchase IRAs reports on their individual banks.

Here's the rub - IRA does not use the FDIC's XBRL feed. I talked with Dennis Santiago, CEO of IRA, about his data choices. He sad to me "Dan, why would I make a choice to spend more programmer time and company money on a complex standard when I can get the data as a flat file and directly import and use that data. It does not make economic sense for me to use the XBRL. I know that data in the flat file will be as clean as the XBRL; it comes from the same source."

"We tried taking the XBRL, but we just had to spend too much effort stripping it back to flat files so that we could run computations and analysis against the data. We were already, and still are taking flat files from other data providers. Taking the flat files from a trusted entity dramatically speeds up our processing, reduces our storage, and has zero negative impact on the quality of our product. If anything, attempting to remain current with an ever evolving taxonomy imposes simply too high a price on our business."

Recommendations:

XBRL is a standard, it is not a hammer. We need to stop looking at every situation as a nail.

l          There are plenty of valid examples of reporting situations for which XBRL is the perfect answer. And while some might not be terribly happy about it, the iXBRL requirement from HMRC is probably one of those examples. XII and the jurisdictions should be looking for such projects and programs.

l          The SEC should consider following the FDIC's example, and provide multiple formats to consumers of the XBRL data is provided by filers. Is there a more "trusted" or "trustable" entity then the SEC for data? In which case, a "flat file" from the SEC in a defined format should work wonders for a large number of users of that information, and like IRA, they may be able to make quicker, more efficient use of that data available from the SEC.

l          XII should, through its working groups, develop a model for the effective estimation of the true costs and time required to develop a taxonomy that can then be used as input for projects considering an XBRL solution.