Digital Financial Reporting

John F. Sowa's paper Fads and Fallacies about Logic made something very clear.

The challenge of getting XBRL-based structured data financial reports to work correctly for public companies is not a technical problem; rather it is an even more formidable challenge of fads, misinformation, trends, arbitrary preferences, politics, and standards.

This is what I learned:

1. There is a communications chasm between business professionals and information technology professionals.  Business professionals need to cross that chasm by learning how computers work. Fear of technology is uncalled for. (Please read Comprehensive Introduction to Knowledge Engineering for Professional Accountants)
2. Syntax does not matter, it is a technical detail.  Semantics matters to business professionals.  There are so many technical alternatives available, so many things that are not interoperable that should be interoperable, endless philosophical debates and theoretical arguments, and most are a waste of time and energy.  Being practical matters.
3. Business professionals don't need to "learn to code" or even learn technology.  Software developers need to learn to build better software.  To get this, business professionals need to understand what software to ask for.
4. Business professionals need to gain an understanding of logical principles.  Basic stuff like: there exists, every, and, or, if-then, not, true, and false.  Really, it is that simple.
5. The hardest task of knowledge representation is to analyze knowledge about a domain and state it precisely in any language. This is not a technical problem, this is a domain problem. Only business professionals can describe a business domain.  Full stop.
6. Any declarative notation could be treated as a version of logic: just specify it precisely.  XBRL definition relations can be a logic if used correctly.  So can XBRL Formula.  XBRL presentation relations not so much.
7. The logic notations of the middle ages is better than the stuff mathematicians and computer scientists came up with. (see the diagram on page 2, that is logic)
8. The tools that will be created for digital financial reporting will be very powerful.

This is John Sowa's summary of his article:

In summary, logic can be used with commercial systems by people who have no formal training in logic. The fads and fallacies that block such use are the disdain by logicians for readable notations, the fear of logic by nonlogicians, and the lack of any coherent policy for integrating all development tools. The logic-based languages of the Semantic Web are useful, but they are not integrated with the SQL language of relational databases, the UML diagrams for software design and development, or the legacy systems that will not disappear for many decades to come. A better integration is possible with tools based on logic at the core, diagrams and controlled NLs at the human interfaces, and compiler technology for mapping logic to both new and legacy software.

Digital is coming to financial reporting.  Accountants, who came up with the idea for XBRL, are leading the way.  Public company XBRL-based financial reporting to the SEC is showing the way and working out the details.  Standards will be perfected by the market. Per the Law of Standards, things will get simpler; the market will see to that.

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:

1. Support normal stuff that high-quality XBRL Formula processors support (i.e. Arelle, UBmatrix/RR Donnelley, Fujitsu, Reporting Standards, etc.)
2. Support inference (i.e. deriving new facts from existing facts using logic)
3. 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)
4. 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)
5. 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
6. 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:

1. Improve the capabilities of XBRL Formula processors as indicated above.
2. 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.

In a video, The New Leadership Paradigm: An Interview with Richard Barrett, Richard Barrett explains that the essential ingredient of a high-performance team is trust.  What is trust?  The graphic below provides a breakdown of what creates trust. Before trust exists, certain other dependencies must also be present. The principal components of trust (the dependencies) are shown in the following diagram:

(The New Leadership Paradigm)

Being a high-performance team provides a competitive advantage. High-performance teams eliminate unnecessary or unproductive work that does not add value; enabling focus on necessary and productive work.