A Comparison of XBRL Filings to Corporate 10-Ks -

Evidence from the Voluntary Filing Program

Jon Bartley, Ph.D.

Department of Accounting
College of Management
North Carolina State University
Campus Box 8113, Nelson Hall
Raleigh, NC 27695
Telephone: 919-515-4441
e-mail: jon_bartley@ncsu.edu

Al Y. S. Chen, Ph.D.
Department of Accounting
College of Management
North Carolina State University
Campus Box 8113, Nelson Hall
Raleigh, NC 27695
Telephone: 919-515-4437
e-mail: al_chen@ncsu.edu

Eileen Z. Taylor, Ph.D.*

Department of Accounting
College of Management
North Carolina State University
Campus Box 8113, Nelson Hall
Raleigh, NC 27695
Telephone: 919-513-2476
e-mail: eileen_taylor@ncsu.edu

Revision 2/17/2010

*Contact Author

For their helpful comments, thank you to Eric Cohen, PriceWaterhouseCoopers, participants in a
workshop at North Carolina State University, reviewers for the 2009 AAA Annual Meeting and other
anonymous reviewers. We especially thank Brad Homer, XBRL Technical Manager AICPA, for spending
time teaching us about the technical aspects of XBRL.

Electronic copy available at: http://ssrn.com/abstract=1397658

 A Comparison of XBRL Filings to Corporate 10-Ks -
Evidence from the Voluntary Filing Program

Abstract
The SEC phase-in of XBRL financial statement filings began June 2009, and by 2011, all
public registrants will be required to file XBRL disclosures. While the SEC expects the
interactivity of XBRL-tagged data to add value to financial reports, this benefit will materialize
only if the XBRL statements are accurate and reliable. If inaccuracies or other significant
problems occur in initial XBRL filings, registrants stand to lose credibility and users will lose
confidence in the data, potentially forcing the abandonment of the XBRL reporting initiative.
This study evaluates the accuracy of early voluntary filings and develops an expectation about
the accuracy of mandated filings. While improvements in the XBRL standard and related
technology will mitigate certain errors, other errors, related to inexperience, will persist. This
study identifies those errors and makes recommendations about how to reduce experience-related
errors.

Electronic copy available at: http://ssrn.com/abstract=1397658

 A Comparison of XBRL Filings to Corporate 10-Ks -
Evidence from the Voluntary Filing Program

INTRODUCTION

In December 2008, the Securities and Exchange Commission adopted Interactive Data to

Improve Financial Reporting (SEC, 2009) mandating the phase-in of supplemental filings of

financial statements using eXtensible Business Reporting Language (XBRL) during the 2009-

2011 period. The SEC continues to rely on HTML and PDF formats for registrants’ official

filings, however, it is apparent that the SEC hopes that the mandated extension of supplemental

XBRL filings will demonstrate that interactive data adds value to financial reports and can

replace HTML and PDF documents for official filings. For this transition to occur, XBRL filings

must be accurate, reliable, and cost effective. The SEC’s expansion of supplemental XBRL filing

requirements to essentially all public registrants is not without risks. If inaccuracies or other

significant problems occur in initial XBRL filings, registrants stand to lose credibility and users

will lose confidence in the data potentially forcing the abandonment of the XBRL reporting

initiative.

XBRL provides data in an interactive,1 context-rich format that users can download

directly into analytical software. In contrast, the current official filings are static documents that

require users to rekey data before using them in electronic analysis. The advantages of XBRL

have been widely demonstrated for documents prepared in standardized, form-based formats, but

1
The term “interactive” means that the data are electronic and tagged with computer-readable code that can provide
rich information about the context and value of financial statement concepts.
the practicality of extending XBRL filing requirements to much less standardized documents

such as the Form 10-K remains untested.

In 2005, the SEC initiated the XBRL Voluntary Financial Reporting Program on the

EDGAR System (SEC, 2005), better known as the Voluntary Filing Program (VFP). In order to

explore the potential application of XBRL to U.S. corporate financial reporting, the SEC invited

public-company registrants to experiment with XBRL data tagging2 and to file the resulting

XBRL documents online. Our study identifies errors that companies made in their voluntary

filings and thus may make in their mandatory filings, and whenever possible we point out the

likely sources of the errors and propose solutions.3

Even though a safe harbor provision greatly reduced participants’ risk of legal liability

for errors in XBRL documents filed in the VFP, fewer than 40 companies participated in the first

full year, 2006; and through 2008, approximately 125 companies had participated. The SEC

collected comments from VFP participants and other parties involved in the process, and as a

result, major improvements occurred during the 2005-2008 period. Unfortunately, the SEC never

published any systematic analyses of XBRL data accuracy or its use by financial analysts’ and

investors. Our study seeks to fill that gap.

In order to provide systematic information about the problems that companies currently

confront in producing accurate XBRL documents, we evaluated the accuracy of initial and

2
Tagging is the process of assigning XBRL computer codes to financial information.
3
Our study does not examine all types of errors that can occur in XBRL documents. In particular, we do not report
on the types of XBRL syntax errors routinely identified by validation software. Validation software does not detect
many types of potentially material errors that can be detected by the direct comparisions we make of XBRL
rendered financial statements to the corresponding audited financial statements submitted to the SEC. For studies of
errors detected by validation software, see Boritz and No (2009) and Boritz and No (2008).
2
subsequent filings of XBRL instance documents4 by companies participating in the SEC’s VFP.

We extend these results by comparing them to the initial observations of the SEC staff regarding

errors observed in the first Form 10-Qs filed in 2009 in compliance with the new mandatory

XBRL filing requirements. We emphasize that the XBRL filings in both the VFP and the

mandatory program are unaudited and that participants are subject to limited liability regarding

inaccuracies. While using the term “filed,” the SEC considers XBRL documents as “furnished

not filed,” so there is a clear distinction between these supplemental documents and the official

filed documents for which registrants are subject of many more legal requirements (SEC, 2005).5

The absence of a requirement for third-party assurance and the limitation of legal liability may

have reduced the motivation of VFP participants to provide error-free XBRL documents.

However, the SEC clearly stated in the VFP rule that “…XBRL exhibits will be required to

accurately reflect the information that appears in the corresponding part of the official filing”

(SEC, 2005). Although we recognize that the main purpose of the VFP was to generate feedback

about the process of XBRL tagging rather than the accuracy of the final product, accuracy cannot

be ignored as it was explicitly required by the VFP rule, and accuracy is of paramount

importance to the ultimate success of XBRL for financial reporting.

4
An XBRL instance document is a computer file containing the computer readable tags that are representations of
financial information contained in a company’s financial statements. The instance document is intended for input to
computer software rather than to be read directly by people. The instance document consists of six interrelated
computer files: taxonomy of the company’s financial statement elements and five files known as linkbases
containing the labels, calculations, references, definitions, and financial statement structure associated with the
financial statements. See Appendix A and Plumlee and Plumlee (2008) for more detailed descriptions of instance
document structure and preparation.
5
In keeping with the SEC’s continued use of the traditional terms “filed” and “filing” to refer to the submission of
XBRL documents that are legally “furnished,” we also use the terms “filed” and “filing.”
3
 We detected numerous errors and inconsistencies in the 2006 voluntary filings, including

missing financial statement elements, incorrect amounts, incorrect signs, duplicate elements,

financial statement concepts not tagged with the appropriate elements, and inaccuracies in the

display of the financial statements. The number of errors that we could systematically document

was much less in 2008 than in 2006, but errors persisted even though most sample companies

had three years of experience preparing both quarterly and annual XBRL submissions to the

SEC. XBRL protocols are still works in progress, and most registrants will be filing XBRL

financial statement documents for the first time during the 2009-2011 phase-in period.

Limitations of XBRL protocols and the software used to create and validate XBRL documents

combine with weaknesses in companies’ processes of preparing those documents to threaten the

accuracy and reliability of these filings.6 Our results demonstrate the challenge of XBRL

implementation and suggest that companies must give substantial attention to the process of

preparing XBRL documents if they are to avoid unacceptable numbers of errors in their

submissions to the SEC.

We organize the remainder of this paper as follows. First, we present an overview of

XBRL reporting and the VFP. We then review the relevant XBRL literature and pose two

research questions to guide our study. Following this, we describe the research method, sample

companies, and the results of the research. The final section summarizes findings and provides

recommendations, describes limitations, and includes potential avenues for future research. The

appendix describes the process and challenges of XBRL tagging.

6
Janvrin and No (2009) conducted a field study of the XBRL Form 10-Q document preparation processes of five
companies in 2009. They found that these companies experienced significant difficulties and uncertainties in their
initial preparation of XBRL documents.
4
 Overview of XBRL
What is XBRL?

XBRL is a computer-based, free, and open standard used for tagging business-related

data (including financial statement concepts) with a broad set of relevant information. Preparers

electronically tag quantitative data with XBRL codes to comprise a standardized document

(dataset) that is computer readable and searchable. XBRL International, a nonprofit consortium

