Digital Financial Reporting

If you listened to the video of Ray Dalio being interviewed by Garry Kasparov where they talk about artificial intelligence, AI and Algorithmic Decistion Making, you heard Ray Dalio explaining how important it is to distinguish between “closed systems” as contrast to “open systems”.  I am in complete agreement.

Why is this important?  It is important to understand the difference between the reliability and predictability (i.e. tolerance for error) that you get from open versus closed systems and how much effort it takes to manage that control.  Systems need to be controlled.  Rework is expensive.

I have not found a discussion of "control" that specifically relates to computer systems.  I sometimes use the terms "finite" as contrast to "infinite" to describe what I am getting at.  Other times I used the notions of "open systems" as contrast to "closed systems".

I found three Wikipedia articles that discuss this notion: Closed system (control theory); Classical control theory, and Control theory.  I also found this article, An Introduction to Systems and Control Theory for Computer Scientists and Engineers, which points out:

“software engineers need to use control concepts to master the ever-increasing complexity of computing systems” 

Guaranteed performance is a good thing.  Stability is a good thing.  Being as high as possible on the knowledge representation spectrum is a good thing.

Admittedly, I do not understand how to describe this formally.  However, I do understand that being able to control a system such as an XBRL-based digital financial report is a business requirment.  It is not a "nice to have" feature; it is a required feature.

I try to explain this in this document. I can point out all that is necessary with this logical theory.  I can prove that I am getting this right with these working proof of concepts and this conformance suite. And all this can be supplemented using the techniques and philosophies of Lean Six Sigma.

All of this can be applied to implement continuous accounting, reporting, and auditing effectively.

Not clear on what needs to be controlled?  Watch these three videos: Impediments Part 1; Impediments Part 2; Impediments Part 3.

Also, I added this Process Control video to the Understanding Financial Report Logical System playlist.

A lot of people are talking about "continuous accounting" and "continuous reporting" and even "continuous auditing".  Some provide grand visions and buzz words to try and describe continuous accounting and reporting.  Some people even give you very broad brush strokes that help you understand what it means. Some provide high-level blueprints for implementing continuous accounting.

But think for a moment.  If you actually wanted to achieve continuous accounting, reporting, and auditing; exactly how would you do that? How exactly are you going to automate the tasks and processes involved?

First, what gets in the way of continuous accounting and reporting?  Here are some specific things that I see:

• Inappropriately set up chart of accounts.
• Inappropriate mapping between chart of accounts and financial report line items. (i.e. lead schedules)
• Information (metadata) used to correctly categorize report information missing from the accounting system therefore automation is impossible.
• Information that is unavailable to automated processes. (i.e. policies not in accounting system, qualitative disclosures not in accounting system)
• Errors.
• Complexity. (i.e. multi-currency, multi-gaap, multi-subsidiaries, multi-special ledgers, multiple accounting systems, etc.)

So all those things add up to the hurdles that need to be overcome to actually get continuous accounting and reporting to actually work.

Second, you actually have to physically implement something.  This video walks you through a basic implementation of continuous reporting.  So this fundamentally works.  Here are all the details of two implementations that have 100% of what is necessary for a basic working system where accounting tasks and reporting tasks are automated: Accounting process automation/record to report; Pixel perfect rendering.  (If you want the complete scope, you need all of this which is simply more volume of what is in the first two examples; but the two examples I point to really are complete.)

To make all of this work effectively, you must be able to control the system effectively.  And so, if you can overcome all of those hurdles and control the system effectively such that the system is reliable and predictable then you can use that system to perform useful work. Let machines do the grueling, gruesome, repetitive, mindless tasks.  Maybe not all tasks and processes will be automated, but certainly some will be automated.

All of this is about augmented intelligence.  Another term used is intelligence amplification.  In his book, Principles, Ray Dalio advises,

“By developing a partnership with your computer alter ego in which you teach each other and each do what you do best, you will be much more powerful then if you went about your decision making alone.”

Augmented intelligence is about computers and humans working together rather than machines replacing humans.  Augmented intelligence applications combine human and machine intelligence. This is important in systems there is low tolerance for error or where artificial intelligence is not evolved enough to take humans completely out of the loop.

That is essentially how continuous accounting, reporting, and auditing will be achieved.  Everything else is really simply a detail.

The Proof+Common+Rendering example representation is a new addition to my set of examples which can be used to master XBRL-based financial reporting.  What this example does is show you the essence of an XBRL-based digital financial report and then reconcile that essence to a 10-K.

Key information for this example representation includes: 

• Files: Every file is available for your further analysis.
• Documentation: This walks you through the example and helps you see what I am trying to get across.
• Database: You can download the Microsoft Access database that I used to create the example.  The only thing not included is the code that generates the disclosure mechanics and reporting checklist rules.
• Pixel Perfect Rendering (Inline XBRL): This is an Inline XBRL instance document that was generated from the database above.  This version references a web-based taxonomy that supports the XBRL instance.
• Pixel Perfect Rendering (PDF): This is a PDF generated from the information in the XBRL instance using XSL-FO and a FOP to generate the PDF.

There is a wealth of knowledge in this information.  This builds on the accounting process automation or record to report example.  In essence, if you read through all the examples you can see that you can put transactions into a general journal and if that is done correctly you can generate a pixel perfect XBRL-based financial report and/or a human-readable PDF, HTML, Word, or other such representation.

Essentially, this points out that there is a completely new workflow possibility that can be employed for creating financial reports.  Whether one of the outputs is XBRL or not makes no difference.  In fact, this is bigger than just reporting; it impacts accounting, reporting, auditing, and analysis.

We live in a world where the questions remain the same; but the answers have changed. This TED Talk video, Why the majority is always wrong, explains.  While 97% continue to do more or less of the same things over, and over, and over; 3% try new things.

Consider thinking outside the box.  Why settle for normal when you can be exceptional! The digital transformation is about talent, not technology.  Learn to leverage your tools effectively.

This excerpt from Ray Dalio's book Principles is one of the best discussions about artificial intelligence that I have run across: SYSTEMIZED AND COMPUTERIZED DECISION MAKING.

This YouTube.com video, AI and Algorithmic Decision Making, provides an excellent overview that is very approachable to business professionals.

There is one notion that I disagree with that comes across in this article.  The article gives the impression that you literally "program" rules (i.e. put rules in code).  For a number of reasons, that is not a good idea. If logic and rules is expressed in "code"; then only programmers can add new logic/rules, maintain the logic/rules, and business professionals have to educate the coders on the business logic that they are trying to get programmed.

There is a better way.  If the "computer code" and the "business logic/rules" are separated, then programmers can write code and business professionals can work with and maintain the rules/logic.  Using this approach, the rules/logic are represented in declarative form in some machine-readable format.  A rules engine or logic engine then uses those rules/logic.

So, rather than writing your "principles" code, you write them as declarative rules.  Closed systems are necessary, you cannot just add "stuff" haphazardly.  Open ended systems might not work reliably, there is a chance of error. If the "future can be different than the past", you have to be very careful.  Open versus closed systems seems to be described by control theory.

Plenty of rules engines or logic engines already exist.  The missing piece is the computer readable business rules. Rules for creating a financial report look like this. (Here are many more examples.)

And so, while I would not dispute that understanding how to code is helpful.  But, you really don't need to "learn to code".  If you want to understand the details better, I would invite you to read Artificial Intelligence and Knowledge Engineering Basics in a Nutshell.