XBRL Assurance

The anticipated growth of XBRL use and its potential to replace traditional financial statements and electronic version of such financial statements in HTML or PDF format raises important assurance issues related to the information in ‘XBRL Instance Documents.’ Many companies that are currently providing their information using XBRL are doing so with limited quality assurance due to a lack of guidance on the best practices and limited auditor involvement. This poses a significant threat to the reliability and quality of XBRL-tagged financial data.

Auditors currently attest to the material accuracy of the financial statements using generally accepted principles of accounting (GAAP) as the criteria against which the financial statements prepared by the management are evaluated. Attestation on the financial statements does not apply to the current process of creating XBRL Instances, and it is not clear what criteria would be used by the auditors or others as they provide assurance services in XBRL environment. In contrast to a traditional financial audit, the subject-matter in an XBRL assurance engagement would be on the XBRL ‘documents,’ which are computer-readable files created in the tagging process.

There is a misconception that tagging of information in XBRL is similar to converting a Word document into PDF file and that tagged XBRL data is as accurate as the underlying information in the source documents from which it has been created and hence Assurance on XBRL Instance is like the original to a zerox copy being certified. This is an inappropriate analogy, because the process of tagging involves judgment and there is potential for intentional or unintentional errors that could result in inaccurate, incomplete, and/or misleading information. This is a problem because it is the XBRL-tagged data that will ultimately be consumed and used for decision-making purpose. Therefore, completeness, accuracy or consistency of the XBRL-tagged data is of paramount importance.

Potential risk in XBRL instances

• Information on Identity of reporting entity could be wrong or might have changed from previous year. It will make the retrieval and comparison of financial data more difficult for the users.

• Nature of financial data could be wrong e.g., audited or unaudited, budged or actual, revised or re-grouped or re-casted, etc. It will make the comparison of financial data difficult.

• Information on reporting period could be wrong e.g., an XBRL instance document with a reporting period of Q 3 2011 erroneously puts the reporting period as Q 3 2001. ? Currency could be wrong e.g., an XBRL instance document filed in India with all monetary values in US Dollars will make the task of comparison difficult. Of course the comparison can be done after converting all monetary values in Indian Rupees, but then there is a risk involved in the currency conversion.

• Precision or scaling in monetary values contained in an XBRL instance document could lead to inaccurate data not suitable for comparison and analysis purposes e.g., Turnover of Rs.1,65,85,987 will be rounded off to Rs.2 crores if the precision measure taken in XBRL Instance document is ‘Rs. in Crores.’

• Segment information could be wrong or might have changed from previous year. It can make the segment comparison difficult for the user.

• Technical reference information in XBRL Instance document can point at wrong taxonomy which will make it difficult to compare with other XBRL filings.

• XBRL validation is a pre-requisite for the regulators and users of XBRL data. They can’t commence using XBRL data unless XBRL Instance document passes the validation test.

• Base reference information could be wrong e.g., pointing to XBRL taxonomy on computer’s hard disk instead of official XBRL taxonomy.

• Selection of wrong tags for reporting financial data in XBRL instance document will not only make the XBRL data inaccurate, but will also make it less usable.

• Reporting wrong data in XBRL instance document even though the tag selection is right, will make the XBRL data inaccurate and less reliable.

• Failing to mark-up a concept will lead to some vital information missing in XBRL instance document.

• Closed taxonomy risks mainly consist of integrity and accuracy of data. Since, taxonomy extensions are not allowed in a closed taxonomy, the filer needs to tag the financial data with the residuary tag which could lead to wrong conclusions e.g., if a filer doesn’t find any suitable tag for a line item in his Profit & Loss Account, he needs to tag it with ‘Other Income’ or ‘Other Expenditure’. The filer could also use a wrong version of taxonomy for XBRL instance generation.

Open taxonomy risks mainly relate to creation of a new taxonomy element (taxonomy extension). The filer could create a duplicate element for a concept that already has an element in the base taxonomy or could create an inappropriate or misleading taxonomy element. The taxonomy extension may not comply with the rules of XML and XBRL. The filer could use prohibited name in taxonomy extension.

Evaluating the quality of XBRL formatted information

Completeness
All required information and data as defined by the entity’s reporting environment is formatted in the XBRL Instance document and is complete in all respect.

Mapping
The elements viz. line items, domain members and axis selected in the XBRL file are consistent with the associated concepts in the source documents.

Accuracy
The amount, date and other attributes e.g., monetary units are consistent with the source documents.

Structure
XBRL files are structured in accordance with the requirements of the entity’s reporting requirements.

Approach to XBRL assurance
Srivastava & Kogan had presented a conceptual framework of assertion for XBRL instance documents for XBRL filings at SEC.

