Change
Report: What's Your XBRL Readiness?
By Michael Ohata | Dec 1, 2008 12:00 PM
Late this year, the SEC will likely finalize a
rule that will require U.S.
Finance and IT organizations should already be
jointly planning for XBRL to ensure that it is integrated into their financial
reporting processes in advance of the SEC's deadline for their organization.
(The SEC proposal takes a phased approach in which large, accelerated filers
will be required to use XBRL before smaller companies are.) Yet many companies
haven't begun preparing in a meaningful way, according to the results of a
recent survey conducted by BPM Magazine and sponsored by TITAN-Pinnacle.
In it, 43 percent of respondents claimed to be beginners with XBRL, and 38
percent claimed to have no knowledge about the data format. Among respondents
in the second category, 81 percent work in public companies and 43 percent work
in companies with more than $1 billion in annual revenue. They include finance
managers, finance and business systems analysts, vice presidents of finance,
and project managers for performance management software implementations.
XBRL is coming, whether companies like it or not.
Fortunately, even organizations that currently have a limited understanding of
the technology's workings — and objectives — can become prepared by keeping in
mind a few simple tips.
First, Understand What
XBRL Is
An Internet-based technology standard, XBRL
requires companies to label their financial and business information in a way
that reflects the context of each piece of data. This makes data easier to
access in large and complex organizations and easier to compare across company
lines. Companies “tag” a financial statement by associating pieces of
information in the financial statement (its numbers and text) with the elements
in a standard “taxonomy,” which is an XBRL dictionary, of sorts. For example, U.S. US
Today, most financial statement information is
filed with the SEC in HTML or ASCII (text) format. This means that analysis of
the data typically requires extensive re-keying of information and
interpretation of the assumptions underlying — and comparability among —
different pieces of data. But information coded in XBRL can be instantly and
accurately exchanged between systems. Because XBRL is based on core Internet
technologies, it simplifies searches across multiple financial statements and
conversion of XBRL reports into other formats, such as HTML and PDF. As a
result, XBRL makes it easier for investors to access companies' performance
information and compare their financials.
Some respondents to the BPM Magazine survey
worry about this increased visibility. One even stated vehemently that XBRL
will add to the effort that his company must regularly expend to correct
analysts' misunderstanding of the organization's financial data. Currently, the
market's focus around XBRL has been on its benefits for those outside an
organization. For companies, XBRL implementations have mostly been about
complying with SEC reporting requirements. However, as businesses embrace the
concept as a matter of necessity, they may want to step back and look at XBRL
in the context of data standards and the optimization of their own reporting
systems and processes. (See also Prepare Today for the Reporting
Language of the Future in the May 2007 issue of BPM Magazine
and Standardized Data: XBRL's Benefits for
BPM Benchmarking in the magazine's November 2005 issue.)
Getting Started
Although CFOs and other finance executives don't
need to be XBRL experts, they should understand XBRL's potential impact on
their organization's financial reporting processes, including what XBRL
reporting looks like and how it differs from current filings. Finance
executives who continue to characterize themselves as having no knowledge of XBRL
are taking an untenable position. They need to learn the basics so that they
can lead — or at least provide adequate support for — their organization's
change effort.
To start its move toward XBRL, a company must
identify the individuals who will have responsibility for managing the XBRL
preparation process. The team should include a corporate reporting
representative, an accountant with external reporting knowledge, and a
technologist with experience in extensible markup language (XML, the underlying
Internet technology on which XBRL is based). The team can get started by
reading the Preparers Guide that is available at www.xbrl.us and reviewing
the U.S. GAAP XBRL taxonomies.
The next step is to develop a sustainable process
with appropriate controls, so that the company can apply appropriate standards
of quality assurance around the preparation of XBRL-formatted filings. More
than half of the 725 respondents in a recent KPMG 404 Institute poll believe
that developing a sustainable, well-integrated process will be their biggest
XBRL challenge. One key consideration in developing a solid process is the
presentation of information in the XBRL format. Because the proposed rule
includes a requirement for concurrent filing of XBRL submissions, the new
process for preparing XBRL filings will have to be integrated with the
company's current financial reporting processes. Quality assurance will require
an understanding of XBRL instance documents (i.e., XBRL-tagged financial
statements), along with how the documents are constructed and how they differ
from the HTML and ASCII versions.
Another key consideration involves decisions
around when and how the company should extend the standard U.S. GAAP taxonomy,
adding data tags that are unique to the organization or its industry. While
XBRL is based on standards, some pieces of an organization's reporting data
will not be found in the GAAP taxonomy. Both finance and IT will need to
understand taxonomy extensions — custom tags that represent reporting concepts
not found in the standard taxonomy — and have a set of guidelines for when and
how to define these extensions. In addition, the XBRL team should look at how
the company will document the mapping of a particular type of data to a
specific XBRL tag, and should think about what validation entails. The
validation process determines whether an XBRL document is compliant with the
XBRL technical standards and whether calculations within an XBRL-based
financial report are accurate. The SEC's proposed rule does not include an
attestation requirement, but companies should manage XBRL filings in the same
way that they manage other filings, ensuring that appropriate quality assurance
is in place.
Companies also need to decide whether they will
prepare their XBRL submissions internally or outsource the work to a third
party. If an organization decides to prepare its XBRL submissions internally,
the first step typically is selecting a commercial software package. Choosing
XBRL Software, lists several factors that a company should consider as it
shops for this important component of its reporting regime. Managing the
software purchase process requires a baseline knowledge of XBRL and, ideally,
some hands-on experience. Fortunately, coming up to speed quickly is possible.
Outsourcing can be a good option if a company is
hesitant to tackle XBRL tagging itself, but even outsourced XBRL reporting
requires the company to have a defined process for overall management of the
preparation of its various financial reports. Organizations that choose to
outsource need to look for a service provider whose offerings integrate well
with their financial-report preparation process. Questions that can help
determine whether a particular outsourcer is a good fit include: Will the
service provider create taxonomy extensions specific to our organization? What
software will the service provider be using? What type of automated validation
tools does the service provider use? And how much of its service will entail manual
efforts? Regardless of whether XBRL documents are prepared internally or
externally, managers remain responsible for the accuracy of their company's
financial data. Executives must include an appropriate amount of review
throughout their XBRL report preparation process to ensure accuracy.
Moving Forward
Although the SEC's proposed rule involves a
phased-in approach to implementation of XBRL, it is not too early for any
public company to get started with preparations. In fact, management should not
underestimate the steep learning curve that comes with any new technology;
executives of businesses that file with the SEC would be well-advised to begin
educating themselves and to start planning their new reporting process
immediately.
When planning for implementation of the reporting
format, XBRL team leaders will need to factor four major required activities
into the budget and the timeline. First, the company must provide adequate time
for training, process development, and quality assurance checks. Second, the
organization needs to analyze how concepts in its financial statements in Forms
10-Q and 10-K align with elements in the U.S. GAAP XBRL taxonomy (i.e., it
needs to sort out the data mapping). Third, the company needs to identify where
it requires custom tags or data extensions to capture those elements of its
financial reports that are not found in the standard GAAP taxonomy. And fourth,
a company must make sure that its executives and key decision-makers understand
the differences between the organization's ASCII/HTML filings and its XBRL
submissions.
Adopting XBRL will require the same discipline
from companies as that which surrounds their current financial reporting
process. They must institute quality assurance procedures and develop controls
over the new process, especially since the proposed rule requires concurrent
filing of XBRL-formatted submissions along with the HTML and ASCII versions.
The XBRL process is certainly manageable; companies that take the proper steps
and allow adequate time to prepare should have a reasonably smooth transition.
Michael Ohata is managing director of advisory services for
KPMG LLP and chairman of XBRL International. Previously, as the senior director
of finance, he led Microsoft's voluntary XBRL filing project.
Choosing XBRL Software
Factors to consider in the evaluation of XBRL
software include:
- Ensuring that the tool is compatible
with the latest version of the U.S. GAAP XBRL taxonomy.
- Determining different tools' ease of
use for users at all levels of experience. For example, consider whether
the software's user interface is intuitive, and whether it supports simple
tasks.
- Determining how easy to use the
tool's validation functions are, both in terms of identifying problems and
in terms of resolving them.
- Assessing the quality of technical
support for the team that will be using the software.
- Obtaining the training and support
necessary for users to accurately tag financial statements and reliably
produce XBRL submissions for the SEC.
- Deciding which software functionality
the company will need, including extension creation, instance document
creation, and validation features. Will a select few software modules
suffice, or does the company require an integrated solution?
