Digital Financial Reporting

I constructed the process for verifying the consistency of the fundamental accounting concepts incorrectly.  While the process does work just fine, it is harder to maintain and debug than it needs to be.

The basic mistake that I made is that I used a forward chaining approach to creating the system when I should have used a backward chaining approach.  This article by Dustin Huntington, Back to Basics – Backward Chaining: Expert System Fundamentals, explains the difference between backward chaining and forward chaining well.

A backward chaining inference engine makes system development and maintenance much easier. Traditional code, which generally uses forward chaining, becomes very complicated as complexity increases making maintenance of the system and even developing the system harder and therefore more costly.

Further, using an off-the-shelf backward chaining engine is better than creating your own engine.  Why?  Two reasons.  First, working off-the-shelf backward chaining engines are proven.  They have already been debugged.  Second, the cost of off-the-shelf solutions can often be less than creating your own backward-chaining engine.  Pretty much a "make or buy" decision.

And so, if you are implementing the fundamental accounting concepts; don't make the mistake I made.  Use backward chaining.  This becomes even more important when you implement additional digital financial reporting consistency or verification checks or an expert system for creating digital financial report creation software.

Also, consider using some sort of off-the-shelf backward chaining inference engine such as PROLOG, DATALOG, an OWL 2 DL reasoner, or even a proprietary reasoner such as FLUENT.

XBRL International provides An Introduction to XBRL. That is a pretty good explanation of what XBRL is.  XBRL International provides this concise statement as to what XBRL is:

In a nutshell, XBRL provides a language in which reporting terms can be authoritatively defined.

Later in the web page in the section What are some of the most important features of XBRL?; these four important features are highlighted:

• Clear definitions
• Testable business rules
• Multi-lingual support
• Strong software support

The most important thing that I see here is people are finally making the connection between "clear definitions" and "testable business rules".  As I have pointed out, business rules are key to achieving a meaningful exchange of information.

I get the big picture fairly well.  Because information which has been unstructured in the past is now structured, machines can help humans automate some processes.  Digital financial reports leverage structured information.  The structured information means that expert systems can help professional accountants construct a financial report better, faster, and cheaper. Machine-readable information will increase over time, machines will be able to do more, and more, and more.  If you doubt this, you may want to check out this machine learning summer school video library.

Looking at the specifics of how machines can help out (are helping out) makes all this a little more tangible for professional accountants.  I synthesized and organized the things I believe must be checked and am checking from the minimum criteria and fundamental accounting concepts into one list.

The list breaks down the quality checks into both automatable and manual processes. There is ZERO probability that 100% of the quality checks can be automated.  Professional accountants will always be involved in the process of creating financial reports.  Likewise, there is ZERO probability that machines will not be able to help professional accountants perform financial report creation tasks.

For lack of a better term, I call the list a digital disclosure checklist.  This is a summary of the items on that checklist (includes both automatable and processes which will remain manual):

1. XBRL syntax
2. EFM
3. Model structure
4. Root economic entity discovery
5. Key dates
6. FAC relations
7. Statement roll ups
8. Statement discovery
9. Statement computations
10. Level 1 notes
11. Industry specific
12. Level 2 policies
13. Level 3 text block disclosures
14. Level 4 detailed disclosures
15. Required disclosures
16. Consistency with prior period
17. Consistency of disclosures
18. Concept selection appropriateness
19. Reported facts full/false inclusion
20. Consistency of facts with peers
21. Concept selection consistency with peers
22. Disclosure full/false inclusion
23. True and fair representation

Here is a detailed version of that list with three years of data on applying my tests to XBRL-based public company financial flings to the SEC.  I have three years of information for about 9 different categories of automated consistency checks that I am performing.  The information quality is increasingly reliable as more and more of these checks are performed via commercially available processes rather than my home-grown consistency check and verification processes:

(Click image for larger view)

I cannot perform all of the processes on that list because I have limited programming skills.  Clearly information technology professionals can build more of this stuff than I can.  I simply understand what can be built, what the possibilities are based on what is necessary.  Professional accountants need a complete solution.

Another thing that I don't understand is exactly HOW to construct the consistency checks and organize the metadata.  The "HOW" question is more about process efficiency and system maintainability.  The "HOW" is up to information technology professionals.  The "WHAT" is up to professional accountants and relates to effectiveness.

You don't have a choice about what makes up a complete solution.  Quality drives that.  Not measuring the quality of something does not magically increase quality.  You do have a choice as to whether work is performed using automated or manual processes.  A consequence of that choice is the cost of performing the work, how long it takes to perform work, and the quality level which can be achieved.

In terms of the "HOW"; I keep running into issues that I really don't clearly understand.  Is PROLOG the right rules engine? Or, is DATALOG a better choice?  Is there some other answer?  Maybe DROOLS.

There are probably different right answers in terms of HOW to best implement this technology.  And I am most likely missing some items which should be included on my list.  But it is crystal clear that machines can automate processes that are being performed by professional accountants.  Work practices will change.  Cost models will change.

If you have not done so yet, you may want to check out this short video which explains systems theory.