of over 550 companies, organizations, and government agencies develops the standards for

XBRL. Individual jurisdictions develop their own taxonomy7 of financial statement concepts,

rules, and guides for implementation. Under the auspices of the SEC, XBRL US (a nonprofit

consortium of corporations, public accounting firms, the AICPA, and other interested

organizations) manages this process in the United States. XBRL US originated from an XBRL

committee established by the AICPA in 1998.

Conceptually, XBRL financial report data are analogous to financial report data provided

by third-party aggregators such as Standard & Poor’s Compustat, but with a much greater level

of detail, representativeness, and usability. For example, the latest U.S. GAAP taxonomy

includes over 18,000 elements, compared to the several hundred that are typically available from

third-party aggregators.8 XBRL documents have the advantage of providing additional

contextual information such as definitions and references to authoritative literature, and perhaps

7
Taxonomies resemble dictionaries that provide computer tags that can be assigned to numerical and textual data
(the elements or concepts) in financial reports. These tags provide a wide range of information about each financial
statement element including definition, descriptive label, time period, unit of measurement, and mathematical
relationships between elements. The U.S. GAAP taxonomy is a comprehensive taxonomy of financial statement
elements representing the financial concepts appropriate for public registrants that apply U.S. GAAP.
8
Approximately 3,500 of the 18,000 XBRL elements in the most recent update of the taxonomy represent typical
financial statement line-items (XBRL US, Inc., 2008a). The SEC and XBRL US are attempting to expand the U.S.
GAAP taxonomy so that companies rarely will need to create new, unique elements.
5
more importantly, XBRL viewer software is available to render an accurate replica of the printed

financial statements including notes, and supporting schedules. In addition to surpassing third-

party aggregator data in the level of detail and usability, we expect XBRL documents eventually

will be more accurate because the companies themselves (as the original source) are responsible

for data tagging and submission.9

A Short History of XBRL in the U.S.

The SEC’s push for XBRL reporting began in 2004 when SEC Chairman William H.

Donaldson announced that the SEC was evaluating the benefits of interactive financial data for

official filings. In February 2005, the SEC initiated the XBRL Voluntary Filing Program (VFP)

(SEC, 2005), and XBRL US, Inc. released the initial US GAAP XBRL Taxonomy (XBRL US,

Inc., 2005). The VFP’s explicit purpose was “…allowing registrants, the Commission, and others

to test and evaluate tagging technology.” In 2006, the SEC contracted with XBRL US to

complete the U.S. GAAP Taxonomies 1.0 (XBRL US, Inc., 2008a)and a Preparers Guide (XBRL

US, Inc., 2008b); both released in 2008. XBRL US continues to update and release authoritative

documents on an annual basis under contract with the SEC. The formal comment letters and

recommendations by VFP participants and other interested parties provide useful input for

improving XBRL and the expanding the U.S. GAAP taxonomy, but there has been little

published research examining the reliability and accuracy of XBRL filings.

9
Although most companies currently are outsourcing a significant portion of XBRL instance document creation
process, their personnel should be involved with the selection of elements from the GAAP taxonomy (i.e., the
mapping of financial statement concepts to taxonomy elements) and in the validation of the final documents.
Phillips, Bahmanziari and Colvard (2008) identify the software tagging programs that have been used by
participants in the VFP, and they provide a simple illustration of how the tagging process is accomplished.
6
 In early 2009, the Securities and Exchange Commission issued the final amendments to

its mandatory XBRL filing rules. Interactive Data to Improve Financial Reporting (SEC, 2009)

requires registrants that apply U.S. GAAP or International Financial Reporting Standards to file

supplemental XBRL documents in addition to the current HTML or PDF formatted filings for

Forms 10-Q, 10-K, and 8-K, among others. The rules took effect for Form 10-Q filings for

quarterly statements ending on or after June 15, 2009, for the approximately 500 accelerated

filers with a public float over $5 billion. The phase-in rules for all non-accelerated registrants

require XBRL submissions for fiscal periods ending on or after June 15, 2011. To support XBRL

reporting, the SEC upgraded its on-line EDGAR system in 2009 to facilitate easy viewing and

downloading of financial reports filed as XBRL documents. Registrants are required to post the

XBRL documents simultaneously on their company websites. In the initial year of filing,

registrants are required to tag every financial statement concept in the basic financial statements

and tag the footnotes and schedules as blocks of text. In subsequent years, they must individually

tag all financial statement concepts in footnotes and schedules as well.

Extending the limitation of liability provided in the VFP, the SEC provided a safe harbor

from specified anti-fraud provisions for a period of 24 months from the date a registrant is first

required to file XBRL documents (SEC, 2009). The safe harbor provisions require that a

registrant makes a good faith effort to comply with XBRL tagging requirements and correct any

failure within 24 hours after the company becomes aware of the failure. The inclusion of the safe

harbor provision signals the SEC’s recognition that XBRL implementation is still a work-in-

progress. At the time of this writing, it is unclear the extent to which the SEC will validate filings

and enforce corrections of errors.

7
 While the SEC has worked to ease XBRL adoption by not requiring third-party assurance

and by limiting liability for errors in XBRL filings, other forces exist that pressure registrants to

provide accurate and reliable statements. First, since XBRL filings are publicly available, errors

in those filings may damage the registrant’s reputation and cause investors to make decisions

based on inaccurate disclosures. Second, the SEC’s enforcement division expects to rely heavily

on interactive data to improve the efficiency and effectiveness of their analyses. Error-laden

XBRL filings will negatively affect their work, and perhaps result in unwarranted attention to

otherwise compliant registrants. Third, the SEC has a financial and political interest in the

success of XBRL making it likely the SEC will aggressively enforce the XBRL reporting

requirements.

LITERATURE REVIEW AND DEVELOPMENT OF RESEARCH QUESTIONS

About the same time as the VFP began, Debreceny, Chandra, and Cheh et al. (2005)

identified research issues whose investigation and results would “…guide preparers, users, and

regulators” in the process of XBRL financial reporting. They specifically mention the potential

errors that could occur in the complex task of creating the XBRL documents that describe all of a

company’s financial statement concepts and the related amounts (The appendix provides a

description of the process of preparing XBRL documents). Several studies have documented the

problem of errors when financial statement data are converted to a database format by third-party

aggregators (Yang, Vasarhelyi, & Liu, 2003; Kinney & Swanson, 1993; San Miguel, 1977).

Even with the assistance of data tagging software, the complexity of preparing XBRL documents

is much greater than that of populating any of the existing third-party databases.

8
 Although limited in scope and sample size, initial studies of XBRL VFP filings have

found evidence indicating that high numbers of errors have occurred. Following the guidance

provided by the PCAOB (2005) for attestation of XBRL documents, Boritz and No (2009)

performed a mock audit on the October, 2005, Form 10-Q XBRL filing for United Technologies

Corporation. One of the earliest filings, this 10-Q was selected because the XBRL documents

had been formally reviewed by PriceWaterhouseCoopers LLP.10 Although Bortiz and No

concluded through a manual tracing that the XBRL rendered document produced a complete and

accurate representation of the data in Form 10-Q, they were unable to comment on the fairness of

the presentation in accordance with GAAP. They found several problem areas including

redundant elements, inconsistent labels, missing totals, and misspellings.

Boritz and No (2008) extended their earlier research by using XBRL validation software

to evaluate filings for 304 quarterly and annual reports for 74 companies from the inception of

the VFP through December 31, 2007. This study did not attempt a manual validation due to the

sample size. They found that just under two-thirds of the filings contained errors in the XBRL

instance documents that were detected by validation software. While some of these validation

errors represented legitimate management disclosure choices (such as not reporting all

components of the net accounts receivable calculation), others represented inconsistencies that

could confuse users. Further, they found that over half of the elements included in the instance

documents were unique extensions of the U.S. GAAP taxonomy created by the registrants.

10
The most current guidance for attestation of XBRL documents is provided by Auditing Standards Board
Statement of Position 09-1: Performing Agreed-Upon Procedures Engagements That Address the Completeness,
Accuracy, and Consistency of XBRL-Tagged Data (Assurance Services Executive Committee (ASEC) XBRL
Assurance Task Force, 2009).
9
Although they did not comment on the appropriateness of these extensions, it is likely that at

least some were unnecessary. Additionally, Boritz and No found that the frequency of errors for

all validation tests increased each year from 2005 through 2007.

The Bortiz and No studies focused on errors identified by software validation tools

although they did perform a manual tracing in their first study. Plumlee and Plumlee (2008)

observed that software validation of the instance documents and the extension taxonomies cannot

identify all errors in XBRL documents, e.g., the appropriateness of the tag and the accuracy of

the value tagged. We extend the Bortiz and No work by conducting a side-by-side comparison of

XBRL rendered filings with the companies’ original Form 10-K, accessing the XBRL instance

document when necessary. Our manual approach enables us to identify errors that are

undetectable by validation software. Additionally, our longitudinal data set provides further

