Digital Financial Reporting

Knowledge graphs, DAGs (a.k.a. directed acyclic graphs), Merkle Trees, and Merkle Proofs will transform (are transforming) accounting, reporting, auditing, and analysis profoundly and forever.

As I have pointed out previously, an XBRL-based financial report is a knowledge graph.  Not only are such reports knowledge graphs, they are special types of knowledge graphs that don't have "loops" or cycles. Those special types of knowledge graphs are called directed acyclic graphs.

A Merkle DAG is a type of Merkle Tree. You can create a Merkle DAG from the information contained within an XBRL-based digital financial report.  When thinking about this, most software engineers think about a hash of the XBRL technical syntax that makes up the report.  But you can also think of this while considering the logic of the digital financial report.  That logic is represented by all of the rules related to the report that has been represented using the XBRL technical syntax.

A Merkle proof is an approach to verifying that information stored, transferred, handled, processed, or otherwise used by a computer has not been changed or otherwise tampered with.  You can also verify that the rules used to verify the logic of the report have not been changed.

So, for example, an auditor can verify that an XBRL-based financial report is considered complete, consistent, and properly functioning and the set of rules used to make that determination can be both defined and specified; included in the Merkle DAG and proven using the Merkle proof.

My method specifies a minimum set of information that must be used to verify an XBRL-based financial report.  Effectively, that method defines a level 5 financial report.

If you use Merkle trees and Merkle proofs to verify the report and put those hashes on a publically available digital distributed ledger then you can make known specifically what was reported, understand what information was used to verify that reported information, and be sure that the information has not been tampered with. This, I guess, is how you would create a level 6 digital financial report.

If you use a Merkle tree and Merkle proof at the transaction level you could not only verify the report but also verify the set of transactions which were used to generate that report.  This, I guess, is how you would create a level 7 digital financial report.

Wow!  This is all based on mathematics.  Heres is a prototype XBRL-based financial report plus 94% of the rules that I have come up with to make that report consistent with my method. Here is another prototype that includes the transactions and, I believe, has 100% of the core rules necessary.

Accountants, I am telling you; you might want to read the Essence of Accounting.

###################

What is a Merkle Tree?

Amazon QLDB

The IPFS whitepaper describes IPFS or the InterPlanitary File System thus:

The IterPlanetary File System (IPFS) is a peer-to-peer distributed file system that seeks to connect all computing devices with the same system of files.

Today, the internet uses location based addressing.  IPFS uses content based addressing. What IPFS is and how it works is explained in very simple terms in this video. This article, What is IPFS? - A Beginner's Guide, digs into the details a bit more.

Filecoin is a decentralized network for storing content that uses IPFS and blockchain technology. This video helps you understand Filecoin.

Key to understanding how IPFS works is having an understanding of Merkle DAGs.  How all this works together is explained in this article, What's really happening when you add a file to IPFS? 

So what does all this mean?

It means that things like IPFS, Filecoin, Merkle DAGs and such can be used to flexibly store information that will always be available and you can trust that the information has not been tampered with. A complete audit trail is provided in an immutable digital distributed ledger.  All of these things provide the physical "stuff" that is necessary to effectively employ the logical "stuff" like knowledge graphs that are used to represent XBRL-based digital financial reports.

#############################

Splitting a Directed Acyclic Graph into Components

Quick Tip = What's a DAG?

What is a Merkle Tree?

Installing IPFS Command Line (This video walks you through installation)

I put together a bit of information about logical derivation to help accountants get their heads around this notion from some tests that I created.  Logical derivation is basically about deriving new information from existing information using the rules of formal logic. 

Three examples will help you understand the essentials.  (All three examples are provided in this PDF).  All of these examples were processed using Auditchain's Pacioli logic/rules/reasoning engine.

One step derivation

To start off, consider a very basic example.  In financial reports, it is common for the subtotal line item "Noncurrent Assets" to not be reported. But for analyzing or normalizing financial information, you might want to understand the value of that line item.  This is not a problem.  If you have information for the value "Assets" and for the value "Current Assets"; plus if you understand the rule that "Assets = Current Assets + Noncurrent Assets" then you can derive the value for Noncurrent Assets. (Here are the Pacioli results of this derivation)

Two step derivation

Taking this very basic example one step further; suppose neither the line items "Noncurrent Liabilities" nor "Liabilities" was explicitly reported in a financial report.  You could derive both unreported values using two rules.  The first rule is "Liabilities and Equity = Liabilities + Equity".  The second rule is "Liabilities = Current Liabilities + Noncurrent Liabilities".  If the facts Liabilities and Equity, Equity, and Current Liabilities are explicitly reported; then the values for the facts Liabilities and Noncurrent Liabilities can be logically derived. (Here are the Pacioli results for this derivation)

