When XBRL was in its infancy, much of my attention was spent trying to improve the intersection between the auditor’s report and management’s financial statement.

(click on the title to read the full article)

Others could focus on “comparability” or facilitating the numbers jumping into spreadsheet models. One of the directions I was tasked with was establishing new ways to make clearer what was covered by the auditor’s report, and what was not. Twenty years later, that remains an open item, despite our early efforts.

The auditor’s report (ISA 700, AS 3101, AU-C 700) normally begins with an introductory paragraph that tells what part(s) of the associated presentation falls under the auditor’s scrutiny. The PCAOB refers to “[a} statement identifying each financial statement and any related schedule(s) that has been audited” and “the financial statements, including the related notes and any related schedule(s)”, while ISA speaks to “the title of each statement comprising the financial statements” and “the notes, including the summary of significant accounting policies”.

Perhaps that is clear enough, although there was evidence that readers often didn’t know what, beyond the basics on paper, was included or excluded. And there isn’t much room for expansion – such as 2011-2013, when the PCAOB considered expanding the opinion letter for information outside of the financial statements, such as MD&A or non-GAAP information or earning releases – how could the introductory paragraph make the difference clear for a human reader without keeping their finger on the auditor’s report while reading the financial statement?

But providing an automated tool to explicitly highlight what is covered by the Auditor’s report or, conversely, what is not, was something we saw XBRL able to facilitate. The auditor could point to the facts included in their coverage, and then highlighting could be turned on or off.

This was just a beginning. If there was more than one kind of assurance involved – such as reasonable assurance on some content and limited on other content (and nothing obvious on some more, and none on the rest), the new platform could support it. Or If different materiality levels, or degrees of stochastic assurance, or other options were present, or even different auditors opined on different parts of the same report, the new platform could expand.

I called this “data level assurance” – not necessarily because the (immediate) goal was getting rid of “taken as a whole” or “true and fair view”/”fairly represented” … but because we were going to leverage the power of XML to move beyond a document, give it or take it, to machine help based on the content. One might consider this focus on an existing presentation very backward; it does not move forward the concept of a data approach, where the data plus the necessary context, not tied to a specific presentation, becomes the document of record, which is a path I do believe in; I was merely trying to leverage XBRL to make the traditional report with assurance more transparent to readers. The primary existing example of XBRL assurance, found in the Netherlands, still relies on a normative presentation, now known as the Consistent Presentation (CP) (https://www.sbr-nl.nl/sbr-international/what-sbr/assurance).

My colleague on ThinkTwenty20.com, Editor in Chief Gerald Trites, led a CICA Study Group on Data Level Assurance in 2011, in which I participated, and wrote a research study on the topic. So I am in good company here. 

What do you think? Is the introductory paragraph, with what is covered by the auditor’s report, a fine place for what the future will hold? Or will more explicit, interactive tools be helpful, necessary, and worth pushing for? Can we get past management’s presentation, or a single, consistent, normative presentation defined by a third party and get to assurance on data in context rather than data as presented?