01 December 2009

XBRL - the One True Standard?

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:


  1. 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.
  2. 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 (http://www.marinetraffic.com/ais/), 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.


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

2 comments:

  1. The problem with XBRL GL is not the format itself, but the approach to introduce it to the market. The idea of finding application cases and pushing for its introduction, do just not work. In fact it is for instance such governmental demands that are usually removed today in the EU simplification processes.

    The reason XBRL don't work in the market is that there has not been built in any real rewards for the producer of data, the paying customer of SW. And the demand for XBRL comes from those who wants to use the data, and is not the paying party of SW. The main problem is that XBRL is not designed from the view of the paying customer. However data can be available in anyway, but other ways of getting the producer of data to pay for the export features has to be found. The benefits suggested today, like a week extra to file reports, are in most cases insults to the paying customer.

    What should be interesting for XBRL to study is the SIE in Sweden that is about the same thing but in great use since 20 years in one country, very alike XBRL. SIE is tagged flat file format, but that is not the issue. The issue is that SIE built in a benefit for the paying customer. It was designed to export data to special applications for income tax declarations and soon expanded to full ledger that created a market of emailed accounting files exchanged between clients, accountants and audits. Making their work integrated, the audit could stay in his own office and do the work on his computer and application SW. And suddenly there is not possible to sell SW without SIE support in Sweden.

    The XBRL GL SBR-LS conversion specification and application code kits like I am developing for XBRL GL, UN/CEFACT and SIE accounting will make data cross format available. That will make a huge change for XBRL GL. The SW marketed in Sweden are also available internationally and has SIE support, so files can be converted to XBRL GL. If that is possible suddenly a market for XBRL tools will grow. If the audits and analysts want XBRL there will be no trouble in the future.

    The second big flaw of XBRL is letting people believe international transparency comes with the file format, it don't. It comes with administrative harmonisation processes between countries and that is politics. The file format work is not politics and here we need to communicate with the politicians. Many from XBRL tell them that transparency comes with the file format and we will never get it. We need to convince them that the only key is the harmonisation starts with the tax administrations. For more details you can read the Alphabet ABs replay to the EU CESR 09-859 document. See http://www.alphabet.se/download/Alphabet%20AB,%20Response%20to,%20CESR%2009-859.pdf

    The question where are the experts in XBRL you stated in one of your articles is certainly a symptom of the present situation. I have been the secretary of the SIE and a member of the XBRL Sweden board as a SIE representative and been participating in the UN/CEFACT process. I tell you there are about no consultancy missions in XBRL possible today and I live mainly by driving taxi. I can’t afford going to UN/CEFACT forums worldwide, sometime when near, like in April 2009 in Rome I did go. I believe in a future market, that is why I do it. There is email.

    My SW development is slow but I believe it will be it making any data in XBRL GL format available. But there is certainly no funding. The costs you have been referring to, are enormous but will never the less, hasn’t gain results. Much less money would make on other tasks, a huge difference. XBRL so far always has been thinking big. It is from the other side of the market, you create the results, it is worth a thought.

    I think the questions you are arising are very important topics. You know the development has only two sources in combination. questioning and immaterial assets. Something the accounting and financial analyse can't evaluate. I think that is also an important topic.

    ReplyDelete
  2. Jan, Thank you for the comment. Your second paragraph seems to hit the problem directly.

    ReplyDelete