Digital Financial Reporting

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.