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 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.
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 (email@example.com) and Y.S. Al Chen (firstname.lastname@example.org) are professors of accounting at North Carolina State University. Eileen Taylor (email@example.com) 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 firstname.lastname@example.org.
Use journalofaccountancy.com to find past articles. In the search box, click “Open Advanced Search” and then search by title.
XBRL—Preparing for Phase II and Detailed Tagging (taking place Jan. 27)
SOP 09-1, Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data