evidence about the effects of preparer experience on accuracy and reliability, with consideration

to improvements in XBRL technology and specifications. We also compare our findings to the

preliminary observations of the SEC staff about errors in the XBRL Form 10-Q documents filed

for the second and third quarters of 2009. When practical, we attempt to identify the likely

sources of the errors and pose recommendations for reducing them.

We design our study to answer the following research questions.

RQ1: What are the types and frequencies of errors made by companies participating in

the XBRL Voluntary Filing Program (VFP)?

10
 RQ2: Did the frequency of errors change between 2006 and 2008 as companies gained

experience with XBRL document preparation and improvements were made in XBRL

protocals and the U.S. GAAP taxonomy?

The answers to these research questions will assist companies, the SEC, and XBRL US in

identifying steps that they can take to improve compliance and accuracy. Our findings provide

insights about the challenges faced by companies preparing initial filings and bring to light the

importance of controls over the process. Since most SEC registrants have little or no experience

with XBRL tagging, we expect the types of errors that initial filers are likely to make will be

similar to those of the participants in the VFP after giving consideration to improvements in the

XBRL taxonomy and protocols and in the software used to create XBRL instance documents.

RESEARCH METHOD and SAMPLE COMPANIES

We identified errors in the XBRL Form 10-K documents filed with the SEC by

participants in the VFP for fiscal 2006 and 2008. Most initial participants in the VFP were

companies that one would expect to be motivated to make a serious effort to produce accurate

documents. Many participants are leading corporations that have a history of active participation

in standard setting for financial reporting, e.g., Dow Chemical, Ford, General Electric, IBM,

Microsoft, Pfizer, 3M, and Xerox. Others are companies whose business will be directly

benefited by the expansion of XBRL reporting, e.g., Adobe Systems, Bowne & Co., International

Securities Exchange, and RR Donnelley & Sons.

We obtained the 2006 sample by accessing the SEC web-based Interactive Financial

Reports Viewer and identifying all 26 companies that filed XBRL documents containing 10-K

11
financial statements ending in 2006. We excluded four companies resulting in a sample size of

22 companies (see Table 1).11 For 2008, we identified 11 of the 22 companies in the 2006 sample

that also filed 10-K XBRL documents in 2008. Limiting the 2008 sample to companies also in

the 2006 sample allows us to make better inferences about the effects of preparer experience

with XBRL on the accuracy of the instance documents.

(Insert Table 1 about here) – List of Sample Companies

We downloaded the related XBRL-rendered financial statements and the underlying

XBRL instance documents for the 22 (11) sample companies from the SEC website, and the

official 10-K filing for each company from EDGAR. We limited our analysis to the four basic

financial statements (income statement, balance sheet, statement of stockholders’ equity and

statement of cash flows). Only two companies in the sample attempted XBRL tagging of

significant amounts of other information such as footnotes, management discussion and analysis,

and executive compensation. The 2006 XBRL filings were evaluated relative to the 2005 version

of the commercial and industrial US GAAP Taxonomy (XBRL US, Inc., 2005), and the 2008

XBRL filings were evaluated relative to the 2008 version of the commercial and industrial US

GAAP Taxonomy (XBRL US, Inc., 2008a).12

Since the 10-K is the registrant’s original audited document and official filing, we assume

that it is always correct and that any difference between the 10-K and the XBRL rendered

11
South Financial Group Inc., EDGAR Online Inc., and ENGLOBAL Corp. either omitted some financial
statements or we were unable to access the complete set of XBRL instance documents. We excluded Satyam
Computer SVC because it is a foreign company.
12
General Electric was the only sample company that continued to use the 2005 version of the U.S. GAAP
taxonomy in its 2008 filings. All but one sample company used the commercial and industrial entry point of the
taxonomy. T. Rowe Price Group used the broker and dealers entry point.
12
document is an error in the XBRL filing.13 On a line-by-line basis, we compared labels, values,

and signs between the XBRL rendered financial statements and the 10-K. We traced most

differences between the two documents to the computer tags in the XBRL instance document in

order to determine the source of the difference.14 We also applied validation software (Fujisu

Taxonomy Editor) to help interpret the nature of the differences between the XBRL document

and the 10-K. With the exception of inconsequential labeling and formatting differences that are

permitted by the SEC, we recorded all differences between the XBRL rendered financial

statements and the Form 10-K.

Legitimate questions can be raised about whether the individual errors we document are

material. We provide commentary on our view of the significance of the errors, but we do not

attempt to classify them based on materiality. Plumlee and Plumlee (2008) observe that in the

context of an audit, the risk associated with a material misstatement may be unrelated to the size

of the item and that it is not known how the traditional concept of financial statement materiality

applies to XBRL documents.

Our manual tracing of differences between the 33 rendered XBRL financial statements

and the 10-Ks is a significant extension of this form of validation over what has been reported

previously in the accounting literature; however, practical considerations limit the extent of our

validation tests just as they have limited manual validation tests in prior XBRL research. It was

13
We thank an anonymous reviewer for pointing out that XBRL documents may provide a more accurate
description or formatting of data than the official Form 10-K. In this study, we presume that deviations from a
registrant’s 10-K disclosures are the appropriate basis for defining errors because of the SEC’s requirement that the
XBRL documents accurately represent the 10-K; however, we did not count obvious improvements in disclosure as
errors.
14
Label errors were so common that we chose not to trace all of them to their source.
13
not practical to devote the time necessary to perform a complete manual validation of every

financial statement concept in the 33 financial statements included in our study. Boritz and No

(2009) reported that it required approximately 63 hours to trace all of the concepts in a single

United Technologies Form 10-Q to the XBRL instance documents, and a Form 10-K has many

more financial statement concepts than a Form 10-Q for the same company.

Plumlee and Plumlee (2008) point out that the “agreeing” of the XBRL rendered

documents and the 10-K cannot detect all possible errors in the XBRL instance documents. In

particular, our methodology does not detect the XBRL syntax errors that Boritz and No (2008)

identified using validation software. Further, there are a variety of other serious errors that can

only be discovered by a manual validation of the computer tags of every financial statement

concept, not just for the tags of those elements whose rendering in the financial statements

differs from that in the 10-K . For example, our lack of detailed knowledge of a company’s

financial statement concepts makes it impractical to identify all the financial statement concepts

that appear to be labeled correctly but are tagged with an incorrect element in the U.S. GAAP

taxonomy. A related form of this error occurs when a company creates a unique company-

specific element even though an appropriate element to represent the financial statement concept

already exists in the U.S. GAAP taxonomy. Although these serious errors appear to be common

and we are able to identify a few obvious cases, we are unable to document what are potentially

much larger numbers of incorrect elements.

As we proceeded with the analysis, we identified six general categories of errors (see

Table 2). Table 3 summarizes the effects of each type of error on the XBRL data that will be

input into analytical software and on the display of the data when rendered as financial

14
statements. Table 3 also describes the ability of current software validation tools and of limited

manual validation as performed in this study to detect each type of error.

(Insert Tables 2 and 3 about here) Error Classification, Effects & Detection Methods

Two well-known types of errors identified in the databases of third-party data aggregators

appear in XBRL documents. These errors relate to mapping and data entry. Mapping errors occur

when there is a failure to match a financial statement concept with an appropriate element in the

database taxonomy, i.e., the financial statement concept is not described accurately in the

database. Third-party aggregators use their own judgment to consolidate and standardize

financial statement concepts to conform to their proprietary, pre-determined data fields. In the

case of XBRL, third-party judgments are avoided, but the company itself must make comparable

judgments to map its financial statement concepts to the elements in the U.S. GAAP taxonomy.

The taxonomy includes thousands of elements rather than the few hundred typical for third-party

aggregator databases. The more precise specification and fineness in the U.S. GAAP taxonomy

increase the likelihood that preparers find an exact (or very close) match for each financial

reporting concept, but the large number of choices also increases the possibility that the preparer

will select an incorrect element.

Data entry errors occur when a preparer enters incorrect data even though the accounting

concept is mapped to the correct element in the taxonomy. For third-party aggregators, data entry

errors are typically limited to transposition errors, dropped decimal places, sign errors, and

simple numerical transfer errors. Third-party aggregators can detect most of these data entry

errors by a simple rekeying of the data. Limiting data entry errors in XBRL documents is a much

greater challenge because of the large amount of descriptive information coded in the XBRL
15
instance document. Consider that in addition to its numerical amount; the attributes of an XBRL

element include the company’s unique label, the debit or credit balance type, the data type (e.g.,

monetary, text, shares, etc.), a definition, references to authoritative literature, and contextual

information that controls the display of the element in the rendered financial statements. For

standard elements in the U.S. GAAP taxonomy, this information is pre-coded, but for unique

elements (extensions), preparers must add the information. The complexity of XBRL protocols

and deficiencies in the XBRL tagging software can combine with coder inexperience to produce

a wide range of data entry errors in XBRL instance documents that a simple rekeying validation

cannot detect.

Other characteristics of XBRL are potential sources of errors not present in most third-

