Digital Financial Reporting

The chatter related to third-party audit or assurance of XBRL-based digital financial reports is increasing.

In the blog post, Audited Digital Financial Statements: They Improve The Process Too, Mohini Singh, director of financial reporting policy at CFA Institute, urges regulators and audit standard setters to take heed of what investors want; pointing out that "77% of investors want independent audit or assurance over Inline XBRL documents."

In another blog post, Should XBRL Financials be Audited?, Lou Rohman, Vice President, XBRL Services, Merrill Corporation, points out the strong probability that the European Commission will require Inline XBRL documents to be auited in 2020 when mandated XBRL filing starts.  Mr. Rohman says,

"It seems logical that an XBRL audit will be required, not only because the EU mandate requires the submission of the annual financials to be in a single Inline XBRL format (with no separate .pdf or HTML document), but also because much of the consumption of the financials will be XBRL-based."

In a post to the XBRL-Public group, Glen L. Gray, PhD, CPA, Professor Emeritus, Dept. of Accounting & Information Systems, California State University, Northridge, points out that in the Netherlands like many other European countries, both private and public companies submit financial statements with the government.  He says that starting in January 2017, about 215,000 private companies were required to start filing using XBRL.  In January 2018, medium and smaller companies must begin using XBRL.  Then in January 2019, larger public companies will be required to use XBRL. Dr. Gray points out, "Eventually those filings must be audited."

In a presentation at Rutgers University, Auditor’s report on XBRL-based financial statements in the Netherlands, Sebastiaan Bal, quantifies the number of companies in the Netherlands to be about 900,000 companies (page 3).  Mr. Bal discusses some high-tech approaches to signing reports using something like XAdES (XML Advanced Electronic Signatures) (pages 11 - 12).

What about tools for auditingthe meaning conveyed by such XBRL-based reports?

CompSCI offers a product to the market, XBRL audit | Pro. But given quality measurements of the filings CompSCI creates, I really don't know how good that tool might be.

XBRL Cloud offers software that checks for errors in XBRL-based financial reports that are submitted to the SEC.

The software vendor CoreFiling has a product called Magnifythat they say can be used to review XBRL-based reports submitted to regulators.

There are likely other software vendors, I have not done an exhaustive search.

Given the known quality issues in both the primary financial statements and the disclosuresof XBRL-based financial statements of public companies, either (a) the tools are not working as well as they need to work in their current state or (b) public companies reporting to the SEC in the XBRL format are not employing the tools.

I put together three documents that are relevant to this discussion.  The first document, Thoughts on Auditing XBRL-formatted Information, summarizes my thoughts related to the audit of the meaning conveyed by XBRL formatted information.  Auditors are not going to "audit XBRL", they audit the meaning conveyed by the XBRL formatted information.

The second document, Blueprint for Creating Zero-Defect XBRL-based Digital Financial Reports, I point out the things that I do to make sure meaning conveyed using XBRL-based financial reports are of high-quality, pointing out that many steps in this process can be automated but there are still some manual steps that can likely never be automated.

In the third document, Process of Verifying Quality of an XBRL-based Financial Report, I outline an efficient, effective, reliable, and repeatable process for verifying that an XBRL-based report is created correctly. This includes both the primary financial statements and the disclosures. (This document describes the techniques used to create that process.)

Finally, the fourth document, Making the Case for Reporting Styles, I outline how I manage variability in public company financial reports.  While financial reports are not "forms", they are not "random" either; patterns are identifiable and leveragable.

While there are a lot of questions related to the auditing of the meaning conveyed in XBRL-based financial reports and in my view academics really should step up to the plate and do some deep thinking about this issue; there are certain important facts and realities that need to be considered.  Further, I believe that the points below are self-evident if you really think about them and should be used to frame that discussion of auditing XBRL-based digital financial reports so that the risk of going down the wrong path is minimized:

1. Ultimately, XBRL-based digital financial reports will be the only type of financial reports. 
2. Ultimately, multiple documents is foolish.
3. The question that has to be answered BEFORE you can "audit" a report is to properly and adequate define what "correct" looks like for an XBRL-based digital financial report. The only way you can DEFINE "correct" is to provide proof in the form of tangible empirical evidence that proves that definition of correct.  Simply putting "stuff" in a document and having someone that believes they have authority pontificate or worse speculate what correct might look like is not the right approach.
4. If you cannot measure it, you simply CANNOT control it.  That is a fact of life.  What "correct" means and how "correct" is measured must be defined and tested.
5. If public companies cannot get XBRL-based financial reports right, who can? Once external financial reporting managers, maybe internal auditors, and filing agents can create reports correctly, then third-party independent auditors can also get these reports right.  What makes you believe that auditors might have some magical recipe for getting XBRL-based financial reports correct?   All of the clear quality issues that exist in the XBRL-based reports of public companies is a symptom of some problem.  What is the issue?
6. So, why can't public companies get their XBRL-based reports correct?  There has to be one of two reasons: (a) the software than they have available is not up to the task, or (b) public companies are not using the available software correctly or at all.
7. Do external financial reporting managers, filing agents, auditors, and others trying to do this correctly aware of the quality issues?  Or, can they only react to a quality problem because that problem has been pointed out to them?  Is part of this a training/education issue?  What is the specific skill that auditors have that external financial reporting mangers don't have that make auditors magically be able to do a better job than external financial reporting mangers?
8. Because of the structured nature of the information in XBRL-based financial reports, certain tasks that could never be performed in the past using automated processes (i.e. because the information was unstructured); can now be performed using automated processes making some audit processes more efficient.  Perhaps, even more effective.
9. How much can be automated is directly impacted by exactly TWO things: (a) the power of the problem solving logic available to process machine-readable rules and (b) the extent to which machine-readable rules have been created which the problem solving logic can use.

Are there other things that must be considered?  Undoubtedly.  But, it would be very hard to dispute any of the facts stated above.  Take a stab at it if you want.  We all might learn something.  My view is that the facts above can and should be used to frame any discussion about whether, how, or when XBRL-based financial reports should be audited.