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.