Printer Friendly

XBRL implementation strategies: frequently asked questions.

I've received many questions in response to the three previous columns. Most came from the United States, where many companies must comply with the Securities & Exchange Commission (SEC) XBRL mandate, as well as from the many other countries in which voluntary or mandatory XBRL programs are in place or being considered. The main focus was the deeply embedded approach, which isn't surprising given its broader scope and the fact that there isn't much awareness about the internal use of XBRL.

Here are some of the questions I have been asked most frequently and an overview of the answers that I provided.

Why should we consider using XBRL for more than it is required? The value of XBRL is in the fact that it provides an optimized format to represent relevant categories of financial and accounting information--entries, documents, journals of various types, trial balances, financial reports--in the same way across applications, business units, industries, and jurisdictions. This consistent format enables the use of software procedures that can be created and shared relying on that single, consistent format as opposed to being software- and application-specific. Data is decoupled from the application in which it was created or resides in and can be freely exchanged, and, more importantly, the same controls, business rules, analytics, visualization templates, etc., can be applied to it consistently across applications, business units, industries, and jurisdictions. These benefits are relevant in internal reporting and auditing, for business intelligence purposes, and for other key internal processes.

If we look at the SEC requirements or other XBRL-based regulatory compliance in isolation, the bolt-on approach may seem more appealing, but only if we choose to ignore the obvious connection with other processes and concerns that are critical and currently very cost and resource intensive. There are significant benefits and cost reductions that can be achieved by leveraging this existing and proven standardized format while planning its implementation for regulatory compliance.

The November 2009 column outlines the concept of a standards-based, virtual data warehouse "where consistent business rules and controls, templates for visualization, and analysis can be applied to the standardized data." This seems a compelling approach in theory, but it also seems too broad and comprehensive. Doesn't this make it very difficult or impossible to translate that concept into practice? A common mistake that's made when exploring the deeply embedded approach to XBRL implementation is to compare it to the complexity that a corporation faces when deploying a new enterprise resource planning (ERP) application or a reporting, consolidation, or business intelligence (BI) system. Those systems are fairly monolithic and need to be fully in place before any of the benefits they promise can be achieved. By definition, a standards-based approach is incremental; single services/processes can be deployed separately to address one significant concern at the time, and there's no need to replace the existing data stores, applications, and infrastructure. This greatly reduces the complexity and helps manage the learning curve within the organization more efficiently. Doesn't it make more sense to use the technologies provided by the ERP vendors rather than XBRL and XBRL Global Ledger (XBRL GL)? The real question is: Do existing ERP systems fulfill all the internal reporting, auditing, and BI requirements and expectations? If the answer is "yes," there's no need for anything else. But the reality is frequently different: Not all data stores can be unified under a single ERP application; different versions of the same ERP system run in different business units, and data integration between them isn't straightforward; there are different industry or jurisdictional requirements for different territorial/business units; and so on. The most effective "acid test" to verify if an ERP application really fulfills all requirements is the extensive use of spreadsheets in the various consolidation and reporting processes. Spreadsheets typically fill gaps in the existing information system, and they frequently become facilities where not only data resides, but the transformation and analytical rules applied to them are stored in a decentralized and unmanaged way. A standards-based approach can help by filling those same gaps with a still-flexible but more reliable and centrally managed approach.

Doesn't the deeply embedded approach require the standardization of a wide variety of internal data, more detailed than even XBRL GL can do? Won't it require significant modifications/extensions to the XBRL GL taxonomy to ensure that all the relevant information can be standardized? There's a common belief that XBRL GL can only represent accounting information--and the general ledger in particular. XBRL GL has a very broad and flexible representational power, and it can model any kind of data found in an ERP or source accounting application.

Do we have to guess how to represent our detail? Are we really expected to try to figure out all of the data fields in XBRL GL and how they are related to all of our corporate data at all of the different levels? Abundant guidance and best practices are available. The XBRL GL Working Group has published a number of Working Group Notes and best-practice examples of how to use XBRL GL to represent different kinds of data at different levels of detail. This is available at www.xbrl.org/GLFiles. Also, GaLaPaGoS, Global Ledger Practices Guide for Study (http://gl.iphix.net), is a repository for sample best practice XBRL GL instance documents and other resources, including webcasts of the periodic outreach calls that the XBRL GL Working Group holds on various topics. The Working Group is always available to provide guidance on specific aspects not already covered. Contact information is available on the XBRL International website.

Finally, the Institute of Management Accountants (IMA[R]) recently formed an XBRL Advisory Committee, of which I have the privilege to be a member. One of its goals is to provide XBRL technical guidance to IMA members, with a particular focus on the internal use of XBRL given its specific relevance for CEOs, CFOs, controllers, and other accountants and financial professionals. Questions to the XBRL Advisory Committee can be posted in its dedicated space on LinkUp IMA (http://linkupima.com).
COPYRIGHT 2010 Institute of Management Accountants
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2010 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Garbellotto, Gianluca
Publication:Strategic Finance
Date:Feb 1, 2010
Words:1009
Previous Article:Refining your reports.
Next Article:Tools of the trade.

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters