XBRL (eXtensible Business Reporting Language) has taken center stage as the assumed standard for the tagging and reporting of business information. A common refrain from the XBRL community, including accounting firms, regulators, data aggregators, analysts and software providers: everyone with a vested interest in higher quality data being provided to investors. Underlying this is a fundamental change, a change not seen since the first cave wall – the move from “document centric” to “data centric” reporting.

XBRL provides the opportunity to radically change assumptions about that data.  In this note we look at one specific area where XBRL, or the provision of information tagged at the data element level, has the ability to impact data - at the level of assurance being provided.

Assurance, and the level at which assurance is provided today, remains purely document centric. Assurance is not provided over individual data elements or pieces of information.

Basically if the accountants, SEC and analysts say that the XBRL will improve transparency, but it is not subject to audit and has litigation relief, then why is an audit required on rest of the filings - especially as there is plenty of opportunity to introduce errors (accidentally or intentionally) between creation of the official filing and the XBRL.

Current Assurance

Currently assurance is provided over the document (the financial statements) "taken as a whole". This means two things - that the document, as a whole in concept and intent, can be trusted, and, that individual figures in the document are not included in that assurance. In addition, almost all audit reports will include a phrase stating that the financial statements “present fairly, in all material respects, the financial position of” the company.

Individual figures do not have assurance. Each individual number may or may not have been subject to detailed analysis. Individual figures may or may not have been traced back to original documentation, accounts or invoices.

The auditing profession has been able to use this for decades as the ultimate defense in litigation - the audit followed standards, looked at all material accounts, and performed detailed testing at the level required to confirm those accounts. Certainly it is possible that an individual figure may not have been correct due to error or intent. However, the auditor performed their engagement fully in compliance with professional standards.

"Taken as a Whole" has provided the greatest protection to the auditor, and to the client, for decades. Auditors, and clients, understand that with current technology, liability insurance and personnel costs (and margins needed to ensure target profitability) that it is not possible to review all accounts and all figures used to create the accounts. Coincidentally this also helps explain the audit firms interest in litigation relief.

Individual data elements, while used and useful to investors, do not have assurance.

The Promise of XBRL

The promise of XBRL is that users of information will be able to select exactly the information that they wish to use, without needing to consume the entire document, or to search through documents for the elusive piece of information.

The only problem is that by consuming only the individual data elements that the user wants, the chain of assurance is broken, the document is no longer "taken as a whole", and the user has no confidence that the data elements consumed were subject to assurance procedures. So, can the consumer of the information trust the integrity of the individual data element that was used? The company and auditor will tell you that it was audited, but will give no assurance over that individual piece of information.

Only with the provision of data-level assurance will it be possible for the consumer of the information to know that the specific elements used were subject to assurance. But this does not mean that the auditor would be willing to say that this piece of information was subject to assurance, while that piece of information was not.

Data-level assurance, like its close cousins "continuous assurance" and “process level assurance”, are the subject of ongoing debate and discussion. How can this be achieved economically. What are the legal liabilities of failure to provide assurance over one element, while performing in-depth analysis and examination of another element? Will the principles of materiality change in an environment of continuous or data-level assurance.

Drivers and challenges for data-level assurance

The very promise of XBRL and tagged data to allow element specific consumption of financial and business information is predicated on a change to the assurance model.  “Taken as a whole” provides very little value in a world in which the “whole” is no longer of overriding importance.  The ability to provide assurance at the data-level will increase consumers (analysts, regulators, investors, banks) that the information being provided is accurate.

The accounting firms that are able, working with their clients, to deliver realistic assurance at the data, process or continuous level, will gain a significant strategic advantage. The ability to provide assurance at the detailed level within a cost structure comparable or nearly comparable to current assurance “taken as a whole” will add a level of confidence to information that cannot be gained from current audit and assurance reports.

One key challenge will be in development of standards for such assurance, not to mention cost effective processes for the provision of such assurance. However, the ability with XBRL to build controls into the data (through the use of custom taxonomies) may provide the ability to deliver process level assurance, with the auditor being able to confirm on an ongoing basis the functioning of processes and controls, without the need for periodic inspection.

So XBRL will deliver data centric information to consumers of that information. But until assurance is possible at the data level (or process level) then consumers must either accept that the information is, in effect, not audited. In addition, if the XBRL information is to be the information of choice for consumers, then without that assurance, the value of the current audit environment is called into question.