Digital Financial Reporting

The Microsoft 2017 10-K XBRL-based financial report is one of the XBRL-based financial statements that I have analyzed very, very heavily.  Why?  Because it is good and because it is big.  This blog post provides additional details about that financial report which accountants might very well find interesting.  What I have done is apply my method to the Microsoft XBRL-based financial report retrospectively.

These details are becoming quite easy to show and communicate using the Pacioli Power User Tool. Using that tool and running this script: (chick here)

You get the following report analysis package. (note that this link is permanent and that the verification report was run on February 23, 2022.)  Here is documentation for working with this using Pacioli and Pesseract.

To generate that analysis package, I supplemented the Microsoft base report model (i.e. XBRL taxonomy) and report (i.e. XBRL instance) with some additional information. That additional information includes: 

• Additional mathematical relations: Microsoft is not required to and is, in fact, not allowed to submit mathematical relations information beyond what can be articulated using XBRL calculation relations.  I supplemented that information with 45 value assertions using XBRL formula to test mathematical relations which beyond the capabilities of XBRL calculation relations which only verifies roll up relations.
• Fundamental accounting concept relations continuity cross checks: Neither the SEC, the FASB, nor Microsoft provides rules that verify that the XBRL-based financial report is consistent with fundamental accounting relationships such as "Assets = Liabilities + Equity". See here, lines 10 through 30 for that information.
• Derivation of unreported high-level accounting facts: Did you know that Microsoft does not explicitly report the line item "noncurrent assets" or "noncurrent liabilities"?  The fact of the matter is that there are 19 high-level financial reporting concepts that Microsoft does not explicitly report.  Now, Microsoft is not required to report that specific information, but analyzing their financial report is hard without understanding that fundamental information.  My analysis derives those 19 unreported high-level financial reporting line items.
• Report model structure checks: Did you know that neither XBRL International, the FASB, the SEC do not specify the proper relations between the types of report elements that make up the model of an XBRL-based financial report?  Well, I did and then I verified that the Microsoft finacial report follows only what is permitted.
• Type-subtype relations checks (a.k.a. Parts and Wholes): Did you know that while the SEC does specify that a reporting entity should "use the narrowest concept" per some set of wider-narrower associations; but they do not specify those fundamental wider-narrower relations in machine readable for or, for that matter, in any form really.  So I documented some of those relations to test out how Microsoft is doing and then verified Microsoft's report against those relations. (This is another graphical version of that same information, but this needs some work.)
• Disclosure mechanics checks: Did you know that neither the FASB nor the SEC actually specifies what each disclosure is permitted to look like? Not every detail of every disclosure, I am just talking about the essence of the disclosure. Sure, different economic entities will have different line items, subtotals, and other such information.  But the essence of the disclosure is the same for each specific disclosure. I specified these rules for 121 (about 94.5%) of all the Microsoft financial disclosures and then verified that Microsoft is following what is permitted.
• Reporting checklist: Did you know that neither the FASB nor the SEC specifies, in machine readable form, a checklist that indicates which disclosures are required and when they are required?  Well I did that for 128 possible disclosures which covers about 94% of the 121 different disclosures provided by Microsoft.  And then I verified that the Microsoft report was consistent with what is permitted.
• Blocks of Information: Did you know that "networks" (defined by XBRL) are arbitrary groupings of information?  Did you know that "hypercubes" (defined by XBRL) are likewise arbitrary groupings of information.  A reporting entity can organize information many different ways within networks and/or many different ways using hypercubes within a network.  But did you know that I was able to identify 192 units of information within the Microsoft XBRL-based financial report? Those "blocks" are not arbitrary and not dependent on networks or hypercubes.  This same "block" mechanism works for all XBRL-based financial reports submitted to the SEC.  A block is simply a set of information that has a basket of specific characteristics.
• Blocks Graph: Did you know that information in a financial report tends to be related to other information in a report in many cases? Of course you did.  But, can you visualize that information and use that visualization to navigate between those report fragments?  Well, because we are using a high-level report model we can create that visualization.  (Granted, this is a bit rough right now, but you might get the idea.)

All of this additional stuff I have added to the Microsoft 10-K articulates information about the report (describes the report) and also can be used to verify that the report itself is consistent with that description of what is permitted.

If you are not familiar with knowledge graphs, I would highly recommend The Knowledge Graph Cookbook: Recipes that Work.  The resource Financial Report Knowledge Graphs will help you understand this information specifically for financial reports.

Finally, think about something.  How would you KNOW with certainty that the set of rules you are providing to verify a financial report is COMPLETE?  Think about that.  If you are creating a "true and fair" representation of a financial report in machine readable for, this is important to get right.  If you want to understand how to do that, have a good look at the Seattle Method.

XBRL Switzerland and DCARPE Alliance Association agree to collaborate on the adoption of decentralized financial reporting and assurance using XBRL.

Poolparty provides this semantic search example application. The application is explained in this PDF.

Auditchain describes itself as:

Auditchain is a decentralized accounting, reporting, audit and analysis virtual machine that automates and provides proof of assurance on the world’s financial and business information.

They provide a video Introduction to the Auditchain Prototol if you want to learn more.

For more information about auditchain, see this documentation.

To learn more about Pacioli, start here with this Pacioli Power User Tool.

Here is how Wikipedia describes an oracle:

An oracle is a person or agency considered to provide wise and insightful counsel or prophetic predictions, most notably including precognition of the future, inspired by deities.

and

Oracles were thought to be portals through which the gods spoke directly to people.

Down a little further in that article it discusses the notion of a oracle machine. An oracle machine is described thus:

An oracle machine can be conceived as a Turing machine connected to an oracle. The oracle, in this context, is an entity capable of solving some problem, which for example may be a decision problem or a function problem. The problem does not have to be computable; the oracle is not assumed to be a Turing machine or computer program. The oracle is simply a "black box" that is able to produce a solution for any instance of a given computational problem.

Imagine an accounting oracle. In this context, I see an oracle as a reliable machine-readable, and human-readable preferably, source of information.  No magic involved.  You have a knowledge graph of machine-readable accounting knowledge, a software application that can process the logic represented within that knowledge graph, and an interface for asking questions and receiving answers.

We have accounting oracles today.  Examples include the Bragg GAAP Guidebook and other such interpretations of US GAAP, similar guidebooks for IFRS, Deloitte's IFRS Plus resource, the AICPA's Best Practices in Presentation and Disclosure, and the plethora of other such resources.

But what do all these current accounting oracles have in common?  They tend to be readable by humans (i.e. not machine-readable), tend to exist in silos and not interconnected in any way (i.e. not standard), and tend to be managed by one specific entity (i.e. not open source).

Think standard, think data fabric rather than data silo, think artificial intelligence, think knowledge graphs done right. Think semantic wiki.

And so what if there were an accounting oracle that was machine-readable and also human-readable, it was based on standards, and it was open source to a certain degree.

Personally, I think it is only a matter of time before you see something like this.

What do you think?

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

Semantic Media Wiki

Chainlink; Chainlink Solutions