Digital Financial Reporting

Ultimately systems need to interoperate. This is particularly true today in our networked world in our Digital Age.  The common denominator is business logic.

John F. Sowa put it this way in the conclusion of his paper Fads and Fallacies about Logic: (page 6)

"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 natural languages at the human interfaces, and compiler technology for mapping logic to both new and legacy software."

A reality is that people will always come up with their own approaches to doing certain things.  As such, single-stack architectures might exist within one very small organization; but when you look at organizations of any size or when you have one organization interoperating with another organization you will have multi-stack architectures and each of those architectures need to interoperate.

One architecture stack which has matured very significantly over the past 25 years is the Semantic Web Stack.  As I understand it, in the early days of the semantic web, things were pretty much designed to work one way, the way academics saw the world.  But now, those designing business systems have been heard and there are alternative approaches that satisfy the needs of academics and of those designing business systems.  There is one area of uncertainty. Will the semantic web stack use RDF, OWL, RIF, and SWRL which was created by academics; or will it use RDF, OWL, and SHACL which was created by more business systems designers.

There are many, many important fundamental details related to business logic and logic in general that one needs to get right when designing parts of a stack.  For example, here are the Use Cases and Requirements of SHACL.  UC16 discusses things like the "closed world assumption" and the "unique name assumption".  These are critical things that make the eyes of most business professionals glaze over and what is becoming very obvious is that the average software developer is not familiar with these critically important issues.

Because of the lack of interest of business professionals and the lack of understanding of the average software developer, design mistakes creep into technical architectures that cause fundamental problems.

But, multi-stack architectures that need to interoperate are a reality, as pointed out by Michael Kifer, Jos de Bruijn, Harold Boley, and Dieter Fensel, in their paper A Realistic Architecture for the Semantic Web:

"In this paper we provided an in-depth discussion of the multi-stack architecture (MSA) for the Semantic Web and argued that a stack of rule-based languages, complete with default negation, should exist side-by-side with the ontology stack based on OWL."

What does all this mean for XBRL and the XBRL technical stack?

This is how I see it based on my 20 years of experience trying to figure out how to best employ XBRL for digital financial reporting.

First, XBRL clearly does not get to redefine business logic or logic in general.  Logic in general and business logic in particular, such as the business logic of US GAAP which has been around and tuned for many years, simply cannot be changed by XBRL or any other technical syntax.  Business logic is the common denominator between technical implementations.  Each technical implemenation must us the same business logic.  How they implement that business logic is up to them; but they cannot simply change or ignore business logic. To be clear, I am NOT saying that XBRL is changing business logic.

Second, all that "stuff" exists in the semantic web stack for a reason.  If similar "stuff" does not exist in the XBRL stack then XBRL will have missing capabilities and users of the XBRL stack will be unfulfilled. 

There are two critical issues or areas that XBRL falls short that I can see: 

1. The clear definition of the business logic of a business report which is a fundamental layer of business logic.  Evidence of this is the XBRL-based financial reports of public companies which are created and then submitted to the SEC.  While the vast majority of information reported does follow the business logic that I would expect for a business report, a small minority of the information disclosed does not.
2. The ability of those representing business logic within a business report, such as a financial report, to clearly describe that business logic to themselves so that they can get their report consistent with that logic and to users of the report so that the user of the report can understand the meaning conveyed by the business information reported.

These issues reveal themselves as quality problems within the information conveyed by the report. And it is not so much that one cannot do both #1 and #2 above.  You can.  How do I know?  Because I can do both of these things within financial reports.  Here is my business logic. Here is how I represent logic within a financial report.  The result is financial reports with no errors.  The problem is that there is no agreed standard way to represent business logic within XBRL and that most business professionals seem to be unaware of the ramifications of NOT representing this business logic.  Thus the quality issues.

Important to understanding the above is an understanding of the fundamental strengths or capabilities of computers and the major obstacles that have to be overcome to leverage those strengths/capabilities. This explains WHY you need standards and WHAT you need those standards to do. These strengths and obstacles are summarized well by Andrew D. Spear in his document, Ontology for the Twenty First Century: An Introduction with Recommendations, page 4:

Fundamental strengths/capabilities of computers:

• store tremendous amounts of information reliably and efficiently
• retrieve tremendous amounts of information reliably and efficiently
• process stored information reliably and efficiently, mechanically repeating the same process over and over
• make information instantly accessible to individuals and more importantly other machine-based processes anywhere on the planet in real time

Major obstacles to harnessing the power of computers:

• business professional idiosyncrasies; different business professionals use different terminologies to refer to exactly the same thing
• information technology idiosyncrasies; information technology professionals use different technology options, techniques, and formats to encode information and store exactly the same information
• inconsistent domain understanding of and technology's limitations in expressing interconnections 
• computers are dumb beasts; computers don't understand themselves, the programs they run, or the information that they work with

Information business professionals are trying to store and make use of is becoming more complex than what they have been storing in relational databases or spreadsheets for the past 50 years.  A financial report is complex information. 

Information is not just a long list of facts, but rather these facts are logically, mechanically, mathematically interconnected and generally used within sets which can be dynamic and used one way by one business professional and some other way by another business professional or by the same business professional at some different point in time.  These relations are many times more detailed and complex than the typical computer database can handle. Business professionals sometimes do not understand that certain relations even exist.

As someone put it, rather than "paving the goat path" and replicating existing inefficiencies related to old-school paper-based reporting in XBRL-based digital financial reporting software; we chose a different path.

One type of practical knowledge is know-how; how to accomplish something.

Creating a knowledge based system involves the transformation of machine-readable instructions in such a way as to explain to a machine how a system works and how to make a system work the way you want that system to work.

Then, brick-by-brick, much like building a house, business domain experts and software engineers can create tools that automate certain types of tasks in that process. Humans encode information, represent knowledge, and share meaning using machine-readable patterns, languages, and logic. That will be the way an increasing number of work tasks will be performed in the Digital Age of accounting, reporting, and auditing.  The result will be more efficient processes.

A software engineer and I tested the feasibility of creating an expert system for creating XBRL-based structured financial reports to prove the concept.  We are making that software available free of charge until March 31, 2018.

We also provided information about the techniques we used to create this working proof of concept.  The document, Putting the Expertise into an XBRL-based Knowledge Based System for Creating Financial Reports, provides this information.

We will be making this software available free of charge to filing agents, software vendors, accountants, and public companies as part of my Campaign to Improve Disclosure Quality of XBRL-based Public Company Financial Reports Submitted to the SEC.  This is an excellent opportunity to understand the explicit knowledge and the tacit knowledge needed, the know how, to build such a system and how that system needs to work in order to be considered useful by professional accountants.

The software engineer that is collaborating with me on this and his colleagues won the prize of 9th XBRL Global Academic Competition 2008-2009, which was held in Bryant University, USA.

In addition, another software vendor has implemented these ideas in a product that is commercially available.  This is explained in the document, Process for Verifying Quality of an XBRL-based Financial Report, which helps one understand how to create a reliable, repeatable process for creating quality XBRL-based financial reports.

We believe this will be an industry changing technology, disrupting the process of creating financial reports. Most people don't recognize this yet because they don't understand the paradigm shift that is occurring. But, we do.

If you don't want to follow the same old goat path, read PART 1 to understand the general approach to what we are doing and PART 2 to better understand the conceptual model of an intelligent XBRL-based digital financial report.