XBRL Capabilities and Limitations

By Troy J. Strader

E-mail Story Print Story

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:
<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/.

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.

©2009 The New York State Society of CPAs. Legal Notices