• Whether the XBRL instance document has captured all the facts and data of the financial statement in traditional format or not?

• Whether the XBRL instance document contains any fact or data which is not present in the financial statement in traditional format or not?

•     Whether all the element values and attribute values (context, unit, etc.) in XBRL instance document correctly represent the data in the financial statement in traditional format or not?

•     Whether the XBRL instance document complies with all XML syntax rules or not?

•     Whether the XBRL instance document complies with all rules of XBRL and referenced XBRL taxonomies or not?

•     Whether the XBRL tagging in the instance document properly represents the fact/data in the financial statement in traditional format or not?

•     Whether the XBRL instance document references correct version and industry specific taxonomy or not?

•     Whether the taxonomy extensions created and used in the XBRL instance document comply will all rules of XML and XBRL or not?

•    Whether the new elements in the XBRL taxonomy are not duplicate or misleading or not?

•     Whether the Linkbases used in the XBRL taxonomy extensions are appropriate or not?

Control Tests and Substantive Tests
Control Tests and Substantive Tests need to be designed and applied to mitigate the risks in XBRL instance documents.

The Auditors are familiar with internal controls over the accounting processes. However, in the case of assurance over XBRL instance document, internal controls over XBRL tagging process need to be checked. The control tests need to be applied on:

(i)    the effectiveness of the XBRL tool that has been used to generate XBRL instance document; and
(ii)    the effectiveness of the validation tool

Substantive tests

In traditional audit sampling, the auditor is expected to specify either tolerable error or tolerable deviation rate and a desired reliability in order to determine a sample size sufficient to meet the audit objectives. However, in the case of audit of an XBRL instance document, since the objective of sampling is to determine whether tagging process has resulted in a material misstatement; an attribute sampling approach would not be appropriate. One can imagine a situation where a single wrong tagging results in a material misstatement or where numerous wrong tagging aggregates to an immaterial amount of error.

Materiality

The current auditing processes for examining and reporting on financial statements are designed to ascertain that, ‘taken as a whole’, the financial statements are free from any material misstatement and present a ‘true and fair view’ of the state of affairs of any company. The concept of materiality in the context of traditional audit of financial statements refers to the probable impact on the judgment of a reasonable person of an omission or misstatement in financial statement. In conjunction with auditors risk assessment, materiality’s role in planning a financial statement audit is to determine the allocation of audit efforts and in the opinion formation phase of the audit to evaluate the implications of the audit evidence on the financial statements ‘taken as a whole’. However, in case of XBRL, where a single inappropriate or mis-leading tag could result in the XBRL document ‘taken as a whole’ being materially misstated, the concept of materiality can’t be applied the way it is being applied to the audit of traditional financial statements.

In audit of XBRL instance document, two kinds of materiality need to be considered:

(i)    Materiality for the entire financial statement; and
(ii)    Materiality for each line item in the XBRL instance document.

Since the materiality concept used in the audit of financial statement is at the aggregate level, the implied materiality in the XBRL instance document is also at the aggregate level. However, since users of XBRL data are going to use each line item separately in their decisions, they will perceive each line item to be accurate in isolation. This would lead to erroneous decisions.

Conclusion

The focal point of XBRL assurance is the evaluation of the accuracy and validity of the XBRL tags applied to the line items in the financial statement of the company. In order to perform these evaluation, the auditors need to have the knowledge of what constitutes an error in XBRL instance document, what is the potential risk in XBRL instance document, how control tests and substantive tests should be applied in XBRL environment, and how materiality should be conceived and applied to XBRL instance document.

References
1.    Bovee, M., A. Kogan, K. Nelson, R. Srivastava, M. Vasarhelyi. 2005. Financial Reporting and Auditing Agent with Net Knowl-edge (FRAANK) and extensible Business Reporting Language (XBRL) Journal of Information Systems, Vol. 19. No. 1
2.    Boritz, J. E. and W. G. No. 2007. Auditing an XBRL Instance Document: The Case of United Technologies Corporation

3.    Plumee & Plumee (2008) Assurance on XBRL for Financial Reporting

4.    AICPA — Proposed Principles & Criteria for XBRL Formatted Information

5.    Rajendra P. Srivastava & Alexander Kogan (2008) — Assur-ance on XBRL Instance Document: A Conceptual Framework of Assertions

6.    AICPA — Performing Agreed Upon Procedures Engagements That Address The Completeness, Accuracy or Consistency of XBRL Tagged Data
7.    ICAEW  —  Draft  Technical  Release  for  Performing Agreed Upon Procedures Engagements That Address XBRL Tagged Data Included Within Financial Statements Prepared in An iXBRL Format.