IN THIS ISSUE

Vol. 10, August 10, 2007

Print Article Print Entire Issue

Using XBRL — Audit and Control Implications

Extensible business reporting language, commonly known as XBRL, standardizes the way organizations collect, prepare, and share business information. However, organizations and internal auditors need to become acquainted with the different control issues that might impact XBRL use and its effectiveness.

GLEN GRAY, PH.D., CPA
ACCOUNTING AND INFORMATION SYSTEMS DEPARTMENT, CALIFORNIA STATE UNIVERSITY AT NORTHRIDGE

According to Charles Hoffman, the founding father of XBRL and the director of industry solutions and financial reporting for UBmatrix, the benefits of XBRL extend beyond the creation of end reports and touch all aspects of the information supply chain. XBRL standardizes data formats through the use of agreed-upon tags (a type of metadata involving the association of descriptors with objects), simplifying the way data is imported, converted, and presented in business and financial reports. "Using XBRL streamlines the work for internal auditors and enables organizations to reduce reporting errors and risks," explains Hoffman.

"XBRL is an application of extensible markup language (XML) to business data that uses standardized tags to describe this information, thus making business information immediately reusable and interactive," says Mike Willis, a partner with PricewaterhouseCoopers (PwC) and the founding chairman of XBRL International, a consortium of more than 500 companies and agencies worldwide that build XBRL and promote and support its adoption. "Because XBRL is an Internet-based information standard, it enables the seamless flow of information from one organization to another, as well as the customization of data for different reporting purposes," he adds.

Because XBRL uses common templates for the analysis of business reports, many internal auditors are taking the lead in converting the outputs of dissimilar systems into XBRL documents as a way to maximize audit review efforts. However, before embarking on an XBRL initiative, auditors need to be aware of the different audit and control issues associated with its use, especially for created end reports that require internal audit assurance. Armed with this knowledge, auditors will be able to maximize XBRL use and add more value to companywide information supply chain activities.

AUDIT AND CONTROL ISSUES

