Capabilities and Limitations
Troy J. Strader
DECEMBER 2007 - Business
operations produce financial results that must be captured and disseminated
to a wide variety of internal and external users. This process can
be difficult because it must be done in a timely, efficient manner
while conforming to the rules and guidelines governing financial
reporting in a particular jurisdiction. The challenges associated
with accurate, timely financial reporting are apparent from the
number of accounting scandals uncovered during the past few years.
These scandals have been widely reported and the estimated cost
has grown into the billions of dollars (“Still Counting the
Cost,” Economist, October 2003). Restatements of
financial results by public companies soared in 2005 as auditors
drilled deeper into corporate accounts, in part because of a sharper
focus on requirements laid out by the Sarbanes-Oxley Act (David
Reilly, “Sarbanes-Oxley Changes Take Root,” Wall
Street Journal, March 3, 2006). But nontechnological solutions
can go only so far.
technology solution that may aid business and financial reporting
is Extensible Business Reporting Language (XBRL). But to what
extent does XBRL help? One method for addressing this question
is to assess the potential impact of XBRL on four categories of
data quality (intrinsic, accessibility, contextual, and representational)
in financial reporting.
Business Reporting Language (XBRL)
XBRL is an
Extensible Markup Language (XML) application developed for reporting
business and financial results through the World Wide Web. It
is an open standard that is being developed by an international
nonprofit consortium of approximately 450 major companies, organizations,
and government agencies (www.xbrl.org).
can be applied to a wide range of business and financial reporting
contexts, including income statements and balance sheets; internal
accounting reports; regulatory agency reports; and reports provided
to investors, financial analysts, and financial markets.
applications have already been implemented. The U.S. Federal Financial
Institution Examination Council (FFIEC), which includes the Federal
Deposit Insurance Corporation (FDIC), has mandated that banks
use XBRL (Ted Kemp, “FDIC Mandate Boosts Data Quality in
World’s Largest XBRL Project,” Intelligent Enterprise,
March 2006). From late 2005 through April 2006, XBRL was used
to file more than 10,000 company accounts with Companies House,
the U.K. agency responsible for collecting and publishing company
The Tokyo Stock Exchange (TSE) announced in April 2006 that it
was introducing an XBRL reporting system because the exchange
believes that consumers of financial information will find XBRL
useful for receiving and analyzing corporate financial information
Numerous regulatory agencies and financial markets around the
world have mandated or recommended XBRL in the past few years,
and its usage is steadily growing.
is applied to a specific reporting context, the core components
of the application compose what is termed a taxonomy. An XBRL
taxonomy encompasses the components that must be present to describe,
validate, relate, and process the data needed to create the final
reports (also known as XBRL instance documents). The relationship
between the taxonomy components is described in Exhibit
1, and each individual component is described below. (For
a more in-depth description of the ongoing development of XBRL
taxonomy components, see www.xbrl.org/Taxonomies.)
XBRL taxonomy components include the schema, presentation linkbase,
calculation linkbase, definition linkbase, reference linkbase,
and label linkbase. Two additional items are the taxonomy extension,
which may be used to extend the base taxonomy, and the report
itself, which is referred to as the instance document.
An XBRL schema stores information about taxonomy elements and
their associated attributes. For example, one element from the
balance sheet would be Cash. The input data for this report would
be included in the instance document as <Cash>7000</Cash>
where the value is included between the opening and closing tags,
following typical XML format. But how is cash described in the
schema? It is included as an element with associated attributes.
A simplified element definition for Cash in the schema would be:
<element name=“Cash” id=“Cash” periodType=“instant”
type=”monetaryItemType”/>. The Cash element would
be named and given an identifier. Its use would be described—“instant”
is an element valued on a particular date as in a balance sheet,
and “duration” would be for elements describing monetary
flows such as revenue in an income statement. And the element’s
data type would follow. The schema would include an element definition,
with appropriate attributes and attribute values, for all items
necessary for a broad range of reporting purposes. Information
regarding financial reporting taxonomies and their associated
schema can be found at www.xbrl.org/TaxonomyGuidance/.
schema captures and defines reporting elements and their core
attributes, the linkbases are used to identify the different relationships
among elements or between elements and associated information.
linkbase. A presentation linkbase stores information
about relationships between elements in order to properly organize
the taxonomy content (www.iasb.org/xbrl/about_xbrl/fundamentals_xbrl.html).
This allows reports to be properly organized, indicating hierarchical
relationships between elements. For example, assets could include
current assets and other assets. And current assets could include
cash, inventory, and accounts receivable. Relationships in the
presentation linkbase can describe the parent-child nature of
associated elements. Instance documents may then be used to report
data at the required level of detail.
linkbase. A calculation linkbase is used to validate
calculations included in instance documents. For example, the
sum of lower-level elements must be equal to the higher-level
element. One limitation is that the verification can only take
place for elements that have the same value for the attribute
“periodType.” For example, calculations across income
statement and balance sheet items could not be validated through
linkbase. A definition linkbase provides taxonomy
creators with the opportunity to define different kinds of relations
between elements (www.iasb.org/xbrl/about_xbrl/fundamentals_xbrl.html).
One example would be to indicate that two elements have similar
would be to define a pair of elements that would require a user
to enter a value for both rather than only one. This enables XBRL
users to validate data in more complex situations than can be
handled by only the schema and other linkbases.
linkbase. Business and financial reports often include
items that are associated with an external regulation or standard.
A reference linkbase can be used to indicate the relationship
between elements and a source that describes the associated external
regulation or standard in more detail. For example, a balance
sheet could include a reference to the relevant guidance used
to determine inventory value.
linkbase. Because XBRL is intended to be a universal
standard, a label linkbase is included in an XBRL taxonomy to
match elements with labels in different languages. This enables
a common set of financial data to be utilized not only in a wide
range of reports but also in many jurisdictions, which is necessary
given the increasing globalization of business operations. For
example, the label linkbase would enable a financial report to
easily be displayed in Spanish as needed.
extension. Taxonomies are often developed according
to specific legislation or standards. A taxonomy extension allows
users to extend a taxonomy to be able to handle nonstandard reports
that may be required for internal use or for a unique external
This may involve adding a required element that is not included
in the base taxonomy, or modifying the relationship between elements.
While taxonomy extension is available, there are some limitations,
such as requiring that no extensions physically modify the base
taxonomy. Such changes could create unanticipated problems with
existing reports that use the base taxonomy.
document. Finally, the instance document includes
the element tags and the values used for creating a business or
financial report that fulfills the syntax, relationships, and
other validation measures included in the appropriate taxonomy.
A web browser with the appropriate software installed can be used
to display the instance document as a report that that has been
validated against the associated taxonomy.
time of early mainframe-based management reporting systems to
today’s data warehouses, one of the major objectives for
information-systems developers and users was, and still is, to
improve data quality. This is an increasingly important objective
because organizations are collecting more data than ever before,
and the potential value of this data to decision makers is increasing.
Improving data quality is not a simple task; data quality is composed
of a number of dimensions that each fall into one of the aforementioned
four categories: intrinsic data quality, accessibility data quality,
contextual data quality, and representational data quality (Diane
M. Strong, Yang W. Lee, and Richard Y. Wang, “Data Quality
in Context,” Communications of the ACM, May 1997).
The dimensions of data quality included in each category are shown
goes far beyond the accuracy of collected data. In an accounting
context, it is not enough to have accurate numbers for income
statement and balance sheet items such as revenues and assets.
Systems that provide enhanced data quality must also be concerned
with ease of access, timeliness, and concise and consistent representations.
Financial reports must be easily and quickly accessed and distributed.
The data must be available when needed, at the proper level of
detail, and the representation must be consistent and follow relevant
laws and regulations.
complexity of proper financial reporting and the associated importance
of data quality in financial reporting systems, the question that
must be addressed is whether XBRL provides a solution. Does XBRL
benefit all dimensions of data quality, or are there limits to
and Data Quality
3 identifies the data quality categories affected by each
XBRL taxonomy component.
data quality. The impact of XBRL on intrinsic data
quality is somewhat limited. The calculation linkbase may improve
verification of calculations based on the input data, but the
ability of XBRL to verify input data accuracy or bias is limited.
The old saying “garbage in, garbage out” still applies.
If accountants do not accurately determine a value for items such
as assets or revenues, or if they bias a value to achieve a certain
outcome, there is no guarantee that an XBRL component would be
able to catch it.
data quality. Accessibility has two dimensions:
ease of access, and access security. XBRL is capable of providing
easy access to financial reports if they are in the appropriate
format, such as in a valid instance document, but its ability
to provide access security is limited. XBRL documents can be easily
distributed and viewed on standard web browsers with the appropriate
plug-in. Security is left to other components of the overall information
data quality. Contextual data quality is enhanced
by the schema and presentation linkbases. The schema provides
complete descriptions of data items at both detailed and summarized
levels, along with their attributes. Presentation linkbases provide
a description of the relationship between these data. These two
XBRL components enable the quick production of reports that are
complete, include the right amount of data, and are relevant to
the user. Timeliness is enhanced because the XBRL application
runs on a standard Internet infrastructure that is used by many
data quality. The reference and label linkbases
enhance representational data quality for financial reporting.
They provide concise, consistent reports that are displayed using
standard browser technology. References to external regulations
can be linked to reports and the appropriate report labels can
be displayed, depending on user needs.
In addition to the four categories of data quality discussed above,
an additional system-level quality is the extent to which an application
allows for extension (modification) for new uses. XBRL does provide
a financial reporting system that can be readily extended to new
reporting uses. The definition linkbase and taxonomy extension
components enable users to define new element relationships, add
new elements, or modify element relationships to provide unique
reports required by regulators or needed for internal purposes.
This provides a robust system that can evolve as user requirements
development of XBRL has created a number of issues that must be
addressed by commercial organizations and government agencies.
First, for an XBRL implementation project, how should return on
investment be determined? What costs are relevant, and how can
the long-term benefits be quantified? (See Bryan Bergeron’s
Essentials of XBRL for a discussion of the ROI issue.)
Second, once the decision has been made to implement XBRL, what
is the proper conversion process, given that a financial reporting
system must be available at all times? The current (legacy) financial
reporting system will likely be run parallel to the XBRL system.
The third organizational issue is how to train employees affected
by the conversion to XBRL. Given how new XBRL is, few employees
currently involved in business and financial reporting will have
the skills necessary to easily work in the new environment. One
solution to consider is outsourcing the implementation work, the
financial reporting system, or both. If a number of organizations
determine outsourcing as the best course of action, then a tremendous
opportunity will be created for consulting companies to provide
these services. Universities might also start training current
accounting and information systems students to prepare them for
jobs that will involve XBRL implementation and use.
agencies and public policy decision makers, the key question is
to determine what role they should play in the conversion to a
mandated XBRL-based financial reporting environment. XBRL can
benefit citizens through improvements in collection and dissemination
of business and financial data. Should public money be used to
jump-start the conversion to XBRL-based financial reporting? Or
should it be left solely to the organizations required to use
XBRL? XBRL implementation may be similar to the expansion of the
Internet. Public money may be necessary to jump-start the project,
but private funding will grow as the system becomes fully implemented.
considered to be the father of XBRL, has identified additional
issues that must be addressed before CPAs begin using XBRL en
masse (Robert Tie, “XBRL: It’s Unstoppable,”
Journal of Accountancy, August 2005). He believes that
XBRL software will have to become more user-friendly for the average
CPA, and it will have to make mission-critical applications better,
faster, or cheaper.
financial reporting requires nontechnological and technological
solutions. SOX and related legislation focus on improving accuracy
and minimizing bias in the financial data that is entered into
financial reporting information systems. And XBRL, combined with
web browsing technology and appropriate system security, provides
one potential solution for enhancing the other dimensions of data
quality. XBRL development and implementation will take time, but
it will be worth the effort if it contributes to improved financial
J. Strader, PhD, is an associate professor of information
systems in the college of business and public administration at
Drake University, Des Moines, Iowa.