ShareThis

FINANCIAL REPORTING / TECHNOLOGY

Avoiding Common Errors of XBRL Implementation

By Jon Bartley, CPA, Ph.D., Y.S. Al Chen, CPA, Ph.D. and Eileen Taylor, CPA, Ph.D.

FEBRUARY 2010

Following three years of voluntary XBRL submissions, the SEC’s mandatory requirements for XBRL financial report submissions began phasing in June 15, 2009. As with any new process, companies can easily underestimate the challenges posed by this complex reporting technology and make mistakes along the way.

This article describes common errors appearing in Voluntary Filing Program (VFP) Forms 10-K that continue to occur under the SEC’s mandatory Form 10-Q submissions and discusses how they can be prevented. CPAs can use this information to develop expectations about the challenges of XBRL document preparation and of performing agreed-upon procedures engagements. It is especially important for companies to be aware of these potential errors, because the errors occur not only in filings prepared in-house, but also in filings prepared by third-party financial printers. Regardless of who prepares the filings, the company is ultimately responsible for the documents’ accuracy.

Despite the prevalence of these errors, significant improvements have been made in XBRL creation tools, the U.S. GAAP Taxonomy and in software validation tools.

In the future, we expect many companies to integrate XBRL and their automated accounting information systems (AIS) enabling the AIS to directly produce the XBRL instance documents and eliminating many types of errors. However, almost all companies currently prepare XBRL documents using a bolt-on process that follows the traditional preparation of financial statements in ASCII or HTML format. This manual data transformation process is a significant source of the errors we observed in XBRL documents.

METHODOLOGY

To gain better insight into the challenges new filers faced, we examined the filings of the first 22 U.S. companies that submitted relatively complete XBRL-formatted 10-K financial statements in 2006 as part of the SEC’s VFP. As part of a major research initiative undertaken at North Carolina State University examining issues related to XBRL financial statement documents, we examined the XBRL documents and compared each to the original Form 10-K. We noted differences in amounts, signs, presentation, labeling, classification, etc. To examine how accuracy improved with experience and with the intervening improvements in XBRL software and the XBRL U.S. GAAP Taxonomy, we repeated our examination in 2008 for the 11 companies that filed XBRL 10-K documents continually from 2006 to 2008. We base our discussion on these results and the preliminary observations of the SEC staff regarding errors identified in the submissions of XBRL 10-Q reports of the first registrants (approximately 500) required to file XBRL documents for the second and third quarters of 2009. (SEC observations are available here.)

The XBRL 2006 and 2008 voluntary 10-K submissions of almost all companies examined contained significant errors that would not be acceptable under the SEC’s rules for mandatory submissions. These errors occurred in various steps of the process including mapping, extension, tagging, and creating and validating. Exhibit 1 identifies the types of errors that occurred. The SEC staff observations from a review of initial XBRL 10-Q submissions indicate that accuracy has improved significantly, but many companies are still making the same errors we observed in the voluntary submissions. Fortunately, companies that make a good-faith effort to comply with XBRL requirements and correct errors within 24 hours of discovery are protected from legal liability by the SEC’s safe harbor provision during the first two years of submissions.

We identified these errors by comparing financial statements rendered by the SEC’s Interactive Financial Report Viewer software to the official Form 10-K and then tracing apparent errors to the underlying XBRL document containing the computer code. We defined errors as violations of basic XBRL principles in effect at the date of the document submission. At present, the SEC’s final rule and the EDGAR Filer Manual govern the content of XBRL data files, while the XBRL US GAAP Taxonomy Preparers Guide provides detailed instructions for the construction of instance documents containing the computer-readable code that represents a company’s specific taxonomy of elements, business facts and financial relationships.

We will use the four major steps involved in preparing XBRL documents to organize the discussion of the most common errors that were observed (see Exhibit 1).

MAPPING ERRORS

Mapping is the process of identifying and matching every accounting concept and the related amount in a company’s financial statements to the appropriate financial statement element in the XBRL U.S. GAAP Taxonomy. Companies made numerous mapping errors, which are among the most serious because they distort the meaning of the data that are downloaded into analytical software. Financial statement concepts that have been matched with incorrect XBRL elements may be impossible for users to detect without detailed comparisons of the XBRL elements to the original financial statements and notes.

