XBRL in Canada: The Case for Moving Forward

Written by Chantal Rassart 

Posted on October 7, 2010 ments

My grandmother used to say, for every pro there’s a n, and that’s certainly true of technological progress. Yes, technology speeds up data processing; yes, it automates routine tasks; and yes, it makes information far more aessible. At the same time, now we are overwhelmed by data; simple changes to system parameters require the involvement of specialists; and puter systems within an anization often are inpatible with one another — to say nothing of external systems.

Today, businesses fill out most reports – production schles to suppliers, financial statements to shareholders, financial ratios to bankers, requests for ernment grants, and so on -- in formats that must be manipulated again and again along the information supply chain. Wouldn’t it be great if a pany (or even an individual) uld generate financial information and other data only once in a format that allows both internal and external users to integrate it instantly into their systems?

As readers are aware, such universality is precisely what XBRL offers. With XBRL, data no longer needs to be manipulated for each information request. Information is automatically exported into a readable and usable format by each user’s application; all users need to do is automatically import the data that is regnized by their systems without further manipulation.

Since this time- and money-saving solution already exists, the question bees why it isn’t being used more often. The level of interest in XBRL in Canada among users of financial information is instructive.

Much of the focus has been on the financial reporting activities of publicly-listed panies, as it was expected that securities missions would adopt regulations similar to those of the SEC, requiring panies to publish their financial statements in XBRL. A voluntary program was introduced in Canada several years ago, but a mandatory requirement has yet to be adopted.

To understand why not, nsider that publicly-listed panies are already very busy with the changeover to IFRS, and we can assume that the securities missions are hesitant to add new requirements until after the transition. At this time, only one requirement affects a limited group of Canadian panies: those firms that prepare their financial statements in acrdance with US GAAP (or, beginning in 2011, IFRS) and are registered with the SEC must include XBRL exhibits with their reports. About 400 panies will be affected by this requirement, a relatively low number nsidering that there are more than 3,800 reporting issuers in Canada.

The potential benefits of XBRL remain pelling, however — so, what will it take? How can XBRL use bee more widespread in Canada? In lieu of a legal requirement, sound reasoning that can rce user apprehension must be made, and the advantages of using this format must be demonstrated.

This reasoning will need to address these most-cited reasons for not adopting XBRL:

Lack of knowledge XBRL is wrongly seen as only a technological matter that falls in the realm of puter experts. puter experts make sure that security standards are met, the nnectivity level is at its maximum capacity, and applications are properly installed; but when it es to taxonomy and tagging — the driving force behind XBRL — that’s the acuntants’ domain. Acuntants are the ones who will tag data and assign their acunts to retained taxonomies, so they need to be made more familiar with the standard. Fortunately, the knowledge gap is not insurmountable. In most cases, a half-day workshop is sufficient to bee familiar with the basics of XBRL, the relevant taxonomy, and the software that facilitates its application.

plexity Off the bat, XBRL’s acronym turns off many. Instead, it’s best to describe XBRL taxonomies as dictionaries. The “dictionary” ntains a ntrolled vocabulary to assign to each item of financial information. Doing so bees a rather simple exercise once we understand the nature of the financial information and its definition within the selected “dictionary” (or taxonomy).

Lack of time The initial exercise of tagging data can be long. Depending on what data a pany chooses to tag — financial reports alone, or a portion or all of its source data — the exercise uld be very long. It takes several minutes to tag an item of financial information, but the payoff is greater flexibility. It’s important to understand that the more granular the item tagged, the more flexible it bees for sharing information.

No readers Unfortunately, this is a devastating argument! Today, users of financial information cannot easily read data in XBRL format: they first have to download an XBRL data reader, which can be a serious obstacle even for interested users. As long as we don’t have the equivalent of a web browser (like Inter Explorer, Chrome, Firefox) that is ever-present and allows users to read information on the Inter without getting lost in de, it will be very difficult to increase the number of XBRL users. Regulators including the SEC in the US and the CSA in Canada have moved forward with some data readers, but we have a long way to go.

Chicken-and-egg Even if data preparers create documents in XBRL, their users may not be able to process documents in this format because their systems have not been modified to do so — because not enough preparers create documents in XBRL to necessitate the switch. To make the switch make sense, an entire group of entities – e.g., all the subsidiaries of an enterprise, or all the members of a mon-interest work -- ought to adopt XBRL together, in order to benefit from its advantages in all their internal information exchanges. The payoff from the transition is that information can be exchanged even if participants do not use the same systems, do not transact using the same currency, or do not express themselves in the same language. All it takes is that everyone’s data uses the same ntrolled vocabulary, with equivalents for the relevant currencies and languages.

Ultimately, however, what it will probably take to overe many of these impediments to adoption is a legal requirement making it mandatory to provide financial data in XBRL format. In response to jump-started demand for XBRL patibility, financial application providers would step forth with updated applications.

Meanwhile, a standard simple XBRL reader similar to web browsers would also be helpful. The goal is demystifying the XBRL format and allowing financial data available in this format to be analyzed.

Several untries are well advanced in this area: Australia, the herlands, and Japan are a few examples. The future will tell whether Canada joins this group of innovators or if it will wait to join the trend once the market dictates.