Digital Financial Reporting

The accounting equation is a tiny logical system, but using that as a tool you can create excellent sophisticated examples that people can get their heads around to understand the fundamentals of how XBRL works.  I summarized information for about 10 different fundamental impediments to creating a properly functioning financial report logical system in a new version of the accounting equation logical system.  This document, Impediments to Creating Properly Functioning XBRL-based Reports (AE), will help you master XBRL-based digital financial reporting.  Or, you can get all the information from this link.

Similarly, the same thing was done using the FASB's SFAC 6 Elements of Financial Statements.  Here is the document Impediments to Creating Properly Functioning XBRL-based Reports (SFAC6).  Here is a link to all the information about SFAC 6.

Those two examples provide the basis for understanding my Special Theory of Machine-based Automated Communication of Semantic Information of Financial Statements.

This article by Narayanan Vaidyanathan, Explainable AI: Putting the User at the Core, published by the Association of Chartered Certified Accountants (ACCA), is spot-on when AI is used in accounting, reporting, auditing, and analysis.  Don't miss the full report which you can get here.

What I have created is 100% explainable.  That is what I mean by "justification and explanation mechanism" (see here).  The user of the software should be able to follow the chain of reasoning used by any software application helping them. SBRM is likewise 100% explainable.

Here is part of the executive summary of this article:

Explainable artificial intelligence (XAI) emphasises the role of the algorithm not just in providing an output, but also in sharing with the user the supporting information on how the system reached a particular conclusion. XAI approaches aim to shine a light on the algorithm’s inner workings and/or to reveal some insight into the factors that influenced its output. Furthermore, the idea is for this information to be available in a user-readable way, rather than being hidden within code.

Historically, the focus of research within AI has been on developing and iteratively improving complex algorithms, with the aim of improving accuracy. Implicitly, therefore, the attention has been on refining the quality of the answer, rather than explaining the answer. But as AI is maturing, the latter is becoming increasingly important for enterprise adoption. This is both for decision making within a business, and post-fact audit of decisions made. Auditable algorithms are essentially ones that are explainable. 

The complexity, speed and volume of AI decision-making obscure what is going on in the background, the so-called ‘black box’ effect, which makes the model difficult to interrogate. Explainability, or any deficit thereof, affects the ability of professional accountants to display scepticism. In a recent survey of members of ACCA and IMA (Institute of Management Accountants), those agreeing with this view, 54%, were more than twice the number who disagreed. It is an area that is relevant to being able to trust the technology, and to being confident that it is being used ethically. XAI can help in this scenario with techniques to improve explainability. It may be helpful to think of it as a design principle as much as a set of tools. This is AI designed to augment the human ability to understand and interrogate the results returned by the model.

If you are unclear about AI, I would recommend this document.

The Data Coalition also talks about explainable AI.

I took information for a small logical system, SFAC 6 Elements of a Financial Statement, put the logic of that information in an Excel spreadsheet, and then generated the XBRL taxonomy schema, XBRL linkbases, XBRL formulas, and XBRL instance.  I then validated everything to make certain that it was correct, both the XBRL syntax and the financial information logic, using three different XBRL processors.  Here is information for this experiment: 

• Download: This ZIP archive has the Excel spreadsheet and the autogenerated XBRL files.
• Human readable: This is human redable information about that XBRL-based information.
• XBRL instance: This is an XBRL instance which you can load into Pesseract or other software application for working with XBRL-based information.
• Validation results: Here are the validation results from UBmatrix XBRL Formula processor, UBmatrix calculations validation, UBmatrix XBRL processor XBRL syntax validation, XBRL Cloud XBRL processor validation, XBRL Cloud Evidence Package validation summary.

I created the processing using Microsoft Access.  I was going to use Excel but did not want to suffer trying to figure out VLOOKUPS and such necessary.  Relational queries are much easier.  I wanted to use Excel so it would be easier to share the code.  I simply attached the Excel spreadsheets to the Access database and processed the information using Access.

There was one task where I "cheated".  Because my programming skills do not allow me to parse the XBRL formulas such as "$ComprehensiveIncome = ($Revenues - $Expenses + $Gains - $Losses)"; I manually put each of the concepts into a relational database table so that I could have the information I needed to autogenerate the XBRL Formulas.  Other than that short cut which adds a little work for the creator of the Excel data; 100% of the information necessary to generate the XBRL yourself exists in that Excel spreadsheet.  There a handful of lookup tables that I created to convert say provide the friendly data type "Monetary" to the Excel user but then generate "xbrli:monetaryItemType" in the XBRL taxonomy schema.