What is going on here might seem simple, but the next example shows that this is not two simple logical derivations, what is going on is far more powerful than a sequence of rules.

Multi step derivation (forward chaining)

This more sophistocated example introduces the idea of forward chaining.  For most software to process these rules; the rules need to be provided in a specific sequence and tend to be implemented using basic IF...THEN... statements.  A logic/rules/reasoning engine works different.  In this example I provide the line items of an income statement but I don't provide any of the income statement subtotals.  I do provide the grand total Net Income (Loss) so that I can make the income statement foot.  In this example, all of the subtotals are dynamically derived logically from the reported information. (Here are the Pacioli results for this derivation)

Summary

In this final example I put the first three examples together into on report and perform all if the derivations.  (Here are the Pacioli results for this derivation)

In the report without any derivations there are 44 nodes (facts that you have to work with) and 22 edges (relations between the facts). You can see this on page 5 of the PDF here. But when you add the derivations the nodes are increased to 64 and the edges increased to 53 which basically indicates the additional information you have to work with.  You can see this on page 6 of the PDF here.

Logical derivation is only one capability of a logic/rules/reasoning engine.  There are many, many more capabilities.

This might seem like a toy from the simple examples.  The examples are simple, they are not simplistic.  To see a more robust example, have a look at the Knowledge Graph of Microsoft 10-K example.  Here are the Pacioli results for that.

Stay tuned and I will explain more of these capabilities.

In his book Data and Reality (Third Edition) its author William Kent makes the following observation at the beginning of chapter 9 Philosophy:

"There is an important difference between truth and utility.  We want things to be useful - at least in this business; otherwise we'd be philosophers and artists."

Kent point out that representing things so that automated computer processes can deal with them effectively and perform useful work is a duality. On the one hand, reality can be complicated and in an absolute sense there really is no one singular objective reality that everyone agrees with.  But on the other hand, if we can share a common enough view of reality for most of our working purposes then reality does appear to be objective and stable.

On the one hand, trying to describe every detail of reality so that a computer process can understand something is a fools errand that can never be successful.  On the other hand, dumbing reality down too much and you might be able to create something but it will not be useful.  The key is striking the right balance between what is important and what is a negligible difference that can be ignored.

If the members of a society can effectively agree to share some common purpose and create some objective and stable enough view of reality then effective tools can be constructed.

Paraphrasing Kent, useful tools have well-defined parts and predictable behavior.  These tools lend themselves to effectively solving problems we consider important.  The justification for a tool is economic: the cost of the production and ongoing maintenance of the tool as contrast to the value of the problem solving functionality provided by the tool.

The larger the group trying to agree, the harder it is for that group to reach agreement.  A logical data model is much more durable than a physical data model because the logical model represents information, not how information is compromised by a technology.

Within the institution of accounting, a small group within the larger society, we have already agreed on many things: the general purpose financial report, the double entry accounting model, generally accepted accounting standards (US GAAP, IFRS, IPSAS, GAS, UK GAAP, etc.), the XBRL technical syntax, and even the Logical Theory Describing Financial Report if you look closely at XBRL-based financial reports submitted to the U.S. Securities and Exchange Commission and reverse engineer the logical theory).

It will be interesting to watch the impact on financial accounting, reporting, auditing, and analysis.  All that is left is for accountants to understand the new rules. The new information economy has different rules than the previous industrial economy but most people have not figured that out yet.

Software engineers that want to understand how to build useful software for accountants related to XBRL-based financial reporting; here is a reading list that I would suggest: 

• The Knowledge Graph Cookbook: Recipes that Work: Helps you understand what a knowledge graph is and that an XBRL-based financial report is a knowledge graph.
• Systematic Introduction to Expert Systems: Knowledge Representations and Problem Solving Methods: Helps you understand what an expert system is and now to build one.  In particular, read Part 1 Introduction.
• Semantic Web for the Working Ontologist: Helps you understand how to implement knowledge graphs using RDF, OWL, and SHACL.
• The XBRL Book: Simple, Precise, Technical: Helps you understand the XBRL technical syntax.
• Essence of Accounting: Helps you understand accounting, reporting, auditing, and analysis basics.
• Mastering XBRL-based Digital Financial Reports: Helps you understand the details, find test cases, and anything else you might want to understand about XBRL-based financial reporting.
• Effective Automation of the Record to Report Process (Iternation #4): Helps you understand the details related to implementing modern accounting proceses.
• Special Theory of Machine-based Automated Semantic Communication of Financial Information: Spells out as best as I can how machine-based automated communication of the meaning of financial reports.
• Computational Professional Services: Explains the notion of computational professional services.