party aggregator-produced data. These issues relate to presentation and to compliance with

XBRL specifications (validation errors). While users rarely create printed financial statements

from third-party databases, users do expect to be able to render financial statements from XBRL

instance documents. Although presentation errors do not affect the underlying usability of the

individual data items, they do create differences between the printed 10-K and the rendered

XBRL document.15 These differences can cause user confusion and may reduce user confidence

in the accuracy and reliability of the data resulting in damage to the company’s reputation.

Complexities in the XBRL tagging and rendering software combined with coder inexperience

lead to errors in the accurate display of the original 10-K statements.

15
Although some XBRL advocates maintain that XBRL disclosures do not have financial statement presentation as
a primary objective, it is evident that accurate rendering of XBRL financial statements is essential for moving
beyond an inefficient and costly dual reporting system.
16
 Validation errors (not the focus of this study) occur when the XBRL documents do not

conform to XBRL protocols. Software tools are available to detect syntax errors in the XBRL

code and as well as to validate some mathematical relationships and other information in the

XBRL code. However, many serious errors such as tagging a financial statement concept with an

incorrect element are not detectable by validation software (see Table 3).

RESULTS

The XBRL filings we evaluated reveal the difficulties of accurate tagging of the basic

financial statements. In response to RQ1, we found that the frequency of errors is high for a

process that is fundamentally an electronic replication of information in the audited financial

statements (see Table 4 for frequency chart). We detected errors in the XBRL filings of all 22

companies in 2006 and 10 of 11 companies in 2008.16 The most common errors found in both

2006 and 2008 were display errors. In 2006, we also found many missing elements, sign flip

errors, incorrect amounts (including dates), duplicate elements, and incorrect elements. In

response to RQ2, we found that the frequencies of all errors other than display errors decreased

dramatically between 2006 and 2008 (see Table 4). Figures 1 and 2 present a visual comparison

of the decline in the average number of errors and in the percentage of companies making each

type of error between 2006 and 2008. The following sections of the paper describe our findings

for each type of error.

16
We detected no errors in the 2008 filing by IBM; however, we did not attempt to identify several types of errors
that may have existed. Similar to IBM, there were no differences between General Electric’s 2006 10-K financial
statements and the rendered XBRL financial statements. However, upon inspection of General Electric’s XBRL
documents, we observed that the company tagged a new element (either a standard element or a unique company
specific element) for every appearance of a concept in its financial statements in violation of XBRL specifications.

17
 (Insert Table 4 and Figures 1 and 2 about here)

Missing Elements

A missing element error occurs when a financial statement concept (generally each

unique concept in the financial statements) appears in the Form 10-K, but a corresponding

element is not included in the XBRL instance document. As noted in Table 3, these errors distort

both the underlying data and the display. We detected missing elements through a manual

comparison of the rendered XBRL document to the 10-K followed by examination of the

instance document to determine if the element was omitted (missing element) or simply not

displayed in the rendered financial statements (display error).

In 2006, two of 22 sample companies, United Technologies and Bristol-Myers Squibb,

omitted numerous financial statement elements. United Technologies omitted numerous financial

statement concepts in all four statements by combining related concepts into single elements. In

addition, United Technologies omitted all of the detailed changes in its statement of

stockholders’ equity reporting only total changes in each balance sheet account. In a similar

manner, Bristol-Myers Squibb omitted all of the detailed changes in comprehensive income. It is

likely that these omissions were the result of preparers making a conscious choice to simplify

XBRL document preparation in 2006 rather than commit errors in application of XBRL

protocols. Prior to 2008, limitations in the XBRL technology made it difficult to code the

instance documents to create an accurate display of the changes in stockholders’ equity. The

current version of XBRL includes a dimensions feature that reduces the difficulty of coding

tabular formats like those commonly found in the statement of stockholders’ equity.

18
 Improvements in XBRL technology appear to have eliminated the motivation for element

omissions in 2008. We detected only two element omissions that appear to be random. For

example, United Technologies failed to code an element for its total changes in comprehensive

income concept even though it correctly coded the detailed changes in comprehensive income

concepts. We do not expect that missing elements in the four basic financial statements will be a

problem in mandatory XBRL filings beginning in 2009 due to improvements in third-party

validation software and the availability of SEC viewer software that allows previewing of

statement display. However, random element omissions may become a significant problem if

companies fail to conduct detailed manual or electronic tracing between the XBRL documents

and the footnotes and schedules in the 10-K. Beginning in the second year of mandatory filing,

registrants will be required to include detailed tagging of footnote and supplemental schedule

concepts. Software validation of the calculations that are integral to the financial statements are a

primary means of detecting detection omitted elements, e.g., a test that the amounts of all asset

elements sum to the amount of total assets.17 Unfortunately, validation by calculation is not

applicable to most of the concepts that are contained in the footnotes.

Incorrect Amounts

Incorrect amounts, including dating errors, are very serious in any financial report. Some

errors of this type distort more than one-year’s data. For example, an erroneous date for a XBRL

element results in removing the element from the correct year’s financial statements and possibly

inserting the element and its amount in the comparative financial statements for a different year.

17
Boritz and No (2008) reported that software used to prepare and edit the XBRL documents was not always
capable of performing complete mathematical validation of the financial statements.
19
In 2006, four of 22 companies filed instance documents containing seven incorrect amounts of

which two were dates. For example, Microsoft erroneously reported two amounts as millions

rather than billions in its statement of stockholders’ equity. We observed no incorrect amount

errors in 2008.

The most likely source of an incorrect amount is a simple data keying error although

incorrect coding of other attributes may occur as well. Our results for 2008 suggest that these

data entry errors in the four basic financial statements should not be a significant problem from

2009 forward because most incorrect amounts can be detected by software validation of the

mathematical accuracy of the totals within the financial statements. However, manual validation

is necessary to validate amounts that are not included in a summation within the financial

statements. For example, the SEC reported observations of incorrect amounts for earnings per

share in the mandated 2009 10-Q filings, caused by use of the incorrect decimal attribute for the

amount (SEC, 2010).

Sign Flip Errors

Sign flip errors result from either incorrect coding of an element’s sign or the coding of

the incorrect weight (+1 or -1) in the calculation linkbase controlling the addition or subtraction

of the element amount within the financial statement. In addition, it is possible for an element’s

sign and its calculation weight to be correct, but either the element’s label or its sign in the

rendered XBRL financial statements is incorrect. We did not classify these less serious display

errors as sign flip errors; rather, they were classified as display errors. Sign flip errors are more

significant than display errors because they misrepresent amount of the element in the context of

the financial statements. In 2006, 10 of 22 companies made 58 sign flip errors with the erroneous
20
signs occurring across all four statements. In 2008, we detected no sign error flips. The SEC has

observed that sign flip errors continue to appear in the mandatory 2009 10-Q filings, e.g.,

incorrect signs for treasury stock, income (loss) concepts, and incorrect signs of elements in the

cash flow statement. We observed the same pattern in 2006, when analyzing statements from

inexperienced companies (first-time filers).

In 2006, sign flip errors were most common on the statements of cash flows and

stockholders’ equity. The cash flow statement is especially subject to sign flips because of the

large number of elements that do not have a natural debit or credit balance, e.g., many of the

adjustments to income to arrive at cash flow from operations. In 2006, a common sign flip in

both the balance sheet and the statement of stockholders’ equity was for the treasury stock

element. Treasury stock was coded with a positive calculation weight so that it was added to

stockholders’ equity rather than subtracted.

Because of the complexity of managing the sign of an element in the rendered financial

statements, it is likely that the sample companies made additional sign flip errors that we did not

observe. For example, companies may have violated XBRL protocol for assigning the sign to an

element amount as a shortcut to achieving the appropriate sign of an element in the rendered

financial statements. In this instance, we would not have observed the inconsistent sign because

there was no difference between the element’s sign in the rendered XBRL financial statements

and its sign in the Form 10-K. This type of sign flip error achieves a correct display and can only

be detected by a combination of validation software and manual tracing of every element in the

financial statements.

21
 It is likely that the reduction in sign flips in 2008 reflects technical improvements in

XBRL protocols, XBRL editing and validation software, and an increasing familiarity of

preparers with the complex procedures necessary to control element signs. The XBRL U.S.

GAAP Taxonomies v1.0 Technical Guide (Bolgiano, 2008) describes a significant technical

improvement in XBRL that reduces the motivation of preparers to make sign flip errors as a

shortcut to achieving the correct display of elements in the rendered financial statements. The

Technical Guide introduced “negating labels,” a protocol that reverses the display sign of an

element (including a modified label) when it is displayed but does not reverse the sign in the

underlying XBRL data.18 In addition, the XBRL US GAAP Taxonomy Preparers Guide (XBRL

US, Inc., 2008b) contains improved guidance for tagging the signs of element amounts. Even

with these improvements, the complexities of XBRL protocol and of financial reporting

conventions remain sources of errors for inexperienced preparers.

