Guest Post: Is Assurance Required For XBRL- Based Financial Reporting?

This is another in a continuing series on XBRL, a subject I don’t think has had enough attention outside of subject matter expert blogs.

Ryan Buckner is a Shareholder at BrightLine CPAs & Associates Inc. With over 10 years of experience in the fields of public accounting and IT auditing, Ryan is responsible for leading SAS 70 and SSAE 16 assessments, AT 101 examinations, and Trust Services certifications throughout the southeastern United States. He is also a leader in the development of the company’s methodologies.  After beginning his career at Arthur Andersen, Ryan joined SAS 70 Solutions in 2003.  He maintains the professional designations of CPA, CISSP, CISA and CIA.

Founded in 2002 as SAS 70 Solutions, BrightLine CPAs & Associates Inc. was the first CPA firm established specifically to provide audit services in accordance with Statement on Auditing Standards No. 70 (SAS 70). Over the years, its service lines have expanded to include other complementary audits and assessment services. The company provides SAS 70 and SSAE 16 assessments, PCI DSS validation, ISO 27001 and 27002 assessments, and AT Section 101 attestation services, including WebTrust and SysTrust certification to hundreds of clients worldwide. BrightLine is a licensed Certified Public Accounting firm and is registered with the Public Company Accounting Oversight Board.

********************************************************************************************************************

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 publicly 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 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® certification 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 in 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 about the provider’s processes and controls as well as the types of audits and certifications it has undergone to validate those controls.