What are the interest and awareness levels among investors and analysts in XBRL?
Investment professionals are marginally more aware of XBRL than they were four to five years ago, but there is still lot of learning to be done. Fund managers and securities analysts are generally excited about what XBRL can do for them, but they expect it to be delivered as a packaged product, ready to use. They are waiting for the concept to become more of a practical reality.
To sophisticated investors and other users of financial information, XBRL still looks and feels more like a concept car than one they can drive off the lot. The technology is interesting and promising, but it still feels inaccessible to them. So fund managers and equity analysts continue to work with Bloomberg, Thomson Reuters, FactSet, Compustat, or other solutions that are ready to use and already tie seamlessly to their workflow.
What are the obstacles investors and analysts may encounter?
There are no inexpensive, off-the-shelf software programs available that allow users to pull data from XBRL instances into their (mainly Microsoft Excel) spreadsheets. Among the earliest solutions, we see applications that are designed for the specific use cases of investment professionals, so they could not handle different taxonomies. We also see applications that simply disregard workflow constraints. They may offer a spreadsheet solution with a familiar look and feel, but they are in “the cloud,” where serious financial analysts would never put their models; it raises too many concerns and compliance and the protection of intellectual capital.
For the software industry to produce an inexpensive, off-the-shelf solution – something in the range of $250 – it needs a mass market to economically justify development. In the case of XBRL, there is a market, but it couldn’t be described as “mass.”
XBRL International is ideally positioned to take the lead on promoting or even funding the development of applications for general users – and not just for investment professionals. It takes a visionary approach like those we should expect from XBRL consortia to turn this concept into a marketable reality. The situation feels a bit reminiscent of the advent of the World Wide Web. If users had only been able to view web pages and not work interactively with web content, it would have remained a static, stagnant resource winning no better than a lukewarm reception from consumers.
Are there any other obstacles that concern you?
XBRL also suffers from a bit of an image problem. At first glance, it looks a lot more like a regulatory initiative than a technological solution. XBRL International’s success stories describe simple, upstream processes, focusing on a number of entities that send their data into a central database, and that’s the end of the story.
If that was the true intention of XBRL, we could have used plain ASCII. What about downstream processes? The corporate reporting supply chain – that is how those of us in the investment world would see it – does not end in the database of a regulator.
To my knowledge, there are more than 100 XBRL installations in place around the globe. Assuming pools of instance documents exist in each of these installations, who uses these instances? Why is there so little interest in giving users access to the instances? Having users work with XBRL instances is so pivotal, it may be the most significant factor in whether XBRL is ultimately successful. History has demonstrated it is not necessarily the best standard that wins the race, but the one that is most rapidly adopted.
Filers and taxonomy developers have had to buy or develop software and services that have been created by software developers who have funded the development and then marketed those applications to users (filers). This has been done without funding from XII. Why is it then that XII ".. is ideally positioned to take the lead on promoting on promoting or even funding the development of applications for general users" for analytical purposes?
Surely the "rules" should be the same for the analytical community. They should be driving the need for such tools by asking software developers and then paying a fair price for those tools. I agree that XII could be a driver but they should not be a funding the application development. Their responsibility is to continue the development of the standard as the XBRL market grows. Application development is the responsibility of the software development community and analysts need to start asking for it and expecting to pay a fair price for it.
I am sure that the cost of applications and the development of the sophisticated spreadsheets used by analysts cost a lot more than $250 per application licence. Why should it then be expected that a comparative application be available to the market at such a cheap price?
The comment about XII's responsibility to possibly fund the development of applications and some of the other comments seem to indicate to me that analysts (at least the author here) want someone to "give" them all that they pay for now to get their data from data providers but without having to pay the same fees they pay their current providers.
Jim,
thank you for responding to some of the points I made in the interview.
You seem to be looking at XBRL from a completely different angle than I do. For me it is a very clear case: XBRL is medium of transmission i.e. getting company data from A to B. Its purpose is not to showcase that XML works with accounting data: the promise and expectation of what XBRL can do is to provide greater transparency of company performance and ease of accessing performance data. But for whom? Clearly, the answer is: for users.
Users i.e. financial analysts and investors already have access to company data in a digital format today through Bloomberg, FactSet, ThomsonReuters, Compustat and others. They are clearly not queuing for XBRL. From my perspective it should be the absolute priority of XBRL International and in fact any company reporting XBRL instances to have users use XBRL. Who has ever heard about a transmission standard without users? Radio programs without listeners, web sites without visitors - how long will this transmission standard survive? And you suggest that users invest an equal amount of money as the corporate side had to invest? Are you serious?
From my perspective most XBRL implementations are mere acts of technological and accounting masturbation. Sorry for these harsh words but I thought I might as well speak my mind. In 2011 for the first time I have heard accounting and corporate reporting masterminds say that they think if XBRL does not quickly built a significant pull from users the standard will die down. I believe this is true. But because we all have invested that much time in XBRL I am trying to wake up XBRL International to do something about user involvement. If, however, XBRL International clearly stated that XBL is nothing but a regulatory tool that would also be fine but then we'd be released from the pushing for user involvement.
R.
Here are some tools that are currently available and may help analysts consume and analyze company XBRL structured disclosures:
EDGAR-Online's IMETRIX: http://www.edgar-online.com/OnlineProducts/IMetrixProfessional.aspx
Morgan Stanley's Modelware: http://www.morganstanleyiq.ch/DE/binaer_view.asp?BinaerNr=141
BlueMatrix Financial Online Research Production: https://www.bluematrix.com/www/Home.action
Rivet Software's Crossfire Controller: http://www.rivetsoftware.com/solutions/sec-corporate-filers/crossfire-controller/default.aspx
Hitachi's Xinba: http://www.hitachiconsulting.com/xbrl/products.cfm
Microstrategy's Bank Performance iPhone and iPad apps: http://www.microstrategy.com/news/pr_system/press_release.asp?ctry=167&id=2252
Also, as a source of timely and freely available company XBRL disclosures; analysts may want to consider the SEC EDGAR RSS Feeds available here:
http://www.sec.gov/spotlight/xbrl/filings-and-feeds.shtml
There may be other tools listed here: http://xbrl.us/taxonomies/Pages/US-GAAP2009.aspx and http://xbrl.org/tools that may also be useful to analysts.