Digital Financial Reporting

In prior blog posts I mentioned semantic reasoners, inference engines, XBRL Formula processors, and other such logic processors (not completely sure what to call these things).

What I was trying to figure out was what sort of application is necessary to process the information contained in an XBRL-based financial report in order to perform sophisticated verification of the information provided in such a structured data document.  One example is accounting and reporting checklists.

One thing that I have figured out is that syntax is not important.  It is semantics that is relevant, particularly the expressiveness of the semantics and the safe implementation of the semantics.  Fads and arbitrary preferences confuse and confound people, making it hard to get a straight answer.

Well, this is what I have figured out.  First, I can articulate all the semantics that I can imagine using XBRL.  As such, it would make sense to use an XBRL Formula processor to process the XBRL instances and related XBRL taxonomy information (including metadata that one can add).

But, all of the XBRL-based business rules and other metadata that I have created to support the creation and sophisticated validation of XBRL-based financial reports of the style that are submitted by public companies to the SEC shows that the currently available commercial XBRL Formula processors (which sit on top of XBRL processors and XBRL Dimensions processors) have specific deficiencies.  Literally, all are deficient.

To overcome these deficiencies, the following capabilities MUST exist or need to be added to XBRL Formula Processors:

• Support normal stuff that high-quality XBRL Formula processors support (i.e. Arelle, UBmatrix/RR Donnelley, Fujitsu, Reporting Standards, etc.)
• Support inference (i.e. deriving new facts from existing facts using logic, what inference engines do)
• Improved support validation and use of structural relations (i.e. XBRL Taxonomy functions; this was consciously left out of the XBRL Formula specification in order to focus on XBRL instance functionality)
• Support forward chaining and possibly also backward chaining in the future (i.e. chaining was also proposed but was left out of the XBRL Formula specification)
• Support a maximum amount of Rulelog logic which is safely implementable and is consistent with ISO/IEC Common Logic and OMG Semantics of Business Vocabulary and Business Rules
• Additional XBRL definition arcroles that are necessary to articulate the Rulelog logic, preferably these XBRL definition relation arcroles would end up in the XBRL International Link Role Registry and be supported consistently by all XBRL Formula processors (i.e. these general arcroles, and these financial disclosure related arcroles; this human readable informationis helpful to understand the arcroles)

If you try and reconcile the pieces of XBRL with the components of an expert system, you can clearly see the specific deficiencies in the capabilities XBRL Formula processors (i.e. the above list).  Here is that reconciliation:

• Database of facts: A database of facts is a set of observations about some current situation or instance. The database of facts is "flexible" in that they apply to the current situation.  An XBRL instance is a database of facts.
• Knowledge base (rules): A knowledge base is a set of universally applicable rules created based on experience and knowledge of the practices of the best domain experts generally articulated in the form of IF…THEN statements or a form that can be converted to IF...THEN form. A knowledge base is "fixed" in that its rules are universally relevant to all situations covered by the knowledge base.  Not all rules are relevant to every situation.  But where a rule is applicable it is universally applicable.  All knowledge base information is machine-readable. An XBRL taxonomy is a knowledge base.
• Rules processor/inference engine: A rules processor/inference engine takes existing information in the knowledge base and the database of facts and uses that information to reach conclusions or take actions.  The inference engine derives new facts from existing facts using the rules of logic. The rules processor/inference engine is the machine that processes the information.  An XBRL Formula processor is a rules processor and, if build correctly, can perform logical inference.
• Explanation mechanism: The explanation mechanism explains and justifies how a conclusion or conclusions are reached.  It walks you through which facts and which rules were used to reach a conclusion. The explanation mechanism is the results of processing the information using the rules processor/inference engine and justifies why the conclusion was reached.  The explanation mechanism provides both provenance and transparency to the user of the expert system.

This functionally listed above is necessary to properly work with XBRL-based financial reports.  Please review the Law of Conservation of Complexity.  Financial reports simply cannot have errors and there is too much detail in a structured data-based report for humans to get right using only manually oriented human-based processes.  There are exactly two ways to achieve this functionality:

1. Improve the capabilities of XBRL Formula processors as indicated above (i.e. add the listed capabilities to existing XBRL Formula processors).
2. Enhance existing business rules engines to support XBRL

If you want to understand better what I am saying here, please read the document Comprehensive Introduction to Expert Systems for Professional Accountants.  If you want an even better understanding, have a look at the Framework for Understanding Digital Financial Report Mechanics.

If you have any feedback to improve what I am saying here, please let me know.  If you know of any other resources that explain this stuff better than I have, please make me aware of those resources.