Digital Financial Reporting

XBRLogic.com published their quality measurements for XBRL-based financial reports submitted to the SEC for the second quarter of 2020: (click image for larger view)

XBRL Cloud's Edgar Dashboard does not summarize this information, but you can get the details.  Seems like there are many who can benefit from my method of creating high quality XBRL-based financial reports.

The "bolt on" approach to implementing XBRL-based reporting was doomed from the beginning becuase it made absolutely nothing better, faster, or cheaper.  All it did was add more work to existing processes.

Computational professional services is a new approach, in fact it is a completely new paradigm. Some call it "smart regulation", others "algorithmic regulation", others "rules as code", and still others "robo cop".  To make this work, accountants don't need to "learn to code".  Software engineers need to learn to build the right software; software business professionals can realistically use, be effective, maintain their high quality standard.

Here are four different user interface ideas for enabling business professionals to actually use computational professional services.  You have to use your imagination here.  Each of these interfaces is too low a level.  The actual interface I am contemplating is driven by a higher-level metamodel and pre-created metadata.  These simply shows the fundamentals of interacting with "building blocks".  The trick is to have the correct level of building block to interact with and the correct visual image. 

• Scratch: This is a browser based version of the MIT project that started it all.  Here is a tutorial.
• Blockly: This is a browser based version of Blockly which was inspired by Scratch. In my view, this is two levels of abstraction away from what business professionals would use.  Maybe three. The Block Factory lets you construct blocks. Here is information relating to block creation.
• Blawx: This is a browser based version of something based on Blockly which is connected to a logic engine.  This actually works.
• Make Code: This is a browser based version of Make Code which is very similar to Scratch.  Again, this is too low a level, business users would work with higher level models.  Two and maybe three additional levels of abstraction are necessary to get to where you would want to be. (Make  code playground)
• Waterbear: Another alternative, does not seem that great.

So, something inspired by the UI that you see above would be linked to some logic/rules engine.  Here are candidates for such a logic/rules engine: (for details see here and here) 

• OWL/SHACL/RDF (i.e. knowledge graph) using something like TopBraid
• SWI Prolog or Scryer Prolog
• Cypher/Neo4j (i.e. labeled property graph)
• Ergo AI (proprietary logic system)
• Build your own rules engine on top of XBRL Formula (i.e. XBRL Cloud did this)
• Create your own rules engine (i.e. Pesseract)
• Decision model approach (business rules management system)

The actual interface would look more like this; this is what the UI pieces might look like: 

• Pesseract: This is a working proof of concept which has a dynamic interface. (more information)
• XBRL Cloud: This is a static interface but it helps you see what the objects business users would work with.  (here are more examples)

The Logical Theory Describing Financial Report (i.e. SBRM eventually) provides the high-level metamodel for financial reports.  It is those objects that a business user would interact with in the user interface.  That would be driven by metadata that fits into that metamodel, this can be exemplified by the US GAAP Financial Reporting metadata.

All these different layers are tied together.  Technical complexity is buried deep within software, business users interact with high-level logical things that they understand.  Here is a bunch of information which summarizes testing that I have done.

And that is how computational professional services can be implemented. This is a straight forward engineering design process.  If you need more details, look here.  There are no short cuts. Use your imagination, but you have to make this realistically usable by business professionals with a complete set of capabilities that allow business professionals to succeed.

Engineers that design things follow a formal process called the engineering design process.  The engineering design process is a tool engineers use to create products and make sure the products work as expected.  This short video explains the engineering design process.  This is a graphic that explains the engineering design process: (click here for larger view)

If you don't follow the engineering design process, this is typically what happens: communications problems and things do not work as expected:

Stakeholders need to agree on the goals and objectives that some system is supposed to produce. Once you agree on the requirements, you build a working prototype to make sure you can get the system to work and you can go back to check with the stakeholders to be certain the system is working as the stakeholders expect.  As I pointed out, you have to comply with the Law of Conservation of Complexity and the Law of Irreducible Complexity.

This is how computational professional services will get created and built out. There are no short cuts.  Engineering 101.

I mentioned Blawx in a prior blog post. While Blawx was designed to work with legal information, it also works with accounting information.  Here is the Accounting Equation and SFAC 6 Elements of Financial Statements representations using Blawx:

Accounting Equation: (properly functioning)

Accounting Equation: (intensional error)

SFAC 6 Elements of Financial Statements: (note that I could not represent two of the mathematical rules)

For some bonus points, here is a prototype of SBRM represented using Blawx (work in progress):

Lots of potential here!  Thank you to Jason Morris for helping me get the accounting equation and SFAC 6 examples created.

Jason Morris who created Legal Blawx said, "The onus is not on the lawyers to become programmers.  The onus is on the programmers to provide tools that lawyers can realistically use."

I am in 100% agreement with Mr. Morris.  Also the same thing applies to accountants and auditors and others that participate in computational professional services.  Accountants and auditors don't need to become programmers.  There are a few accountants and auditors that need to learn how to communicate effectively with computer science professionals who build software.  Once the right software exists, the average professional accountant and auditor really don't need to understand how the software actually works.  They will simply use the software.

The "bolt on" software that most software vendors created was doomed from the very beginning.  It saved no time at all, in fact it added MORE WORK to the task of creating XBRL-based financial reports. That is why on one is using XBRL-based digital financial reporting other than those mandated to do so.

For computational professional services to work, the process of creating financial reports must change to leverage what technology offers to make tasks and processes better, faster, and/or cheaper.

Here is one way this will likely work.  Think "layers".  You have a user interface layer, a logic and semantics layer, and you have a technical syntax layer.  Consider the following graphic which shows this visually (click image for a larger view):

Here is an explanation of the three layers: 

• User Interface Layer: The user interface layer (see here) is where the user of the application interacts with the application.  The user, a nontechnical business professional, works with "logical business related things" that are exposed by the software that the business professional is very familiar with.
• Logic and Semantics Layer: The logic and semantics layer has THREE parts.  
  • Engine: The first part is a "logic engine" or "rules engine" (like this or like one of these).  
  • Metadata: The second part is the actual "domain business logic" expressed as machine-readable information (like this for US GAAP). 
  • Metamodel: The third part is a metamodel, in the case of financial reporting it is the metamodel of a financial report (like this).
• Syntax Layer: The technical syntax layer takes care of the physical manifestation of something like a financial report in a standard format that can be exchanged.  That format could be XBRL, Prolog, RDF/OWL/SHACL or some other knowledge graph, Cypher or some other labeled property graph, CSV, SQL, Excel (see here). 

Those three layers interact with one another. There is no need for business professionals to interact with the syntax layer.  There is no need for business professionals to create complicated metamodels or metadata.  Specialists will do that.  This is not a new idea, this is simply "model-view-controller".

Per the Law of Conservation of Complexity, you cannot remove complexity from a system; but you can move the complexity.  Per the notion of Irreducible Complexity you cannot simple leave pieces out and expect the system to function as needed.

The vast majority of software applications for creating XBRL-based financial reports available today are complex, hard to use kludges.  Over time, this will change.

No one has put all the pieces together correctly yet.  But, working prototypes and proof of concepts such as Blawx, Pesseract, SWI Prolog-based applications, commercial tools such as XBRL Cloud's Edgar Dashboard and Evidence Package, and other software help provide glimpses of how all this will eventually work.