Although the application of XBRL has the potential to improve data analysis, accelerate the use of continuous auditing, reduce the proliferation of spreadsheets throughout the information supply chain, and enhance two-way audit trails, internal auditors interested in the use of XBRL need to be cognizant of the different challenges associated with its use. (For more information about the internal audit benefits of XBRL, read ITAudit's "Got XBRL?" article, published on June 10, 2007.)

"The good news about XBRL is that it allows organizations to create, publish, and consume detailed business information through the use of clear text and standardized tags," comments Eric E. Cohen, XBRL technical leader for PwC. "The bad news is the good news — that XBRL data is easy to create, publish, and consume, thanks to the use of clear text and standardized tags." According to Cohen, this is because XBRL could be used for industrial espionage or other nefarious purposes unless appropriate security measures are implemented such as XML signatures and encryption. “Although this is a temporary challenge, it is a challenge nonetheless,” Cohen adds.   

In 2002, the Canadian Institute of Chartered Accountants (CICA) published a report, Audit & Control: Implications of XBRL (PDF, 204 KB), that describes three kinds of risks organizations may face when using XBRL for financial reporting — risks of errors, control issues, and assurance issues. Although CICA describes these risks as part of the financial reporting process, these risks can impact other kinds of business reporting as well. Below is a description of each risk and recommendations internal auditors can provide to organizations interested in implementing XBRL.

Risks of Errors
Error risks center around the accurate mapping of business information to tags and the use of appropriate taxonomies (i.e., XBRL dictionaries that define the specific tags for individual items of data). Hence, mapping tags accurately ensures that the data retrieved is correct. Consequently, without an effective internal control structure to ensure accurate tagging, the data retrieved can represent invalid and inaccurate transactions.

The importance of accurate tagging and mapping of information is increased when data is streamed in real time and automated; the risk of error in the statement or report increases, depending on existing change management controls and the effectiveness of the controls that oversee changes in the mapping of data to tags. This also creates additional risks because the data mapped to a particular tag may change without the organization's knowledge due to a faulty control, which increases the likelihood of errors. As a result, when XBRL instance documents are generated in real time, tests of the mapping algorithms captured in the conversion software used to turn business data into tags must be comprehensive to ensure that the converted information retains its accuracy and integrity.

Control Issues
XBRL control risks pertain to the use of appropriate taxonomies, tagging of data, and the integrity of the tagged data. "Ensuring that the client has used the appropriate taxonomy in the creation of their filings or financial reports is a major audit and control issue," explains Diane Mueller, vice president of XBRL Development for JustSystems Inc. and a member at-large of the XBRL International Steering Committee. "Auditors, therefore, must be aware of the different taxonomies in existence and ensure that the appropriate one is being used." (To see the U.S. Financial Reporting Taxonomy Framework overview, click here.)

Once the appropriate taxonomy is chosen, the next area of risk is the actual tagging of data. "Taxonomies can be complex hierarchies and contain thousands of concepts," Mueller continues. "Correctly choosing what information to map to each tag can be difficult when learning how to navigate the tools and taxonomies in the tagging process." For example, organizations need to have a system in place that ensures the appropriate taxonomy was chosen when preparing a financial statement. Therefore, staff working on the business report need to be knowledgeable about the requirements of a particular report and the taxonomy used so they can pick the right taxonomy. Otherwise, the organization runs the risk that tags are implemented incorrectly, which affects the accuracy of the reported information throughout the entire information supply chain. 

When reviewing the taxonomy for its appropriateness, auditors should review the details of the taxonomy to determine whether they are up-to-date with current business and reporting requirements and whether the taxonomy is applied correctly. In addition, auditors need to determine whether there are procedures in place to ensure that the tagging of data is complete and accurate. These procedures include review and approval activities by a knowledgeable person on:

• The tagging that is applied.
• The data elements to which tags are applied.
• The consistency of tagged data elements with the requirements of the taxonomy being used.

Finally, auditors need to examine whether there is an approval process in place that describes how financial statements should be created from tagged data for inclusion on Web sites or for other purposes. These procedures should be applied to business reports generated at any point in time and should be required for any report updates. For reports generated on a real-time basis, the organization should implement a more complex set of procedures that ensure the integrity and accuracy of changes to tagged data on an ongoing basis.

Assurance Issues
Where assurance is concerned, auditors need to pay close attention to the different issues that might impact XBRL use and its effectiveness. "Auditors should use multiple validation tools, to ascertain the quality of the data in the XBRL report and not just rely on the preparer's tool for validation assurance," explains Mueller. "This is because different tools have slightly different approaches for tagging business reports with XBRL tags and preparers might have their own built-in validation processes, which may not be as rigorous as the tests conducted by other users." As a result, testing the validity of the tags with another validation tool is a good practice when auditing XBRL business report filings. "This second opinion can flush out any issues concerning the improper use of tags, conflicting contexts, improper extension of base taxonomies, or just missing information," adds Mueller.

Different assurance issues auditors need to pay close attention to include:

• Reviewing policies and procedures that describe how XBRL statements are generated at a point in time. To make sure these policies and procedures are effective, auditors need to review the controls that oversee the use of an appropriate taxonomy, the tagging of data, and the integrity of tagged data. Auditors also need to document and test these controls for their effectiveness and determine if the appropriate taxonomy is used when generating the statement. Finally, auditors need to test the data tagging procedure to determine if it is appropriate and includes all the data required.
• Reviewing procedures that describe how statements are generated on a real-time basis. When XBRL is used on a real-time basis, additional controls may be needed to ensure the integrity and accuracy of the tagged data. As a result, auditors need to identify and evaluate these controls. Furthermore, any online monitoring and exception reporting software used by the organization also can be used for assurance purposes. For instance, continuous audit procedures can be developed to flag conditions based on the most appropriate exception reports, such as unauthorized changes in selected data elements, while other audit software can be used to monitor selected conditions and generate periodic reports at random intervals for audit activities.

As stated earlier, picking the right taxonomy is one of the most important issues auditors need to pay close attention to — if the right taxonomy is not picked, the auditor may be unaware there is an error in the reported data. To verify whether XBRL documents conform to applicable XBRL taxonomies and specifications, the American Institute of Certified Public Accountants and Public Company Accounting Oversight Board  recommend that organizations render the report. (See Attest Engagements Regarding XBRL Financial Information Furnished Under the XBRL Voluntary Financial Reporting Program on the Edgar System [PDF, 59 KB]).

"Rendering means to convert the XBRL tags into human-readable form, such as PDFs or printable documents," explains Mueller. Therefore, if somebody gives the auditor a financial statement in an Excel spreadsheet, the auditor would convert the spreadsheet into XBRL and run the data through another program that takes the tags used as part of the chosen taxonomy and puts them back into human-readable form. The auditor would then print the original Excel spreadsheet and the final report from the second application and compare them side by side. If there is a problem with the taxonomy chosen, it will show in the form of missing data. "Another method of reviewing XBRL-tagged documents includes opening the XBRL report as a source-code document and testing the tags in the instance document," Mueller adds.

PROBLEMS WITH EXTENSION TAXONOMIES

In addition to the issues associated with choosing the wrong taxonomy discussed above, the use of extension taxonomies may pose additional issues when creating XBRL tags. An extension taxonomy is created by an organization or XBRL user to cover information that is not included in an approved or acknowledged taxonomy. For example, an XBRL user may start applying a taxonomy to a specific financial statement and discover there's a line item that's not covered by the taxonomy. The organization will then create its own specialized dictionary or extension taxonomy for those line items that are not in the main dictionary.

XBRL International recognizes two types of externally developed taxonomies — approved or acknowledged. Approved taxonomies have to comply with the official XBRL guidelines for that type of taxonomy as well as with XBRL Specifications, a technical explanation of what XBRL is and how it works. The current specification for XBRL is version 2.1, which can be found on XBRL International's Recommendations Web page. On the other hand, acknowledged taxonomies only have to comply with the XBRL Specifications. Other taxonomies include those used for financial, statistical, tax, and sustainability reporting, as well as the Global Ledger taxonomy, a special taxonomy that supports collation of data and internal reporting within organizations.

When it comes to extension taxonomies, auditors need to review whether the taxonomy was created and implemented correctly. In addition, users may think they need an extension taxonomy, when in fact the tags are already covered in an approved or acknowledged taxonomy. Consequently, they spend additional time creating an extension taxonomy that is not really needed, which increases the changes of introducing errors into the XBRL information supply chain.

OTHER ISSUES

Additional issues auditors need to keep in mind include those pertaining to internal controls and risk assessments, as well as problems validating and checking taxonomies and instance documents. Following is a discussion of each.

Internal Controls
As XBRL becomes more integrated in the company's information supply chain, internal controls and their evaluation become more critical. Internal controls will need to be in place for:

• Creating, using, testing, and maintaining extension taxonomies.
• Mapping data to XBRL instance documents.
• Automating subsequent mappings.
• Performing change management activities related to all aspects of XBRL.

Consequently, internal auditors need to determine whether internal controls are documented properly and collect evidence to test those controls. Before this is done, the internal audit department should create an XBRL audit team to develop a technical understanding of XBRL and prepare an appropriate audit plan.

Auditors need to keep in mind that the XBRL instance document will influence the types of controls that need to be in place. For example, appropriate internal controls should be integrated as part of the XBRL instance document, when creating extension taxonomies, and when testing and maintaining a taxonomy's processes and procedures. If errors are accidentally injected into the XBRL instance document, or a perpetrator purposely makes changes to commit fraud, internal decisions based on those XBRL instance documents will be distorted.

Risk Assessments
From a risk assessment perspective, XBRL risks can be divided in four categories:

1. Technology risks.
2. Mapping errors.
3. Fraud risks.
4. External risks.

When examining technology risks, auditors need to determine whether XBRL is being used correctly and whether extension taxonomies are created and implemented correctly. Auditors also need to determine if extension taxonomies and instance documents were reviewed for their quality. One way to do this is by performing a round trip, a process in which the resulting XBRL instance document is rendered into human-readable text. Round tripping enables the auditor to compare the original document to the rendered document line-by-line to determine if the rendered document is a faithful representation of the original document.

The second kind of risk is related to mapping errors. For example, was the financial statement account mapped to the correct XBRL tag? Answering this question can help internal auditors determine whether the XBRL user who created the instance document made a judgment error (i.e., selecting an inappropriate XBRL tag) or a mechanical error (i.e., inadvertently mapping a concept to the wrong tag). Furthermore, because mapping risks are increased when the XBRL data is created in real time, the auditor may not be able to review the XBRL output. Therefore, algorithms used to tag the XBRL data need to be evaluated during the risk assessment.

The use of real-time reporting also will enable auditors to use continuous auditing. As a result, real-time reporting of XBRL data will not only affect the organization, but the use of continuous audit techniques as well. "Auditors who wish to use XBRL as a way to facilitate continuous auditing should consider becoming acquainted with XBRL by experimenting with it," Hoffman comments. "Build a prototype and try XBRL out. Prototypes are a great way to learn."

Fraud represents a third area of risk. A major question auditors need to ask is whether the XBRL instance document was used to commit fraud. The relative level of fraud risks depends on where XBRL is being used in the information supply chain. For instance, at the end of the supply chain (e.g., when supplying an instance document to the U.S. Securities and Exchange Commission [SEC.]), XBRL fraud risk is probably low. This is because perpetrators know it is relatively easy for anybody to compare the official filling with the XBRL instance document and uncover any differences. On the other hand, the risks associated with XBRL instance documents increase when XBRL is used internally by the organization because there may be no paper trails to compare instance documents, which also may not be reviewed by an independent third party (e.g., an external auditor).

Finally, internal auditors need to be on the lookout for any external risks that might affect the accuracy of XBRL-generated reports. A major external risk includes hacking attempts or vulnerabilities. For instance, because XBRL documents may include internal and external links to the organization, hackers may try to change those links or the linked files. This would enable the hacker to view the source code of an XBRL instance document, identify the names and locations of extension taxonomies, and make changes to the instance document or extension taxonomy. To decrease hacking attempts, auditors need to recommend that organizations have the appropriate firewall encryptions in place and that all firewall security controls are tested for their effectiveness.

A second source of external risks is the inappropriate reliance on XBRL documents. When an XBRL document is created, users may download the document directly into an analysis tool, ignoring the paper-based or other official documents that accompany the XBRL report. As a result, the report's consumer may not fully understand or be aware of any limitations that are part of the XBRL instance document, which was made available to the public. For example, the SEC allows companies to submit XBRL documents without their accompanying notes. Therefore, if someone downloads the XBRL document from a company's Web site or the SEC's EDGAR filing system, they may not fully understand all the information included in the report.

MOVING FORWARD

"XBRL can be used to overcome existing weaknesses in controls by improving the integration of data within an organization and to its auditors," Cohen explains. Although XBRL use carries its own audit and control implications, it "overcomes many of the issues and problems associated with the filing of paper-based reports and manual audit activities, such as manual entry and re-entry of information, and permits auditors to use centralized and standardized rules and tests," he adds. As a result, becoming acquainted with XBRL — its many benefits and control issues —  is of special importance to internal auditors and organizations as countries worldwide start to mandate its use, including the SEC in the United States. 

For additional information on the different audit and controls issues discussed in this article, auditors can refer to XBRL: Potential Opportunities and Issues for Internal Auditors (2005), published by The Insitute of Internal Auditors' Research Foundation.Glen

Gray, Ph.D., CPA, is a professor in the Accounting and Information Systems Department at California State University at Northridge.