Digital Financial Reporting

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!

AccountingToday reports in an article, AICPA CEO Melancon: CPA licensing under threat, that the American Institute of CPAs president and CEO Barry Melancon talked about the need for CPAs to learn new skills as hiring of accounting graduates has slowed and the CPA licensing model has come under threat in some states.

In the article, Melancon points out, “Hiring of accounting graduates over the last four years by public accounting firms is down 31 percent. Total hiring is basically flat and proportionally slightly down. If we don't find a way to put those other skill sets, predominantly technology, into the CPA Evolution, we're going to continue to see that equilibrium change.”

The article mentions two other important details.  First, it says "The AICPA has been working with the National Association of State Boards of Accountancy on an initiative called CPA Evolution to transform the CPA licensure model to teach more technology skills to CPAs."  Two or maybe three years ago, I went to the State Board of Accountancy in Washington state and told them the same thing.  They basically ignored me.

Second, the article talks about the AICPA's Dynamic Audit Solution initiative. Be sure to keep on top of that.  AI assisted audits are really a slam dunk.

So, where do you start?  I strongly suggest that the first step is to get some Computer Empathy to understand how computers work. This will help you understand the real potential impact of artificial intelligence, structured information, digital distributed ledgers, etc.

Analogy is a powerful cognitive mechanism that people use to make inferences and learn new abstractions.  Per the Stanford Encyclopedia of Philosophy, "An analogy is a comparison between two objects, or systems of objects, that highlights respects in which they are thought to be similar."

The video, How Drones Could Change the Shipping Industry, helps you understand the possible impact artificial intelligence, structured information, and distributed ledgers will have on accounting, reporting, auditing, and analysis.

Use your imagination. What analogies do you see?  Let me know.