Moving from "Document-oriented" to "Model-oriented" Mentality for Financial Reporting

In a prior blog post I introduced what I referred to as the world's first standards based expert system for creating financial reports.  As far as I know that description is precise, but it is not accurate as it really should be.

What I really helped to create was a model-based financial report creation software application that was, in fact, a rules-based expert system.  That software application is called Auditchain Luca. You can try Luca (as of this writing) yourself.  This rather old video playlist shows you some of the capabilities of Auditchain Luca. Many newer features were added since those videos were created.

Auditchain Luca is based on research, reverse engineering of thousands of XBRL-based reports submitted to the SEC and ESMA, other work done with XBRL Cloud in the very early days of XBRL-based reporting to the SEC,  the working proof of concept Pesseract, constructing early version of both the US GAAP and IFRS XBRL taxonomies, building software while at UBmatrix, and a plethora of XBRL projects that I have worked on over a 20 year time span.

To make that model-based financial report creation software work; I also had to create a logical model of a financial report which the software used.  XBRL has such a logical model, although that model is not documented very well and the model is limited to the logic of a business report which does not include the logic of a financial report.  And so I used the global standard XBRL logical model, filled in gaps in that model, and enhanced that business report logical model for financial reporting. (For more information, see Financial Report Pieces.)

We also created a control mechanism to keep users of the software within the boundaries of what is permitted by that logical model of a financial report. Prior to creating Auditchain Luca; Auditchain created Pacioli. Pacioli, which was built on top of SWI-Prolog, can provide 100% of the control I needed per my Seattle Method guidance and framework to creating high-quality financial reports.

This screenshot below shows a glimpse of what is being understood and controlled: (the numbers are for the Super PROOF)


The typical reaction that you get when someone looks at XBRL is, "It's complicated!"  But what they really mean is that XBRL is not obvious at first glance and then they stop looking at XBRL because it takes effort.

To understand what XBRL is, and has to be, one needs to understand financial reporting.  Financial reporting under the US GAAP and IFRS financial reporting schemes is complicated.  As such, the global standard XBRL technical syntax, which was driven by US GAAP and IFRS financial reporting, has to meet those needs, some of which can be complicated, had to have some complexity and sophistication.

In the early days of creating XBRL, those engineering and architecting what became the XBRL global standard knew about RDF. At the time RDF was not yet a W3C recommendation, it certainly was not tested, and so using RDF was not considered an option.  Those engineers and architects did know what they were doing.  Early on, W3C's XLink was known to them. OWL did not exist until 2003. SHACL did not exist until much, much later. Relative to RDF, OWL, SHACL, and the rest of the W3C semantic web stack, it seems odd to call XBRL "complicated".

Financial reporting at the level of US GAAP and IFRS is complicated.  But, XBRL is up to that task and used by the U.S. Securities and Exchange Commission (SEC) and the European Single Market Authority (ESMA).  Is XBRL-based reporting completely dialed in by those regulators?  No, it is not.  Will it ever be? Who knows.

What the SEC and  ESMA have done is primed the pump for model-based financial reporting.

For the past 7,000 years accountants have had a "document-oriented" mentality when it came to creating financial reports.  Why?  Because it was the only alternative available.

Now, today, another alternative mentality is possible, "model-oriented" financial report creation.

By document-oriented I mean a human typing presentation oriented information into Microsoft Word or copy/pasting information; basically creating a document by hand.  To use this information, a machine needs to "parse" the information and a machine cannot help you construct the document.

By model-oriented I mean a human creating a report model and then generating the facts reported using an API or something.  You can still generate a human-readable document.  Also, a machine can actually assist you in the creation of the report in many ways. Think semantic spreadsheet, logical spreadsheet, pivot table, logical digital twin of financial report.

The document-oriented mentality has its pros and cons.  So too does the model-oriented mentality.  People talk about algorithmic regulation.  Think about something.  Would algorithmic regulation work better using a document-oriented mentality or a model-oriented mentality?

Sure, model-based financial reporting is not well understood and not practiced by many accountants, auditors, or analysts.  But that will change over time I predict.  XBRL in its current form may, or may not, survive as a standard technical syntax.  People may prefer RDF or GQL or some other syntax.  But financial reporting will be practiced for years and years to come.

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