Current XBRL Formulaprocessors don't meet the needs of XBRL-based financial reporting. All of the XBRL-based business rules and other metadata that I have created (i.e. fundamental accounting concept relations, disclosure validation, model structure validation) to support the creation and 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.
To overcome these deficiencies, the following capabilities should be be provided:
- 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)
- Improved support 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 for chaining, specifically 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 semantics logic which is a set of logic that is highly expressive and safely implementable in software and is consistent with ISO/IEC Common Logicand 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 (for example these and these)
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):
- 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 is NECESSARY (i.e. see the Law of Conservation of Complexity) to enable professional accountants to properly work with XBRL-based structured financial reports. The margin for error is ZERO. If you don't understand this, I would encourage you to read the Framework for Understanding Digital Financial Report Mechanics.
There are exactly two ways to achieve this functionality:
- Improve the capabilities of XBRL Formula processors as indicated above.
- Enhance existing business rules engines to support XBRL.
So that is WHAT needs to be done. I am less clear on HOW to best achieve this.