The basic XBRL convention that applies to most financial statement elements is that a

single polarity must be maintained, i.e., accounting elements having values with natural debit or

credit balances are to be tagged with positive signs. A negative sign is used when an element’s

debit-credit balance is the opposite of its natural balance. However, some financial statement

elements do not have a natural debit-credit balance. For example, the indirect method of

presenting cash flows from operations contains many balance-sheet change elements that are

18
Even when an element is coded with the correct sign, correct display can be a challenge because of variations in
financial statement format and labeling. For example, when an amount is subtracted in the income statement it can
be displayed as a negative value (in brackets) or its label could read “Less X” with the amount displayed as a
positive. To complicate matters further, an element that appears in more than one location in the financial statements
may display as a positive amount in one location and a negative in another location.

22
adjustments to arrive at cash flow from operations and that have no natural debit-credit balance.

Other financial statement elements such as “other income (loss)” can be either credits or debits.

These complexities increase the likelihood that preparers who are not intimately familiar with the

XBRL tagging protocols and accounting concepts will introduce sign flip errors. Detecting all

sign flip errors requires manual validation by individuals with knowledge of XBRL rules for

signing the element, the element’s debit or credit accounting balance, and the company’s unique

financial statement format and labeling.

Duplicate Elements

Duplicate elements are those that have been tagged more than once in the XBRL

instance document, and they distort the underlying data and may distort the financial statement

display as well. XBRL protocol requires that each financial statement concept be represented by

a single element with its display in multiple financial statements and the notes achieved by the

linkbases controlling display and labeling. In 2006, we identified four companies with six

duplicated element errors, and in 2008, we detected none. As we discuss below, there is evidence

that a substantially larger number of duplication errors occurred.

The duplicate elements that we detected were immediately apparent in the rendered

financial statements because they appeared incorrectly multiple times in the financial statements.

We traced all duplications to the XBRL instance documents to determine if the element itself

was duplicated or only displayed incorrectly. An example of a clear duplication error in 2006

was ADP’s tagging the cash and cash equivalents concept with the standard element in the

GAAP taxonomy and tagging it a second time as a unique company-specific element.

23
 We classified elements correctly tagged a single time but erroneously displayed multiple

times as display errors. In addition, some companies coded extra elements unnecessarily that we

did not count as duplicates. This occurred when a company correctly coded an element such as

“inventory” and coded a “total inventory” element with the identical amount. Elements labeled

“total” are only necessary when there are multiple component elements that sum to the total.

What is perhaps a common form of duplication error, creation of a unique element for

every appearance of a concept in the financial statements, is unobservable by examining the

rendered financial statements and is not included in our official count of duplication errors. We

observed this type of duplication error occurring frequently in 2006. For example, General

Electric coded a new element for every appearance of an accounting concept in its financial

statements. Using this technique, General Electric achieved a perfect replication of its 2006

Form10-K financial statements when the XBRL instance document was rendered for display.

Although it was not practical to identify and document all of these duplications because they

were not visible in our manual tracings between the Form 10-K and the instance documents, an

informal review of instance documents indicated that this type of duplication error appeared to

be common for several sample companies.

The complexity of controlling the XBRL financial statement display and preparers’

misunderstanding of the basic XBRL requirement that elements be tagged only once were likely

contributing factors to duplication errors in 2006. Improved software for rendering XBRL

documents allowed preparers to more readily observe duplications in 2008, a year for which we

detected no errors. Nevertheless, it is likely that firms will continue to make unobserved

24
duplication errors until they fully understand the XBRL protocol of tagging concepts a single

time.

Incorrect Elements

Incorrect elements occur when the preparer selects an element from the U.S. GAAP

taxonomy that does not correspond to the financial statement concept in question or when the

preparer extends the taxonomy by creating a unique company-specific element even though the

GAAP taxonomy includes an appropriate standard element. These errors are very serious

because they distort the underlying XBRL data, require manual interpretation, and/or reduce the

cross-sectional comparability of data. We are able to identify only a small number of these errors

with certainty, but it is possible that many more exist. Detection of all incorrect elements

requires tracing every financial statement concept to the corresponding XBRL element and

having knowledge of the true nature of a company’s financial statement concepts. It was not

practical for us to trace every financial statement concept to the corresponding element in

companies’ XBRL instance documents, and even if we had, we could not have determined with

certainty whether many elements were the best choices for particular financial statement

concepts because we did not have detailed knowledge of those concepts.

The incorrect errors we detected were found serendipitously as we looked for other

errors, and we only recorded those instances where a company unambiguously selected an

incorrect element or unnecessarily created a unique element for a common financial statement

concept already included in the GAAP taxonomy. As a result, we can provide evidence of the

existence of incorrect elements, but the frequencies of incorrect elements that we report are

incomplete. We identified four companies with 14 total incorrect elements in 2006 and five
25
companies with nine total incorrect elements in 2008. For example, United Technologies

combined two concepts in its 2006 Form 10-K balance sheet, common stock including

additional-paid-in capital and unearned ESOP shares, in a single XBRL element that was tagged

as “Common Stock Value (Excluding Additional Paid-in Capital) – All Classes” even though the

element included additional paid-in capital and unearned ESOP shares. As a result, two concepts

were tagged with a single incorrect element.19 In 2008, the Microsoft XBRL statement of cash

flows contained the U.S. GAAP taxonomy element ”Deferred Revenue Additions” as an

adjusting item to arrive at cash flow from operations. This element is intended for use in footnote

disclosures of changes in the balance of the deferred revenue element in the balance sheet.

Microsoft should have used the U.S. GAAP taxonomy element “Increase Decrease in Deferred

Revenue” that is the appropriate element for use in the statement of cash flows.

The second form of incorrect element is the creation of unique elements (known as

extensions of the U.S. GAAP taxonomy) that are unnecessary because the appropriate the U.S.

GAAP taxonomy already contains an element corresponding to the financial statement concept.

Validation software can highlight company created elements, but it cannot determine whether

companies created them unnecessarily. Only individuals with intimate knowledge of a

company’s accounting concepts can determine with certainty whether the company-created

elements were necessary additions to the U.S. GAAP taxonomy or were created in error. The

SEC views these errors as serious because the unique company-created elements cannot be

19
The XBRL US GAAP Preparers Guide (2008b) states that every concept in the financial statements should be
tagged as a separate XBRL element.
26
interpreted automatically by analytical software, reducing the cross-sectional comparability of

the XBRL data.

General Electric’s 2006 and 2008 XBRL documents contain a large number of unique

elements some of which provide readily observable illustrations of this type of error. For

example, in 2006 and 2008 General Electric created a unique element labeled “Provision of

income taxes” that included both current and deferred income taxes for the year. The U.S.

GAAP taxonomy contained the appropriate standard element, “Provision for income taxes –

total,” that General Electric should have used to represent the concept in its income statement.

General Electric also created a unique element for cash dividends declared per common share

even though the U.S. GAAP taxonomy contains “Cash Dividends – Common Stock – Amount

per Share” that is defined as including all dividends declared.

The creation of unnecessary unique elements also increases the likelihood of other data

entry and display errors because the preparer cannot rely on the default XBRL coding that exists

for elements in the U.S. GAAP taxonomy. Again, General Electric’s 2008 XBRL instance

document illustrates this problem. General Electric’s rendered XBRL financial statements have

44 missing elements. In substantially all instances, these missing elements are unique company-

specific elements that were not displayed because the company failed to appropriately code the

required XBRL display commands.

We used the Fujitsu editor to identify the number of unique elements created by the

sample companies. Consistent with the prior research, we found that the sample companies

created a large number of element extensions to the GAAP taxonomy, many of which appear to

be unnecessary. Although not directly comparable, the average number of unique elements
27
created by the eleven sample firms with data for both years was 271 in 2006 and 80 in 2008.

Most companies created unique elements for several concepts that do not do not appear to be

unusual and for which the U.S. GAAP taxonomy contained what appears to be an appropriate

element.

The overall decline in the number of unique elements likely reflects both preparers’

increasing familiarity with the taxonomy and the increase in the number of concepts in the U.S.

GAAP taxonomy. The U.S. GAAP taxonomy in use in 2006 contained approximately 3,000

financial report concepts. The revised 2008 U.S. GAAP taxonomy contains approximately

13,000 concepts, greatly reducing the need to create unique elements.20 In fact, a goal of XBRL

US and the SEC is that the taxonomy be so complete that the creation of unique elements is a

rarity.

Comparable to our findings, the SEC has observed what appear to be financial statement

concepts matched with incorrect elements and unnecessary company-specific elements in the

mandatory 2009 10-Q filings (SEC, 2010). In addition to the large number of elements to select

from (in 2009 the number of elements in the taxonomy was over 18,000), the structure of the

taxonomy contributes to this problem. The taxonomy is structured within industry groupings by

financial statement and by financial statement component, and a company may need to locate

select elements from a different industry or a different area of the financial statements.

Misspellings when using the search engine and unfamiliarity with the taxonomy lead to errors.

