Bob Schneider is a Partner in 
Wilson So is the Director of Hitachi Consulting Corporation An Interview with Gerald Trites of XBRL Canada (Part 1)
Gerald Trites is Project Director of XBRL Canada and writes the XBRL Canada Blog. He is an information systems researcher and consultant who is a Research Fellow with the Center for Information Systems Assurance at the University of Waterloo. Previously, he was a Professor at St Francis Xavier University and a partner of KPMG.
Mr. Trites is also principal author of Interactive Data — Building XBRL Into Accounting Information Systems, a book we strongly recommend and the focus of this first installment of our two-part interview.
(1) Your book contains this comment about XBRL and XML: “Many enterprises already use XML to make data available across various disparate systems. XBRL, however, is a more efficient and meaningful system of tagging because it is specific to accounting reports and systems, and is acknowledged by XBRL International.” Could you elaborate further on the advantages of XBRL over XML, and why XML itself isn’t sufficient for business reporting?
This is a rather basic question, but one I’m happy to answer because it is so important to an understanding of why XBRL should be adopted.
XML of course is a generic language and its use for any particular purpose requires that the definitions and special attributes need to be introduced into it (i.e., tagged) before it can be used for that purpose. So if XML is used for internal systems integration, which often happens, these tags need to be added. When it is used for internal purposes, this can be done because the same tags can be used across an organization. However, the tags, not being standard, will not be compatible with tags used by other organizations, so the usefulness of the information is limited.
With XBRL, since the tags are based on an international set of standards, the usefulness of the information can be extended outside the organization. In addition it becomes easier with a standards set of tags to implement XBRL in various segments of the organization than with XML.
(2) Another quote from your book: “While extensions are necessary to enable XBRL to be used for the production of useful and relevant reports, too many can destroy comparability.” There seems to be a tension between the preparers, who see extensions as a way for companies to tell their own story, and the analysts, who seek uniformity and comparability. Do you believe that tension will be a major roadblock for implementation and use of XBRL for financial reporting?
This is a challenge for XBRL that is not going to go away and will need continuing management by the XBRL community. There are countervailing forces at work that aggravate the issue. In the first place, too many extensions by different companies contribute to noncomparability, because each company is likely to do an extension for basically the same problem in a different way. So the results become difficult to compare. One way to address this is to develop very robust taxonomies, such as those in the United States. However, the problem this creates is that the more robust the taxonomy, the more difficult it is to do the mapping required. So robust taxonomies can be an impediment to adoption.
Another approach to the extensions issue is to develop standard acknowledged extensions that would be used, say, for different industries. A modularized taxonomy can accomplish this aim as well. This way, extensions will take place, but at least they will be standardized and therefore comparable. We are facing this in Canada, both with our Canadian taxonomy, which is a bare-bones taxonomy, and with the new IFRS taxonomy when we adopt IFRS in 2011. Neither the Canadian GAAP taxonomy nor the IFRS taxonomy fully address the particular needs of Canadian companies, particularly in the areas of financial institutions and resource industries.
At this point, we favor an approach of developing standard extensions, rather than developing all-encompassing taxonomies. This seems to me to be the best balance between the “barriers to implementation” problem and the implementation complexity of extremely robust taxonomies. At least this way, some control can be exercised over the extensions that are created and used.
(3) You write that XBRL can “reduce the cost of capital with its ability to place standards and context around information and improve data interchangeability and comparability.” Could you discuss how these qualities of XBRL will help companies reduce their cost of capital?
The reduction in cost of capital comes from lower costs of providing information to the capital markets and from better, more mobile information being out there for the users. XBRL through the tagging process adds context to information like definitions, standards, presentation schemes, etc. This metadata moves along with the data wherever it goes, and so it can be reused by users, including regulators and investors with no additional cost to the company. Also, once initial tagging is done, the marginal cost of providing the information is very low relative to information provided in the conventional form.
(4) You note that “an XBRL project presents upfront costs that are easily measurable, while many of the benefits fall into future years and are difficult to measure.” Given this difficulty, do you have any suggestions for companies trying to determine the ROI for XBRL projects?
In many cases, specific ROI calculations are not really necessary, as the benefits can be ball parked and matched to the costs. The situation is no different than many large IT implementation projects, like ERP projects; the solutions can be found in the approach used for those other projects.
(5) In a chapter titled Deep Tagging and Its Implications, you discuss the implications of tagging data at different infrastructure level within the organization. “Transparency, improved quality, and reusability of data are the major benefits of XBRL tagging and all are realized more fully at the data [ie, lowest] level than at any other level.” According to some reports, however, most U.S. companies are simply looking at a bolt-on approach to compliance with an XBRL mandate and not considering tagging more deeply within the organization. What will it take for companies to consider deep tagging within their IT infrastructures?
The idea of deep tagging is fundamental to that particular research study. There is absolutely no doubt that, in most situations, deep tagging is superior to the bolt-on approach. With the bolt-on approach, the reusability of the data is severely limited.
What will it take to get there? First a realization of the benefits of deep tagging by CFOs, CIOs, and others. This will come as they begin to use XBRL and experience its benefits first hand. Second, the incorporation of XBRL capabilities into popular information systems applications, accounting software, ERP systems, database systems, and so on. I continue to be mystified as to why more accounting software developers have not included XBRL in their products. I understand there is a cost implication for them, but it seems clear that XBRL is only going to increase in usage, that there is a need and that that need should be filled.