Using Rules to Eliminate Blind Spots

A system is in effect “blind” to things not covered by that systems rules.  In the past I have said a similar sort of thing by explaining that rules provide "guardrails" or "bumpers" or "guiderails".

The following graphic helps one understand the value of the Standard Business Report Model (SBRM) and the guidance of the Seattle Method.  On the LEFT are the “pillars of quality” that the FASB and SEC seem to be currently relying on: the XBRL technical syntax and some rules about the math in a report that tends to not be enforced.  On the RIGHT is how my Seattle Method sees a financial report and how I hope SBRM sees financial reports and business reports.  Again I say:

A system is in effect “blind” to things not covered by that systems rules. (Click here for larger image)


Think about that statement a minute. What exactly, if not system rules, is the software system relying on in order to understand information if not for the rules of the system?  Magic?

Why does this matter?  Well, let's look at this in terms of sigma levels.  What if you could move your quality level from sigma level 3 to sigma level 6?  At sigma level 3 highlighted in yellow below you have a 6.7% defect rate which gives you 66,807 defects per million of opportunities (DPMO).  At sigma level 6 highlighted in green below you have a 0.00034% defect rate which gives you 3.4 defects per million of opportunities (DPMO).


There are lots of things that can go wrong when you create a general purpose financial statement. And there are penalties for noncompliance with regulators and liability ramifications related to someone relying on a financial statement an economic entity has provided.  And so, these information artifacts tend to be of rather high quality.  But today, that high quality is achieved by throwing loads of manual effort by armies of expensive accountants to get the error rate to an acceptable level.  With the complexity of financial reports increasing, the volume of information in the reports increasing, and the pace at which these large, complex information artifacts flow; the system is being stressed.  Add to that the shortage of accountants which exists.

What if some of this work could be offloaded to computer based processes?  In the past this was for the most part impossible.  Why?  Well, because a computer based process could not understand the financial statement that it was provided.  Sure, software understood the report in terms of paragraphs or tables or other presentation oriented artifacts; but it could not actually understand the actual financial statement because  (a) the information is structured for presentation of the information in a document and (b) there was no meaning conveyed using standards.

This all changes with XBRL-based digital financial statements.  Not only is the information represented in terms of meaning of the information; but that structured meaning is conveyed using the global standard semantics of US GAAP and/or IFRS and those standard semantics are provided in the form of XBRL-based taxonomies that proper software can understand and process.

But neither the FASB nor the IASB provide the necessary machine readable rules to prove through automated software based verification that the financial statements are correct.  That means two things.  First, the quality of the XBRL-based financial reports submitted to the SEC and ESMA tend to be closer to sigma level 3 or likely even less in terms of quality and therefore the software based processes cannot be relied on to give the armies of expensive accountants a hand.

All this will be figured out and eventually the necessary rules will be provided to get the quality levels where they need to be and software will be created that is easy enough for accountants to use and powerful in terms of capabilities to perform useful, helpful work.  This is pretty much a done deal for financial reporting.  It might not look like it to the untrained observer, but financial reporting is leading the way towards digital reporting.  But, it really is.

Think about something.  What does this mean for other financial reporting use cases and general business reporting?  You contemplate that.

Additional Information:

Comments

Popular posts from this blog

Getting Started with Auditchain Luca (now called Luca Suite)

Relational Knowledge Graph System (RKGS)

Professional System for Creating Financial Reports Leveraging Knowledge Graphs