|
|
Total Number of Subscribers: 467 |
|
|
|
||
|
|
||
|
Date:9th January 2009 |
Compiled by Mr. M. Sathya Kumar |
|
|
|
XBRL Capabilities
and Limitations 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. One information 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. Extensible 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). XBRL 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. Many XBRL 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 data (www.xbrl.org/Announcements/UK-CH-25April2006.htm). 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 (www.xbrl.org/Announcements/TSE-27April2006.htm). 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. When XBRL 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. Schema. 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: While the 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. Presentation 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. Calculation 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 this linkbase. Definition 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 meanings. Another 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. Reference 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. Label 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. Taxonomy 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
purpose (www.iasb.org/xbrl/about_xbrl/fundamentals_xbrl.html). 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. Instance 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. Data Quality From the 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 in Exhibit
2. Data quality 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. Given the 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 its
impact? XBRL and Data Quality Exhibit
3 identifies the data quality categories affected by each XBRL
taxonomy component. Intrinsic 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. Accessibility 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 system. Contextual 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 organizations. Representational 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. Extensibility. 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 change. Organizational Implications The ongoing 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. For regulatory 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. Future Prospects Charles Hoffman, 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. Improving 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 reporting. Article by Troy J.
Strader, PhD, is an associate professor of information
systems in the college of business and public administration at Drake
University, Des Moines, Iowa. |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
Rewards waiting for feedback at |
|
|
|
|
|
|
|
||
|
|
|
|
|
|
Disclaimer: We believe that the information contained in this e-zine is true. If you do not wish to receive Smart Trainee please click here. |
|
|
|
||
|
|
|
|
|
|
Click here to contact us, if you are unable to view the content properly |
|
|
|
|
|
