Assault on Poor Financial Hygiene in XBRL-based Financial Statements

Many people have been complaining about the quality of XBRL-based digital financial statements submitted to the SEC for many years. XBRL US even formed a Data Quality Committee to address quality issues.

ESEF XBRL-based financial statements submitted to the ESMA are now being scrutinized and seen to also contain quality issues.  See this report which looks at ESEF report quality by audit firm and this ESEF observatory.

Myself and a handful of others (like XBRLogic) have been measuring the quality of XBRL-based financial statements that have been submitted to the SEC for a number of years.  I have personally looked at the high-level fundamental relationships between financial concepts and their relations between 2013 and 2018. What I saw was many mistakes, improvements over time, but my last measurement showed that about 90% of reports were free from these high-level mistakes, but that means that about 10% of reports had some sort of error. Here is a summary of my last measurement: (click here)

Here is how to read that table.  Look at row #2.  That row shows the rule "Assets = Liabilities and Equity", a fundamental rule in accounting referred to as the accounting equation.  Of the 5,716 reports that I measured (all the 10-Ks submitted to the SEC for fiscal year 2018); 5,706 of those reports were consistent with that fundamental accounting rule; but there were 10 that were not consistent and I manually confirmed that each of those 10 reports were, in fact, in error.

Now, the 10 reports that had that mistake in 2018 was an improvement from the 53 reports that had that mistake, again confirmed by me manually, when I made my first measurements in 2013.

Yes, I am saying that there were 10 public companies that reported balance sheets that did not balance within the set of 5,716 10-Ks submitted to the SEC for fiscal year ended 2018.  That table above lays out other similar mistakes, again all confirmed manually to actually be an error made by the reporting public company or whoever created the XBRL-based financial report that was submitted.

Within the DOW 30 companies, measurements in 2022 revealed that there were 4 specific confirmed high-level accounting concept errors. Again, all four errors were confirmed manually by me personally to be errors.  Within the Fortune 100 (which includes the DOW 30), measurements in 2022 revealed 17 specific errors. Likewise, these were manually confirmed by me to actually be reporting mistakes.

So what is my point here?  Well, I have several points:

  1. Understanding these errors and how the errors occur can help reporting entities creating XBRL-based reports better understand those reports and avoid these sorts of errors.
  2. Data aggregators spend about 90% of their software development effort when trying to make use of all that XBRL-based financial information overcoming these sorts of errors in reported information.  I have talked to many of these data aggregators.
  3. XBRL-based reporting can in fact work.  But regulators like the SEC and ESMA need to provide verification walls that check the quality of reports before they accept a submitted report.
  4. The fundamental accounting concepts and the relations between those concepts is not the only thing that needs to be checked.  Poking and prodding of XBRL-based reports has revealed a hand full of things which I refer to as the "pillars of quality" which reports need to have in order to be fundamentally usable.
  5. My "pillars of quality" do not guarantee that everything in the submitted XBRL-based report is correct; they only check, to the extent that machine-readable rules are provided, to make sure specific things are NOT WRONG.  Basically, all my rules are NECESSARY but they are not SUFFICIENT.  You can never really guarantee that everything is right, you can only prove what is wrong to the extent of the machine-readable rules that are provided.
  6. XBRL-based reports submitted to both the SEC and ESMA have very similar issues.  XBRL-based reporting has been occurring  since 2010.  Seems like quality could be dialed in by now.
  7. The same rules necessary for verifying that reports are prepared correctly are the rules necessary to extract information from those XBRL-based reports effectively.  Financial reports are not, and should not, be forms.  Those financial reports are knowledge graphs.  Because the financial reporting rules allow for the use of different subtotals and totals and the use of different line items (i.e. XBRL concepts) to report information; those validation rules are required to extract information from the reports effectively.  For example, many different concepts might be used to report the line item "revenues".  That list of possible concepts is necessary to effectively extract information from those reports.
The ESMA already says that the human-readable report information and the machine-readable report information need to be of similar quality. Specifically, the ESMA says, "...users should be granted the same level of protection irrespective of how they access the information contained in the financial statements..."  The SEC will eventually enforce quality when it comes to the machine-readable report information. The SEC has already put a few shots across the bow of public companies.

Waiting for the ESMA and SEC to catch up in terms of measuring the quality your processes can output is to miss the point of what is really going on.  Modern accountancy has its advantages.  Being proactive now can prevent crisis mode later when the ESMA and SEC start to clamp down on quality, which they will eventually do.

Anyone with Excel and knows a little about VBA can extract information from XBRL-based reports.  Here are a bunch of Excel based applications that I created. More and more information about errors in XBRL-based reports will become available.


Additional Information:

Comments

Post a Comment

Popular posts from this blog

Getting Started with Auditchain Luca (now called Luca Suite)

Image
(Note that a newer, production version as opposed to only the development version , of Luca Suite is available) The Innovator's Dilemma points out that disruptive innovations often look like toys that are doing everything wrong. Auditchain Luca , which is part of the Auditchain Suite , is a unique approach to creating a knowledge graph .  To experience using Auditchain Luca, have a look at the Getting Started with Auditchain Luca instructions. Be sure to grab the Excel and JSON import files used for this getting started exercise.   This getting started exercise uses one of several different approaches to getting information into a tool for constructing and viewing professional quality knowledge graphs .  Additional getting started guides will be made available over time. Auditchain Luca might not make sense to you if you don't understand the paradigm shift that is occurring and if you have not shifted your mental map. For the next step in your journey, consider t...
Read more

Relational Knowledge Graph System (RKGS)

Image
Relational Knowledge Graph System (RKGS) is an interesting idea that combines the relational paradigm and the knowledge graph paradigm.  This documentation, Why RKGS , explains the idea. This gets even more interesting with the notion of "relational AI".  RelationalAI is described as follows by the company of the same name, Relational.ai : “RelationalAI is a cloud-based relational knowledge graph management system, with state of the art probabilistic processing and declarative reasoning at scale to make developing Data Applications a superpower for your business.” This notion of knowledge graphs represented in relational databases fits into my belief that knowledge graphs have two aspects: the expression SYNTAX and the logic of what is expressed or SEMANTICS. While the LOGIC of a knowledge graph is always the same regardless of technical syntax used to express that logic; there are many, many different technical syntaxes that can be used to represent a knowledge graph. There...
Read more

Professional System for Creating Financial Reports Leveraging Knowledge Graphs

Image
The document Professional System for Creating Financial Reports Leveraging Knowledge Graphs explains a new approach, a new paradigm, for creating financial reports.  The document provides a practical, nontechnical description of a professional system for creating provably high-quality financial reports where the report creator is using financial reporting schemes (such as US GAAP and IFRS) where report creator is permitted to modify the report model which leverages global standard knowledge graphs represented using XBRL. This new approach is useful, it is highly novel, and the details were highly complicated to pull together.  This is certainly not an incremental innovation.  It is definitely a disruptive innovation and it could very well be a foundational innovation. You can decide which for yourself. Foundational technologies have two dimensions that need to be considered: novelty and complexity. The more novel the technology is, the more effort needed to ensure users ...
Read more