20
The U.S. GAAP taxonomy is organized in industry clusters, but companies should use appropriate elements in the
taxonomy without regard to where they are located in the industry structure. In 2006, the primary industrial and
commercial cluster contained approximately 2,000 financial concepts.
28
As companies start to tag footnotes, the number of elements per filing is expected to increase by

threefold to between 1,200 and 2,000. This increase will compound the likelihood of incorrect

element errors. It is imperative that companies use knowledgeable accountants to select and

validate the elements that represent the company’s financial statement concepts.

Incorrect Display

A display error occurs when a financial statement concept either is labeled incorrectly or

is presented in an incorrect location in the rendered XBRL financial statements, even though it

has been tagged correctly with the element, amount, and other information. Although the SEC

does not require rendered XBRL documents to be identical to those in the official filings, it is

considered good practice. The SEC does require that XBRL labels convey the same meaning as

the concepts in the 10-K, and the SEC prohibits changing, deleting, or summarizing information

in the XBRL documents in order to avoid problems in the display.

We consider incorrect display errors to be less serious than other errors because they do

not affect the usability of the individual data items when the XBRL documents are input into

analytical software. However, differences between the rendered XBRL financial statements and

the 10-K can cause user confusion and may reduce user confidence in the accuracy and

reliability of the XBRL data resulting in damage to the company’s reputation and more generally

a loss of confidence in all XBRL documents. Ideally, XBRL instance documents will achieve an

exact rendering of a company’s unique financial statement format making the duplicative

creation and filing of HTML or PDF documents unnecessary.

We detected display errors by tracing differences between the rendered XBRL financial

statements and the 10-K to the related XBRL instance document to determine if the difference
29
occurred because of an error in underlying XBRL data or only in the XBRL protocols that

control labeling and display. We did not count simple variations in statement format or

differences between labels in the XBRL documents and those in the 10-K as errors, unless the

XBRL label failed to accurately describe the financial statement concept. Twenty-one of 22

companies made 340 total display errors in 2006, and 10 of 11 companies made 198 display

errors in 2008. A simple example is that DuPont combined all five concepts representing

changes in comprehensive income in a single XBRL element in its statement of stockholders’

equity in 2006. All five of the elements were present in the XBRL instance document, but none

was displayed. The most common display error was an incorrect element sign (the element’s

label incorrectly described the sign of the element). Other common errors were duplicate

displays of a single element and elements that were displayed at random locations in the

rendered financial statements rather than in their correct location.

Formatting the financial statements, especially the statement of stockholders’ equity, was

a significant challenge for most VFP companies in 2006; however, the current version of XBRL

includes an improved “dimension” feature that facilitates tabular presentations such as those

often used in the statement of stockholders’ equity and in notes and supplemental schedules

(XBRL US, Inc., 2008b). In 2006, the lack of a previewer (SEC financial statement rendering

software that allowed examination of the XBRL rendered financial report prior to filing) was an

obvious handicap. However, the large number of formatting errors across all statements in both

2006 and 2008 is indicative of the complexity of controlling the display of the rendered financial

statements. The SEC observes that correctable display errors continued in the mandatory 2009

10-Q filings (SEC, 2010). Thus, companies will likely continue to have difficulty with this

important aspect of preparing the XBRL instance documents.

30
 DISCUSSION AND CONCLUSION

The SEC mandated XBRL filings for registrants beginning in 2009 with an unstated

expectation that XBRL filings eventually will replace the HTML and PDF formats currently

required. Successful implementation and adoption of XBRL-tagged financial reports has the

potential to provide benefits in terms of efficiency, comparability, and standardization of

financial reporting. However, preparer and user acceptance of this new reporting format is a

prerequisite to full implementation of XBRL reporting. We believe that a low level of accuracy

and reliability in XBRL filings could pose a serious threat to preparer and user acceptance.

This study examines 22 companies’ initial voluntary XBRL Form 10-K filings in 2006

and the 2008 filings of the 11 sample companies that also filed XBRL 10-K documents that year.

We posed two research questions, what types of errors occurred and did the frequency of errors

decrease as companies gained more experience and XBRL technology improved. In a departure

from prior studies that relied primarily on software validation to identify errors, we made manual

comparisons of the concepts, labels, and amounts in the official Form 10-K to the related

elements in the XBRL documents. Software validation detects syntax errors and performs tests

of mathematical relationships that have been established by the preparer. Manual validation can

identify other forms of errors including the selection of incorrect elements, errors in amounts,

and display errors.

Giving full recognition to the limitations of the research design, our results provide

evidence about the types and frequency of errors that may exist in voluntary filings and may

persist in mandatory filings. This evidence will aid the SEC and XBRL US in improving XBRL

technology, and it will aid preparers in designing and implementing XBRL document
31
preparation processes. Third-party developers of XBRL preparation and validation software may

find our results useful in improving their products. In addition, our results provide preliminary

evidence related to the question of whether some level of independent assurance will be needed

for XBRL disclosures to achieve acceptance by the investor community.

We found that all companies made varied errors in 2006, the first year of XBRL filing.

The number of errors decreased dramatically for all 11 sample companies in 2008 with the

exception of display errors. The most common errors that we identified in 2008 were display

errors, incorrect elements, and missing elements. We also provide evidence that there may be a

larger number of duplicate elements, incorrect elements, and possibly sign flip errors that we did

not detect. Display errors are of the least importance for interactive use of the data, but all of the

error types we documented have the potential to create problems for users. Although most of the

reduction in error rates may have been due to improvements in XBRL protocols and in the U.S.

GAAP taxonomy, it is likely that greater preparer experience was also an important factor. The

persistence of errors in the third year of the Voluntary Filing Program is evidence of the

difficulty of preparing accurate XBRL documents for GAAP-based financial statements.

The SEC staff has conducted preliminary reviews of a small number of the initial

mandatory 10-Q filings in 2009, and they have reported observing most of the same error types

identified in this study. Since these initial mandatory filings are from the largest SEC registrants

(based on market value), we would expect these companies to be among the most sophisticated

and well prepared. The frequency of errors that we observed for the VFP participants and the

SEC’s observations of the same errors in the 2009 10-Q filings is cause for concern given that

most companies have yet to file the larger 10-K (eventually including fully tagged footnotes).

32
We expect smaller companies will be less prepared for XBRL document preparation, and it is

possible that third-party companies that provide assistance with the preparation and validation of

XBRL documents will be overwhelmed when thousands more companies seek assistance. To the

extent that the high error rates we observed in 2006 are a reflection of the difficulty of initial

preparation of XBRL documents, the initial mandatory filings may have excessive errors rates

because preparers do not have adequate training and experience with document preparation.

Thus, we remain concerned that the inherent complexity of the XBRL document preparation

process and limitations of XBRL technology will continue to contribute to high error rates in the

initial mandatory filings.

Although technical refinement of XBRL and increasing preparer experience can be

expected to improve XBRL document accuracy, a new threat to overall accuracy is on the

horizon. The XBRL filings mandated by the SEC must include complete footnotes in block-text

format in the first year of filing and detailed tagging of all concepts in the footnotes beginning in

the second year of filing (SEC, 2009) In 2006 and 2008, most companies did not include

footnote disclosures in their XBRL filings. Although the process of tagging blocks of text is

straightforward, the detailed tagging of all quantitative concepts in the footnotes and schedules

will greatly increase the potential for errors. Detailed footnote tagging is likely to triple the

number of tagged elements and increase the number of nonstandard, company-specific elements

that preparers need to create.

We call on the SEC, registrants, and the accounting profession to address the issues of

XBRL accuracy without delay. Since both the user and preparer communities are largely

unfamiliar with XBRL, there is a limited reservoir of support to fall back on if the initial filings

33
are inaccurate.21 Users and filers will judge XBRL based on early filings. There is a risk that the

SEC’s program for mandatory XBRL filings could fail to gain acceptance, and if that happens, it

will be difficult to regain preparer and user confidence in the XBRL process for many years.

In order to increase the likelihood of investor acceptance, we recommend that various

stakeholders consider the following actions. The SEC should continue to improve its detailed

guidance on XBRL implementation. They should also carefully consider the addition of new

elements to the taxonomy and the resultant trade-off in the reduction of comparability between

companies. Registrants should devote sufficient resources to understanding the complexities of

the XBRL technology and specifications and to training staff in XBRL document preparation

and validation. This training should include information about common errors, such as those

identified in the current study. The accounting community as a whole (SEC, registrants, and

investor protection groups) should carefully consider whether mandated audit-level assurance is

necessary to achieve reliability and accuracy. As Nicolaou, Lord and Liu (2003) suggest,

assurance would enhance investor trust by providing independent judgment of the reliability and

accuracy of the filings.

Extending an assurance requirement to XBRL documents is one way to assure accuracy

and reliability, but its implementation would create additional challenges. The Public Accounting

Oversight Board (PCAOB) and the American Institute of Certified Public Accountants (AICPA)