It took me only about 16 hours to write the the code and there is about 1,600 lines of code.  Not that much and probably 30% of that is blank lines, comments, etc.

While it took me 16 hours to program, it took me 10 years to figure out WHAT to program.  There is one additional detail that I want to implement that I will explain later.

What I created takes into consideration the information about how to exchange complex financial information effectively.  The model used in Excel to represent the logic follows the logical conceptualization of a business report prescribed by the forthcoming OMG Standard Business Report Model (SBRM).

"Why is this significant?", you may ask.  Well, it is actually significant for an number of reasons.  First, this ends to discussion about syntax.  I already represented SFAC 6 in XBRL, Prolog, and now Excel syntax.  I then converted the Excel into XBRL proving that I can go from Excel >> XBRL; or XBRL >> Excel.  Next, I am going to modify the application to output PROLOG. Then I will run that using the online SWISH PROLOG Processor.

After that I will add functionality to my application to convert the Excel into OWL/RDF/SHACL and then process that using Protege or some other semantic reasoner.

Second, I will be able to compare the capabilities of XBRL, Prolog, and OWL/RDF/SHACL to process the complex financial information contained in a financial report. Not all knowledge representation tools are equal.

Today, there are two tools that can process 100% of the business rules that I can specify and that are REQUIRED to verify that a financial report logical system is properly functioning.  If you use the formula chaining capabilities of XBRL you can get a little closer with just basic standard XBRL processing (If you don't understand XBRL formula chaining, see here; and have a look at these two examples where I left out the fact for liabilities {before} and then added it using formula chaining {after}.  This video walks you through how XBRL formula chaining works. This ZIP file has the batch file to run, the input file, and all the result files.)

Third, this proves that you can, in fact, create a properly functioning logical system that allows for the kind of variability that exists within a financial report.  With XBRL + SBRM + System Theory; this works today as long as you implement it correctly.  Don't like XBRL?  Fine, use whatever syntax you like. Fads, trends, preferences, and misinformation will come and go. It's all about logic and engineering. It's all about know how and brick-by-brick making it work effectively to solve a problem.

This is an excellent presentation by John Sowa, Knowledge Graphs.  Consider that information when you think about what it takes to exchange complex financial information.

I have explained logical systems in simple terms. Essentially, a logical system is a set of models described by structures that contain terms, associations, assertions (rules); all of which are used to describe facts. All of this is summarized in this video that explains logical systems.

Using that description of a logical system, I created a logical model of a financial report.  That financial report logical model is the basis for the forthcoming OMG Standard Business Report Model (SBRM).

I have described two very basic logical systems using three different syntax and a fourth was described in another syntax by someone else: (SFAC6 in OWL/RDF/SHACL is coming soon)

• Accounting equation (XBRL | Prolog | Excel | OWL/RDF/SHACL)
• FASB SFAC 6: (XBRL | Prolog | Excel | OWL/RDF/SHACL)

I have tried to extrapolate those simple, easy to understand logical systems that are rather easy to wrap your head around to larger financial report representations, proving that the financial report logical systems are properly functioning and therefore showing what is necessary in order to (a) create properly functioning systems and (b) determine if such a logical system is in fact properly functioning.

Now, the XBRL, Prolog and OWL/RDF/SHACL representations can be called "formal" because there are formal specifications for those syntaxes.  The Excel format can at best be called "informal" because there is no formal specification as to how to represent the information within Excel.  Also, the Excel format is a bit of a work in progress; I don't have it exactly where I want it right now.

However, if you take the informal Excel representation, and then effectively convert that to one of the formal syntax, say XBRL, then you can say that the informal Excel representation is effectively representing the logic of the financial information represented within Excel.

Why is this important?  If I can take complex information, represent that information in any of four different technical syntax, and then use the processing capabilities of different existing tools and get the same "answer" as to what the information is logically conveying; then that is pretty darn good proof that all of the pieces of the logical system is working effectively.

The details of what this complex system needs to be able to do and why is described in my document Special Theory of Machine-based Automated Communication of Semantic Information of Financial Statements. (This 15 minute video provides a good overview of that document.)

While I am using this for financial reporting, the applicability here goes beyond financial reporting to general business reporting and the exchange of any complex information really.

Think semantic spreadsheet!