Summary of Information Related to Verification of XBRL-based Financial Reports
Saturday, March 3, 2012 at 07:39AM
Charlie in Creating Investor Friendly SEC XBRL Filings

The following is a summary of information related to the verification of XBRL-based financial reports. I have accumulated this information as part of trying to figure out how to verify SEC XBRL financial filings.

To start, let me define verification.  By verification I mean:

The primary points here are that (a) verification is tangible proof that the financial report is "true and fair" and that (b) verification by the party who is not independent or verification by a third party that is independent has to do with WHO did the verification, not what work is done to verify the financial report.

What I want to stay away from here is the debate as to whether an auditor "audits" financial information expressed using XBRL.  There is a boatload of work that goes into making sure the numbers and other information are "presented fairly" and what exactly goes into the financial report.  That is definitely "audit" or "attest" type work.  I am not talking about that audit work.

There are two sources of information related to verify or "address the completeness, accuracy, or consistency of XBRL-Tagged Data" (basically, what one needs to do to achieve verification):

This blog post of mine has links to both of these documents. The second document has references to other resources. The second document, the paper, makes the following statement:

SOP 09-1 provides only an illustrative list of management assertions for handling the XBRL-tagging engagements under the SSAEs as agreed-upon procedures without considering a framework. Without a conceptual framework, the assurance process for XBRL instance documents would be ad hoc and inconsistent.

I agree with that statement, a conceptual framework is important.  The paper provides a conceptual framework.  I cannot tell if the authors are holding that out as "the conceptual framework".

Another important thing pointed out by the paper is that the reliability of software applications which are used to assist accountants, management or third party accountants is critical. One must understand what the software is doing, what it is not doing, and different software applications should perform the same fundamental processes in the same manner.  Today software is more like a "black box" and no one understands exactly what the software is doing and no software could possibly perform all the steps because the steps are not even defined adequately (more on that below).

I would point out that neither the AICPA SOP nor the paper provide a detailed set of steps that, if followed, would ensure that said document is correct, accurate, consistent, etc.  What I am wondering is how a conceptual framework can be specified without knowing all the detailed steps which are necessary.  Maybe you can do that, but it has been my experience that people who try and summarize things before they understand all the details tend to make mistakes and leave things out.

I would point out that there are three things I believe that both the AICPA SOP and the paper are doing which I believe should be done differently.

  1. Both mix terms that relate to the XML/XBRL technical syntax and terms that relate to semantics. It is my view that there is no need to use terms that relate to technical syntax at all.
  2. Both focus on "XBRL". What if other formats for expressing financial information come to exist or of someone chooses to use RDF/OWL or some other form of XML?  Further, it is because there is a focus on XBRL here that leads to mixing the XML/XBRL technical syntax and financial report semantics and terminology which is both hard to follow and difficult for a business person to understand.
  3. Neither provide enough details as to the steps necessary.

Fundamentally, I believe that a set of verification assertions has no need to consider the medium or format by which the financial information is being made available; be that format traditional financial reports made available on paper; in electronic form such as Word, HTML, or PDF; or even digital form such as XBRL, RDF/OWL, other forms of XML; or other digital formats/mediums such as within some sort of software application for viewing or otherwise consuming financial information.

The Financial Report Semantics and Dynamics Theory has no regard for medium or format of financial reports. This theory breaks financial reports into pieces which are understandable to business users:

This video walks you through this set of primitive or fundamental or rudimentary building blocks of a financial report. These building blocks have no regard for medium/format.  I believe they are understandable to business users.  While business users may disagree on the name of the building block, it is rather hard to dispute the notion of these rudimentary building blocks.

And so, if there are a set of building blocks and if that set of building blocks and each building block's properties are finite; it seems to me that a definable, finite set of steps can be articulated and if one does not lock themselves into one technical syntax, then you can rely on only financial report semantics to articulate these steps.

To be clear I want to list the high level objectives which I believe are important to verify a financial report and define some important terms:

I have provided a detailed set of characteristics of a quality financial report, I repeat that set of characteristics here having "tuned" them to the Financial Report Semantics and Dynamics Theory and the other ideas and notions I have come across:

As such, I venture to summarize all these pieces into a set of risks, assertions to overcome that risk, whether the verification can be automated or must be manually performed, and the required skill level necessary to perform such step:

So now I need to come up with the precise detailed steps for all of this and then cycle those through all this information to be sure the big picture and the details fit together.  Give that I have already been through all these detailed steps with my model/reference implementation for an SEC XBRL financial filing I do understand most of the steps (here are the steps which I have thus far, they are also detailed and explained in this document which explains the working prototype verification application which I created).  Basically, what I really need to do is organize those detailed steps within this framework.

Article originally appeared on XBRL-based structured digital financial reporting (http://xbrl.squarespace.com/).
See website for complete article licensing information.