would need to provide greater guidance to auditors in this area because it has not been

determined how auditors should approach providing audit-level assurance on XBRL filings.

21
An Institute of Internal Auditors survey of over 200 internal audit executives found that over 50% were unfamiliar
with XBRL, and 90% were interested in learning more about their role (Institute of Internal Auditors, 2008).
34
Plumlee and Plumlee (2008) provide an extensive discussion of assurance-related issues that will

need to be resolved by the PCAOB and the AICPA.22

Limitations

There are several factors limiting conclusions drawn from our results. First, our sample

size is small because of the time required to perform manual validations and the small number of

companies that participated in all three years of the Voluntary Filing Program. Second, since the

SEC provided liability protection for inadvertent errors in the voluntary filings, and did not

display the XBRL filings on EDGAR, it is possible that companies were less attentive to the

process than they otherwise would have been.23 Third, we were unable to identify all of the

errors in the XBRL filings. Without detailed knowledge of a company’s financial statement

concepts, it is not possible to detect all the financial statement concepts that are tagged with an

incorrect element or for which a unique company-specific element was created unnecessarily.

Similarly, it was not practical to detect all of the financial statement elements that were

duplicated unnecessarily. Although these types of serious errors appear to be common, we are

unable to document their frequency precisely. Our validation of elements was limited to tracing

differences between the XBRL rendered financial statements and the 10-K to the corresponding

element tags in the XBRL instance document. It was not practical to devote the time necessary to

22
Audit firms may be reluctant to lobby for assurance requirements apparently out of fear of being labeled as
profiteers (much like they were after the Sarbanes-Oxley legislation). While audit firms are helping develop XBRL
technology and are preparing to provide assurance services, they have not been vocal advocates for assurance.

23
There is a long history of voluntary corporate participation in trials of new financial reporting methods and
disclosures sponsored by standard setting organizations. While it is possible that companies that oppose XBRL
implementation could have intentionally exaggerated the difficulties of implementing XBRL reporting, this seems
unlikely in the case of XBRL filings. Most participants in our sample are traditionally good corporate citizens and/or
they were companies that are likely to benefit from either cost savings or from increased business if XBRL filings
replace the current HTML and PDF filings.
35
perform a complete manual validation all financial statement concepts in the 33 financial

statements included in our study. Finally, although we observed reduced error rates as companies

gained experience with XBRL document preparation, it was impossible to separate this

improvement from that resulting from changes in XBRL technology and the expansion of the

U.S. GAAP taxonomy. Since XBRL US is continuing to make improvements in both technology

and the taxonomy, one can optimistically expect a downward trend in error rates for experienced

filers.

Future Research

There are many avenues for academic research related to the implementation of XBRL

financial statement reporting.24 At a technical level, there is a continuing need for refinement of

the capabilities of XBRL code. The whole area of what is a material error and what attestation

processes are necessary to provide adequate assurance of XBRL accuracy are largely

unexplored. There is a need to design processes that companies can follow that will help assure

the preparation of accurate XBRL documents. An especially important opportunity lies in

developing systems that integrate XBRL tagging into automated accounting information and

enterprise resource planning systems. This integration would minimize errors and make

consolidation and closing more efficient. Without a doubt, access to accounting information in

XBRL format holds the promise of greatly reducing the cost of conducting both cross-sectional

and time-series studies based on financial report data. Research that in the past was prohibitively

expensive will become practical with XBRL data.

24
Plumlee and Plumlee (2008) provide a more extensive discussion research questions related to XBRL
implementation.
36
 In conclusion, there is much to look forward to if organizations can successfully

implement XBRL for reporting. XBRL offers us the prospect of greater transparency, timeliness,

standardization, and reduced costs. However, the process is complex, and work remains to be

done. The successful implementation of XBRL reporting will require the support of accounting

practitioners and researchers. With the exception of a small number of individuals at the large

firms, the development of XBRL has thus far occurred without gaining the attention and

engagement of the large majority of accountants. As this study reveals, improvements in the

XBRL standard and related technology will reduce some errors, such as certain display and sign

errors. However, other errors, for example, missing elements, incorrect amounts, incorrect

elements, and duplicate elements will persist unless preparers obtain the proper training and

devote the necessary resources to developing expertise in XBRL document preparation. Without

much broader engagement by accounting practitioners and researchers, XBRL reporting may

remain a promise rather than becoming a reality.

37
 Bibliography
Assurance Services Executive Committee (ASEC) XBRL Assurance Task Force. (2009).
Statement of Postion 09-1: Performing Agreed-Upon Procedures Engagements That Address the
Completeness, Accuracy, or Consistency of XBRL-Tagged Data. American Institute of Certified
Public Accountants, Auditing Standards Board. New York: American Institute of Certified
Public Accountants.

Bolgiano, M. P. (2008). XBRL US GAAP Taxonomies v1.0 Technical Guide. XBRL US, Inc.

Boritz, J. E., & No, W. G. (2009). Assurance on XBRL-Related Documents: The Case of United
Technologies Corporation. Journal of Information Systems , 23 (2), 49-79.

Boritz, J. E., & No, W. G. (2008). The SEC's XBRL Voluntary Program on Edgar: The Case for
Quality Assurance. Current Issues in Auditing , 2 (2), 36-50.

Chou, K. H. (2006). How Valid Are they? An examination of XBRL Voluntary Filing
Documents with the SEC EDGAR System. Proceeding of the 14th International XBRL
Conference .

Debreceny, R. S., Chandra, A., Cheh, J. J., Guithues-Amrhein, D., Hannon, N. J., Hutchison, P.
D., et al. (2005). Financial Reporting in XBRL on the SEC's EDGAR System: A Critique and
Evaluation. Journal of Information Systems , 19 (2), 191-210.

Institute of Internal Auditors. (2008). Interactive Data- eXtensible Business report Language
(XBRL) Survey.

Janvrin, D. &. (2009). XBRL Implementation: A Field Investigation. Retrieved January 2010

Kinney, M. R., & Swanson, E. P. (1993). Research Note: The Accuracy and adequacy of tax data
in COMPUSTAT. The Journal of the American Taxation Association , 15 (2), 121-135.

Nicolaou, A. I., Lord, A. T., & Liu, L. (2003). Demand for data assurances in electronic
commerce: An experimental examination of web-based data exchange using XML.
PriceWaterhouseCoopers Research Monograph , 32-42.

Phillips, M. B. (2008, February). Six Steps to XBRL. Journal of Accountancy , 32-38.

Plumlee, R. D., & Plumlee, M. A. (2008). Assurance on XBRL for Financial Reporting.
Accounting Horizons , 22 (3), 353-368.

Public Company Accounting Oversight Board. (2005). Staff Questions and Answers Attest
Engagements Regarding XBRL Financial Information Furnished Under the XBRL Voluntary
Financial Reporting Program on the EDGAR System. (Public Accounting Oversight Board)

38
Retrieved March 23, 2009, from
http://pcaobus.org/standards/staff_questions_and_answers/2005/05-25%20.pdf

San Miguel, J. G. (1977). The reliability of R&D data in Compustat and 10-K reports. The
Accounting Review , 52 (3), 638-641.

SEC. (2009). Interactive Data to Improve Financial Reporting. Securities and Exchange
Commission. Washington, DC: Federal Register, February 10, 2009.

SEC. (2010). Staff Observations From Review of Interactive Data Financial Statements.
Retrieved January 20, 2010, from U.S.. Securities and Exchange Commission Office of
Interactive Disclosure (OID): http://www.sec.gov/spotlight/xbrl/staff-review-observations.shtml

SEC. (2005). XBRL Voluntary Financial Reporting Program on the EDGAR System. Securities
and Exchange Commission. Washington D.C.: Federal Register, February 8, 2005.

XBRL US, Inc. (2005). US GAAP XBRL Taxonomy. Retrieved January 2009, from
http://www.xbrl.org/us/fr/gaap/ci/2005-02-28)

XBRL US, Inc. (2008a). 2008 US GAAP Taxonomies 1.0. Retrieved May 2009, from XBRL US:
http://xbrl.us/us-gaap/1.0/ind/ci/us-gaap-ci-stm-dis-all-2008-03-31.xsd

XBRL US, Inc. (2008b). XBRL US GAAP Taxonomy Preparers Guide. Retrieved January 2010,
from XBRL.US: http://www.xbrl.us/preparersguide

Yang, D. C., Vasarhelyi, M. A., & Liu, C. (2003). A note on the using of accounting databases.
Industrial Management & data Systems , 103 (3), 204-210.

39
 Appendix A

The Challenges of Manual Tagging

Conceptually, the process of tagging financial report data to create an interactive

computer-readable data file is straightforward. One might assume that the process of assigning

computer codes to the items in an audited financial report would be easy to accomplish, and in

fact, there has been widespread success in the creation of XBRL for select applications in the

U.S. and around the world. Since 2006, the Federal Deposit Insurance Corporation, Federal

Reserve and the Office of the Controller of the Currency have required approximately 8,000