Examples. An accountant must choose from more than 50 “Interest Income” elements or more than 20 “Cash and Cash Equivalents” elements. The fineness of the GAAP taxonomy makes errors likely unless the accountant doing the mapping is very familiar with the company’s financial reporting and with the taxonomy. Companies in the VFP often repeated mapping errors because the initial XBRL documents the company created were used as a template for future documents, leading to repetitive errors.

Several forms of mapping errors continue to be observed under the SEC mandate. The SEC staff’s observations refer to this matter as “element selection.” Filers have used standard elements in the taxonomy that are either too broad or too narrow to accurately correspond to the actual financial statement concept. For example, the filer selects the element “Inventory, Finished Goods” when a more narrow standard element, “Energy Related Inventory, Petroleum,” is available to more accurately capture the meaning of the underlying financial statement concept.

A common and generally more serious mapping error is the creation of unnecessary, new elements that “extend” the U.S. GAAP Taxonomy. This occurs when a preparer fails to locate the correct element in the taxonomy and creates a new unique element for a financial statement concept. We also observed the unnecessary creation of new duplicate elements when a single concept appears in more than one location in the financial statements. For example, when preferred dividends appear in the statements of income, cash flows and stockholders’ equity, the correct mapping for all three locations is to the standard element in the U.S. GAAP Taxonomy for “Dividends, Preferred Stock, Cash.” XBRL provides the coding to display a single element in multiple locations with differing labels when appropriate.

The flexibility of creating unique elements is one of XBRL’s strengths, and may appear harmless. However, analytical software recognizes only the standard elements in the U.S. GAAP Taxonomy so every unique element requires some level of manual interpretation by interactive users. In addition, companies are much more likely to make extension and tagging errors for unique elements because they must enter all of the information that is otherwise provided automatically for XBRL for standard elements—for example, data type, period type, debit or credit balance, definition and label.

The key is creating new elements through the extension process only when a financial statement concept is not included in the standard taxonomy. Companies may request that XBRL US add new elements to the official taxonomy through the public comment process followed for all new versions of the taxonomy.

Solution. Although commercial software is available to assist with mapping, human judgment is essential. The taxonomy contains approximately 17,000 elements. Because of the high level of detail (fineness) of the taxonomy, a precise understanding of a company’s accounting concepts and of the U.S. GAAP Taxonomy is required to ensure that the mapping is correct. The critical step for avoiding mapping errors is to train and assign experienced, knowledgeable accountants to perform and verify the mapping.

Mapping Tips

Use the following tips for mapping financial statement concepts to the XBRL U.S. GAAP Taxonomy:

Examine the official element definitions carefully; however, the XBRL definitions themselves are not authoritative so exact correspondence between the financial statement concept and the XBRL definition is not required.
Select the element with the narrowest definition that fits the concept.
Use standard elements in the U.S. GAAP Taxonomy that correspond to the accounting concepts even if the elements are located within a different industry or within a different financial statement grouping in the taxonomy.
Check for misspelled search terms or terms that do not correspond to the taxonomy because they may prevent mapping software from identifying the correct element in the taxonomy.

EXTENSION ERRORS

The extension process creates new XBRL elements in the taxonomy containing the essential information necessary to create a company’s unique financial statements. This computer code is complex, and thus far, most companies have relied on third-party outsourcers that perform the extension process. The XBRL code allows a company to control or establish:

Unique presentation labels for elements.
The location of elements within the financial statements including multiple locations.
Mathematical relationships that allow the sum of amounts within a related group to be validated. For example, the amounts of the elements in the current asset group should sum to the amount entered for the current asset subtotal.
Other information necessary to create the formal structure of a specific company’s financial statements. For example, display labels such as “Current Assets” that are not attached to an element.

Extension errors often cause serious errors in financial statements, and they can distort the interpretation of XBRL data input into analytical software.

We found numerous extension errors in the VFP submissions. These errors are much less common in the first Form 10-Q mandatory filings, but they remain an area of concern especially as companies begin the detailed XBRL coding of footnotes. Further, the roll-forward process used to create XBRL documents can allow these errors to persist year after year if they go undetected.

Examples. Common extension errors made in the VFP include:

Financial statement elements that are presented in incorrect order or are included in the wrong financial statement, for example, an income statement element is inserted into the balance sheet.
Groups of elements that do not sum to their subtotal or total.
Failure to create presentation labels for elements that replicate those in the original financial statements.

