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.

Rene van Egmond and I created the first version of the Financial Report Semantics and Dynamics Theory back in 2012.  This theory explains the mechanical, logical, structural, and mathematical dynamics of a financial report in terms that are understandable by business professionals.

A theory is a tool for understanding, explaining, and making predictions about a given subject matter. A theory describes absolutes. A theory describes the world and tries to describe the principles by which the world operates. A theory can be right or a theory can be wrong; but it has one intent: to discover the essence of some subject matter.  A theory provides a framework and principles for thinking about or explaining something deeply, thoroughly, and rigorously.

For the past 5 or so years I have been working to better prove this theory in order to tune the theory.  That proof is documented within the theory.  I am still collecting empirical evidence from XBRL-based financial reports of public companies that are submitted to the U.S. SEC.  The proof is getting so good that I am now finding accounting errors in the financial reports of public companies and flaws in the underlying US GAAP.  (I mean US GAAP, not the US GAAP XBRL Taxonomy.)  This is all explained in this document, Making the Case for Reporting Styles.

All this information is documented in the conceptual model that I have created for a digital financial report.  In addition, the conceptual model is being represented in the W3C stack of technologies(RDF/RDFS/OWL/SHACL).

The conceptual model is not for US GAAP.  The conceptual model is independent of any financial reporting scheme and I have created three separate "profiles": one for US GAAP, one for IFRS, and one for an imaginary reporting scheme that I call XASB.  The XASB reporting scheme is for testing independent of the existing XBRL taxonomies for IFRS and US GAAP.  Another profile exists for business reporting.

There are two software implementations that leverage this conceptual model.  One is commercially available via XBRL Cloud.  The other is a successful working proof of concept that was constructed by a software engineer and I to test the feasibility of creating an expert system for creating financial reports and tune the conceptual model even further to support that endeavor.

All this information was obtained by literally reverse-engineering the complete set of XBRL-based financial reports that are submitted to the U.S. SEC by public companies (not including funds or trusts, but everything else).

If you are wondering WHY I have been focused on this for the past 10 years or so, I would encourage you to read the document Getting Ready for the Digital Age of Accounting, Reporting and Auditing: a Guide for Professional Accountants.

In my view, digital financial reporting will be one of the early applications of artificial intelligence, just like accounting systems were one of the early uses of computers.  You can already see signs of the sorts of things computers will be able to achieve.  In is my observation that the "financial reporting" use case and in particular the US GAAP financial reporting use case is one of the more complex business use cases for XBRL.  If you want to truly understand XBRL-based digital business reporting, XBRL-based financial reports submitted by public companies to the SEC is something worth studying.  This in no way takes away from other alternatives to implementing XBRL-based digital business reporting such as the "Data Point Model" approach or the "Standardized Business Reporting" approach.  I am simply documenting another approach which has a certain basket of "pros" and "cons" that are worth looking into.

If anyone wants additional information or has any feedback, please feel free to contact me.  I am not an academic or an information technology professional, but I have done the best that I am capable of currently.  If you know of someone who has done better, please make me aware of that.  I can imagine that there are likely lots of ways to expand on this foundation.

Here is a second version of an information extraction and validation working prototypethat I updated that people can download and fiddle with. This version loads and validates one XBRL-based filing at a time and uses a form to select the filing.  I loaded this with public companies that use the "COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6" reporting style only.

NOTE!!! I originally created this Excel based application in 2013. It does not use the most current metadata for the mapping rules and the impute rules.  You can find the most current rules here for the COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6 reporting style.  Here are the rules for MOST reporting style.

Keep in mind that I am not a programmer, so I am not really proud of the code. But, this is a REALLY good example of how to validate and extract information from an XBRL-based financial report.

Here is the other information extraction and validation toolthat I made available a week or so ago. That works with the "INTBX-BSU-CF1-ISS-IEMIX-OILN" reporting style.  Here is the most current rules for that reporting style.

So how do you know what reporting style a public company uses?  Well, you can probe the filing and figure it out that way.  That is advanced.  In the mean while, you can simply read this REST interface.  Here is the human readable format: COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6 and INTBX-BSU-CF1-ISS-IEMIX-OILN.

If you go to the LEFT hand side you will see a number with a LINK.  Click on the link and you will see this. That is a REST interface that will supply you with the reporting style code for all public companies that currently file with the SEC.

A great way to understand how XBRL-based financial reports really work is to reverse engineer one of these two prototypes.  An even better way is to rip out the hard-coded rules and replace them with the XBRL-based metadata referenced above and make the tools more dynamic.

Why is any of this important???  Read page 16 through 18 in this document where it talks about CLIPS. You may even want to just read the entire document.