financial institutions to file their quarterly financial reports (call reports) as XBRL documents

(SEC, 2009).25 Yet, this successful application of XBRL reporting does not provide strong

evidence that registrants can produce the XBRL filings mandated by the SEC reliably and

accurately. The call report filings and similarly successful XBRL applications in China and

Japan involve standardized forms and relatively simple documents. Standardized forms are easily

reproduced in XBRL and do not require preparers to undertake the specification of unique

disclosures, formats, and complex relationships among the data. The initial creation of a XBRL

instance document for a Form 10-K is much more complex than the tagging process for a call

report.

A short description of the process of creating an XBRL instance document illustrates the

complexity of this procedure. In 2006, participants in the VFP using the U.S. GAAP Commercial

25
China and Japan already require listed companies to file interactive financial data, and numerous countries
including Australia, Canada, Germany, and the United Kingdom have scheduled implementation of XBRL reporting
by listed companies or have voluntary programs in place.

40
and Industrial taxonomy (us-gaap-ci) were required to identify the unique element in taxonomy

of over 1,500 possible elements that corresponded to each financial statement concept. Accurate

tagging requires deep knowledge of financial accounting and of a company’s reporting practices.

The resulting electronic document is a taxonomy schema. Elements in the taxonomy schema link

to five interrelated XBRL files known as linkbases that provide contextual information about

each element. The label linkbase allows the company to enter its own label for each element. The

presentation linkbase specifies where and in what order the elements appear in the financial

report. The calculation linkbase defines relationships that facilitate the accurate representation of

amounts within subtotals and totals contained the in the financial statements. The definition

linkbase describes the relationships of elements (parent-child) within the financial statements.

The reference linkbase provides authoritative references for each element. The XBRL instance

document that companies file with the SEC contains all six of these interrelated files.

XBRL is extensible, allowing users to create unique financial statement elements and to

use the linkbases to create their own terminology and financial statement formats. Recall that

Boritz and No (2008) found that for companies in the VFP, 55 percent of all elements were

extensions. The process of extending the XBRL taxonomy and linkbases requires much deeper

knowledge of XBRL than using only the U.S. GAAP taxonomy and standard XBRL linkbases.

For the basic financial statements, not including footnotes, registrants must create several

thousand lines of computer code. The lines of XBRL code are not intended for humans to read

and do not produce a financial statement document that can be viewed during the input process,

i.e., XBRL does not have the capability of word processing software like Microsoft Word to

instantly produce a viewable document. Fortunately, document creation software is available that

41
allows data entry using menu driven forms.26 Even with the assistance of document creation

software to create the necessary XBRL codes, the process is complex, and it requires detailed

knowledge of financial reporting, the structure of XBRL, and familiarity with the document

creation software. The creation of the XBRL instance document is most difficult in the initial

year, when financial statement concepts are mapped to the appropriate XBRL elements and the

financial statement presentation commands are created for the first time. In subsequent years, the

initial model can be used as a template, followed with only incremental changes.

Aside from the technicalities of creating a valid XBRL instance document, the process of

manually transferring all of the amounts, dates, and language in a financial report to the XBRL

documents is subject to keystroke errors. This is true even with the use of drag and tag software.

The integration of XBRL technology and a company’s automated financial reporting software

could greatly reduce data entry errors, but this option is likely to be several years away for most

companies.

26
Leading instance document creation software used by companies in the VFP include Dragon Tag, EDGAR Online
I-Metrix, Core Filing Ltd. Fujitsu Interstage XWand, and TagEzee (Phillips, 2008)
42
 Table 1
Sample Companies Participating in the SEC’s XBRL Voluntary Filing Program and
Submitting Form 10-K Financial Statement Documents for 2006 and 2008

Ticker
Company Name 2006 2008
Symbol
ADBE ADOBE SYSTEMS INC X X
ADP AUTOMATIC DATA PROCESSING INC X X
BMY BRISTOL-MYERS SQUIBB CO X
BNE BOWNE & CO INC X
CMCSA COMCAST CORP X X
DD DUPONT E I DE MEMOURS & CO X X
DOW DOW CHEMICAL CO X
F FORD MOTOR CO X
GE GENERAL ELECTRIC CO X X
IBM INTERNATIONAL BUSINESS MACHINES CORP X X
ISE INTL SECURITIES EXCHANGE INC X
LMT LOCKHEED MARTIN CORP X
MMM 3M CO X
MSFT MICROSOFT CORP X X
PEP PEPSICO INC X X
PFE PFIZER INC X
RADN RADYNE CORP X
RRD DONNELLEY (R R) & SONS CO X X
TROW PRICE T ROWE GROUP INC X
UTX UNITED TECHNOLOGIES CORP X X
XMSR XM SATELLITE RADIO INC X
XRX XEROX CORP X X

43
 Table 2
Classifications of Errors in XBRL Instance Documents

Error Type Description of Error

Missing Elements (concept) appear in Form 10-K, but not in the XBRL instance
Elements documents.

Incorrect Correct elements are in the XBRL documents, but the amount or date is
Amounts incorrect (excludes sign flips).

Elements coded with the incorrect sign or calculation weight. (Sign errors only
Sign Flips
in the display of an element’s value classified as incorrect display errors.)

Duplicate Financial statement concepts coded more than once so that they appear more
Elements than once in the instance document.

Incorrect Financial statement concepts coded with an incorrect element in the U.S. GAAP
Elements taxonomy or unique company-specific elements created unnecessarily.

Incorrect Elements are otherwise correctly coded are displayed with an erroneous label, in
Display the wrong location, or not at all in the rendered XBRL financial statements.

44
 Table 3
Effects of XBRL Errors and How Errors Can Be Detected

Effects Detection Methods*

Errors Distorts Distorts Software Manual Inspection of

Data Display Validation** Differences Between
the Rendered Financial
Statement and the
Original Financial
Statement

Missing Elements Yes Yes Often Yes

Incorrect Amounts Yes Yes Often Yes

Sign Flips Often Often Often Often

Duplicate Elements Yes Yes Occasionally Yes

Incorrect Elements Yes Often Occasionally Often

Incorrect Display No Yes Occasionally Yes

*All XBRL document errors can be detected by a complete manual examination of all
tags in the XBRL instance documents in combination with a comparison of the rendered
financial statements to the original financial statements.
**Software validation is much less effective in detecting errors in financial statement
footnotes and supplement disclosures because mathematical validation of many amounts is not
possible.

45
 Table 4
Total Errors by Type

CMCSA

TROW

XMSR
RADN
MMM

MSFT
ADBE

errors
DOW
BMY

Total
LMT

RRD

XRX
UTX
BNE
ADP

IBM

PEP

PFE
YEAR 2006

ISE
GE
DD

F
RESULTS

Difference by Type
Missing Elements 7 60 67
Incorrect Amounts 2 2 1 2 7
Sign Flips 1 6 1 8 6 3 1 6 13 13 58
Duplicate elements 1 2 2 1 6
Incorrect Elements 1 3 1 9 14
Incorrect Display 18 23 14 20 24 8 37 10 18 7 13 25 20 7 9 5 12 31 7 25 7 340
Total 20 27 27 22 25
CMCSA 8 37 11 3 26 13 16 27 22 7 9 13 26 31 68 34 20 492

MSFT
ADBE

errors
Total
RRD

XRX
UTX
ADP

IBM

PEP
YEAR 2008

GE
DD

RESULTS

Difference by Type
Missing Elements 1 1 2
Incorrect Amounts
Sign Flips
Duplicate elements
Incorrect Elements 1 1 2 3 2 9
Incorrect Display 58 4 8 9 44 14 21 8 27 5 198
Total 59 5 8 11 47 0 17 21 8 28 5 209
 Table 5
Average Number of Errors per Company

2006 2008

Missing Elements 3.0 0.2

Incorrect Amounts 0.3 0.0

Sign Flips 2.6 0.0

Duplicate Elements 0.3 0.0

Incorrect Elements 0.6 0.8

Incorrect Display 15.5 18.0

Percentage of Companies with Errors

2006 2008
Missing Elements 9.1% 18.2%
Incorrect Amounts 18.2% 0.0%
Sign Flips 45.5% 0.0%
Duplicate Elements 18.2% 0.0%
Incorrect Elements 18.2% 45.5%
Incorrect Display 95.5% 90.9%

47
 20.0

18.0

16.0
Average Number of Errors per Company

14.0

12.0

10.0
2006

8.0 2008

6.0

4.0

2.0

0.0
Missing Incorrect Sign Flips Duplicate Incorrect Incorrect
Elements Amounts Elements Elements Displays

Figure 1
Average Number of Errors per Company

48
100.0%

90.0%

80.0%

70.0%

60.0%

50.0%
2006

40.0% 2008

30.0%

20.0%

10.0%

0.0%
Missing Incorrect Sign Flips Duplicate Incorrect Incorrect
Elements Amounts Elements Elements Displays

Figure 2
Percentage of Companies with Errors

49