Solution. The extension process is inherently difficult because of the variety of financial statement formats and the complexity of the XBRL code controlling the description and presentation of the elements. First and foremost, the XBRL extension process should be performed by an individual with a high level of knowledge regarding the application of XBRL code and the software that is being used to generate the code.

Accountants should use tools such as the SEC’s Previewer and validation software to verify that the extension documents meet the SEC’s technical requirements. However, validation software will not detect all errors. For example, a failure to establish mathematical relationships during the extension process will allow many types of errors to go undetected by validation software. Further, XBRL code cannot establish all relevant mathematical relationships for some tabular presentations so that validation software may not detect all data-entry errors even when accountants perform the extension process correctly.

Although there is a strong preference for exact correspondence between the labels in the original Form 10-K and those in the XBRL documents, the SEC rules require only that the information content of the XBRL labels be the same as the original labels. Thus, companies have the option of using the default presentation labels in the U.S. GAAP Taxonomy. The use of default labels is an inferior practice because inconsistencies between the original financial statements and XBRL-rendered statements may confuse users. A more serious problem arises when the financial statement format requires negating labels such as “less accumulated amortization,” and the company uses the standard label that does not include the qualifier “less.” We recommend using the extension process to create presentation labels that exactly replicate those in the original financial statements.

Finally, it is essential that a professional who has a deep understanding of accounting concepts carefully trace every element amount and description in the rendered financial statements from the XBRL code back to the original financial statements.

TAGGING ERRORS

Tagging is the process of entering both numerical and textual data for financial statement elements including dollar amounts, signs, time periods and units of measurement. Tagging errors are less common than mapping and extension errors, but they are serious because the erroneous data distort both the rendered financial statements and data downloaded into analytical software.

Examples. Companies in the VFP made a variety of tagging errors, including straightforward data-entry errors, or more commonly, tagging elements with the incorrect time period, incorrect sign or incorrect rounding. Although accuracy has improved due to improved validation software and an improved negating sign feature in XBRL, incorrect signs remain a problem in the mandatory 10-Q submissions.

Sign errors generally occur for reasons other than a simple keystroke error. Correctly tagging signs is complex due to the distinction between “debit” and “credit” element values and the fact that a value may be either a positive or a negative depending on its location and description in the financial statements. XBRL principles require the assignment of positive signs to all elements having values consistent with their natural debit or credit balance, but some elements lack a natural balance, for example, the changes in working capital accounts presented in a statement of cash flows. Further, signs established when amounts are entered in the tagging process may require manipulation in the extension process in order to achieve correct presentation in the rendered financial statements.

Solution. Accountants can detect keystroke errors with traditional methods such as double-entry validation procedures. They also may detect keystroke and other tagging errors with validation software if they use the extension process correctly to establish as many mathematical relationships as possible among financial statement elements. This allows validation software to check many amounts for mathematical accuracy. Of course, offsetting errors will not be detected, and some financial statement elements are not part of any total that can be tested. A careful tracing of original financial statement data to the rendered XBRL statements will detect many, but not all, tagging errors.

Oversight by knowledgeable accountants with high levels of familiarity with the company’s financial statement format, familiarity with the natural balance of elements and an understanding of the XBRL extension process is the most effective tool against errors. Elements that have no natural balance should be assigned a sign based on information provided in XBRL definitions of each element. When a financial statement label requires that an amount be presented with a sign that is inconsistent with the sign of the element, the negating sign feature of XBRL is applied in the extension process, causing the element to be presented with the opposite sign in the specified locations. For example, a financial concept such as a gain on sale is represented by a single XBRL element with a positive sign (natural credit balance), and the extension process is used to control its sign when the gain appears as a negative amount in the operating cash flow section of the statement of cash flows.

CREATING AND VALIDATING THE XBRL INSTANCE DOCUMENTS

The final steps in preparing XBRL interactive data for submission to the SEC are the creation and final validation of the XBRL instance documents containing all of the tagged financial statement elements and related presentation information. The final creation of the documents is a straightforward technical process. The failure to conduct adequate software validation and a manual validation allows many of the errors we observed in the VFP submissions to go undetected.

