This article is also posted on the re: The Auditors blog and can be found here.
What is XBLR?
For those who haven’t heard of it, XBRL (eXtensible Business Reporting Language) is an open standard for exchanging business information between systems. It is based on the open XML standards, which involves the tagging of data elements. Converting financial statement data into intelligent and interactive fields allows for applications and systems to more quickly analyze that data.
Today, all US-based publically traded companies are required by SEC mandate to provide XBRL versions of their financial statements, during a three-year phase-in period. The largest companies were required to do this starting in June 2009. The remaining companies are required to file interactive data on a phased-in schedule lasting through mid-2011. Other regulators, such as the Federal Deposit Insurance Corp. and the U.S. Office of the Controller, have been requiring XBRL for the filing of call reports for some time.
The technical process of converting financial data into XBRL relies on a taxonomy of accounting terms and the matching of Generally Accepted Accounting Principles (GAAP) “element” to an XBRL “tag”. The current US GAAP taxonomy has approximately 15,000 distinct elements. Early adopters of XBRL had could map and tag the data in-house or outsource the effort. While some of the larger companies performed the work internally, a recent survey by the AICPA and XBRL.org indicates that outsourcing has been a popular choice for cost purposes.
What are the Risks?
Regardless of whether the company chooses to outsource the conversion or not, the company whose financial statements are being converted to XBRL is still responsible for the accuracy of the output data. In addition, the introduction of a third party performing this work introduces the risks from errors and omissions to operational errors such as missing a filing deadline, sending the wrong file, and data security breaches.
Many companies do not have the formal reconciliation and approval processes in place with XBRL vendors as they normally have for a payroll vendor, for example, who files tax reports and makes payments on behalf of the company.
One speaker at the Financial Executives International (FEI) Current Financial Reporting Issues Conference this past November, the Chief Accounting Officer at a Fortune 500 pharmaceutical company, described an incident where their vendor had sent the wrong file to the SEC. This necessitated a subsequent filing to correct the erroneous data. In this case, the company caught the erroneous filing, not the vendor.
Current Audit Practices
Today, there is a concern that XBRL is not being thoroughly reviewed by external financial auditors. The Public Company Accounting Oversight Board issued guidance in 2005 on external auditor engagements regarding XBRL, which relies on the auditor agreeing on a paper-only versions of the XBRL-related documents to the information in the official filing.
The PCAOB rules allow an auditor to perform an examination under attestation (AT) Section 101 that would include:
- XBRL data agrees with the official EDGAR filings, and
- XBRL-Related Documents are in conformity with the applicable XBRL taxonomies and specifications, as well as with the SEC requirements for format and content.
For larger companies, reviews of XBRL have been performed under the framework provided in the AICPA for Agreed Upon Procedures (AUP) otherwise known as AT section 201. AUP engagements are specific between one company which engages the audit firm, and another company to be audited, in this case the vendor and would generally be specific to the company’s specific data, and the two or more companies specifically agree to have the audit firm perform certain procedures. AUP reports are not shared reports and can only be used by companies specific to that agreement. These reports are mainly seen as an extension of the financial statement audit.
Alternative Approaches and the Path Forward
It would seem that the more appropriate and cost effective path would be to have these third-party vendors be examined or reviewed under an attestation following the AT section 101 framework. One benefit of using this framework is that the report could potentially be made available for use by multiple companies. In addition, the Trust Services frameworks fall within AT Section 101 such that a third-party provider could obtain a SysTrust® examination for their services.
If history remains consistent, the combination of a compliance requirement for XBLR and the desire to do so at the lowest cost will result increased outsourcing. With this comes increased risk of a provider’s technologies and processes inaccurately reflecting the financial position of the company. Like any outsourcing, companies looking to outsource this function should inquire the provider’s processes and controls as well as the types of audits and certifications it has undergone to validate those controls.