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:

• Model-based Financial Reporting
• Modern Accountancy
• OMG's Ontology Definition Metamodel (see chapters 10 and 11)
•