Validation software automatically reviews and identifies most, but not all, violations of XBRL standards. It verifies mathematical accuracy when the extension process has established the mathematical relationships among the financial statement elements and their totals; however, as noted earlier, XBRL currently cannot specify all financial relationships in the statements. Preparers should conduct software validations with both their third-party software and with validation software that is available on the SEC’s Web site.

After conducting the software validation, preparers should upload the instance documents to the SEC’s online system where preparers can privately preview the financial statements as rendered by the SEC’s Previewer software.

We recommend that an experienced accountant conduct a detailed tracing of every element, its label and presentation from the rendered statements to the source document (10-K or other official financial report).

The internal assurance process is iterative and should occur continually throughout the preparation of the instance documents. Errors tend to accumulate and trigger additional errors, so waiting until the instance documents are complete to begin validation will make the validation and correction process more difficult.

XBRL in the United States

The U.S. GAAP Taxonomy is a structured list of financial accounting concepts with the associated computer codes for use in XBRL documents. The SEC contracts with XBRL US Inc. to prepare and maintain the current taxonomy. XBRL US originated from an XBRL committee established by the AICPA in 1998. The organization is a member of XBRL International Inc., a consortium of more than 550 companies, organizations and government agencies.

The Attestation Process and XBRL

The SEC final rule does not require attestation of XBRL submissions, and it specifically states that auditors are not required to apply AU section 550, Other Information in Documents Containing Audited Financial Statements; AU section 722, Interim Financial Information; or AU section 711, Filings Under Federal Securities Statutes (AICPA, Professional Standards, vol. 1). The rule states that issuers can obtain third-party assurance voluntarily, if they choose. Anticipating CPA involvement, the AICPA issued SOP 09-1, Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data, in April 2009.

A Strong Process for Preparing XBRL Docs

A firm should take the following steps to create a strong process for the preparation of XBRL documents:

Educate management that ownership of XBRL submissions belongs to the company, not the outsourcer.
Educate management that this is an accounting and reporting process, not an IT process.
Make clear assignment of responsibility, for example, to the controller’s office, external reporting team, etc.
Use consultants to assist with complex technical issues even if preparation is in-house rather than outsourced.
Prepare a detailed plan that enables preparation to occur in lock step with the manual filing process.
Establish and monitor controls over both internal and external processes.
Provide adequate training to internal experts especially if preparation is inhouse.
Start early and conduct a practice preparation before the first submission.
Have more than one internal expert involved in the mapping and review processes and do not rely solely on software validation.
Validate at all stages of the process to avoid compounding errors and test XBRL documents before submission using the SEC Previewer and validation software.
Allow adequate time for final changes and reviews, especially if you expect last-minute changes in the manual documents before submission.
Document the XBRL process and choices carefully, especially the basis for mapping accounting concepts to particular elements.
Finally, be prepared for increased effort when the company begins submitting detailed coding of footnotes, which will more than double the number of financial statement concepts and corresponding XBRL elements.

EXECUTIVE SUMMARY

All public companies with filing periods ending on or after June 15, 2011, will be required to submit financial statement documents in XBRL format to the SEC as part of three phases, which started with large accelerated GAAP filers with fiscal periods ending on or after June 15, 2009. The move is expected to provide greater transparency and quicker dissemination of financial information.

Although attestation is not required, CPAs can expect to be involved in XBRL document preparation.

Companies made a variety of errors in XBRL submissions during the SEC’s Voluntary Filing Program and in the initial mandatory Form 10-Q submissions in 2009, suggesting that the difficulty of complying with the SEC’s XBRL submission requirements has been underestimated.

CPAs can expect the greatest challenges in the first year when coding the four basic financial statements in detail and in the second year when coding the financial statement notes in detail.

This article describes the significant errors that have been most common, and it identifies the resources and strategies that CPAs can use to eliminate errors in XBRL submissions.

Jon Bartley (jon_bartley@ncsu.edu) and Y.S. Al Chen (al_chen@ncsu.edu) are professors of accounting at North Carolina State University. Eileen Taylor (eileen_taylor@ncsu.edu) is an assistant professor at North Carolina State University.

To comment on this article or to suggest an idea for another article, contact Alexandra DeFelice, senior editor, at 212-596-6122 or adefelice@aicpa.org.

AICPA RESOURCES

JofA articles