Digital Financial Reporting

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.

LKIF Core Legal Ontology (Legal Knowledge Interchange Format) is a library of ontologies relevant to the legal domain. This paper discusses the ontology.

As explained by Jason Morris, The main idea behind Rules as Code is that government legislation, statutory rules, regulation, and policy can and should be co-drafted in two languages at the same time: (1) in natural human language as it is now; and (2) in a machine-readable and machine-executable language. Both versions of rules would be published side-by-side.

When I say "rules" I include financial accounting rules, financial reporting rules, financial audit rules and such.

Why do this?  There are a number of reasons. 

• This approach helps to detect and remove ambiguity in rules, making the rules better. By going through the effort of encoding the rule, issues become very apparent. This co-drafting forces rule creators to be precise.
• This approach allows for loopholes to be discovered when writing the rules, rather than after the rule has been officially published.
• This approach allows for machines to be leveraged to test rules and to test for unexpected results when creating rules.
• This provides a single, authoritative interpretation of what the rule means.
• This simplifies the automation of government services.
• This would make something like computational professional services work nicely.

So, before you jump to any rash conclusions let me clarify some things.  First, what if the natural human readable language and the machine readable language could be the SAME language? Say something like Logical English. Other alternatives would be some visual modeling language or a specially designed language based on the domain.  Second, personally I don't like the term "code".  What I think they mean is to use a declarative logical programming language as contrast to an imperative language. Third, this is not about professionals "learning to code".

For more information about Rules as Code, see: 

• Better Rules for Government Discovery Report
• Ted Talk
• Blawx: Rules as Code Demonstration
• Rules as Code Showcase
• Stanford University, FutureLaw 2019, Government as a Platform
• Rules as Code Can, and Should be Done Without Programmers
• Playing Along with Rules as Code
• Computational Law: The Cop in the Back Seat
• More information