Digital Financial Reporting

An important objective when sharing or exchanging information, particularly within a distributed system, is to share or exchange that information without disputes as to the precise meaning of the information.  A lack of discipline and rigor or a lack of formality in expressing precise meaning soon leads to arguments as to information meaning.

A knowledgebase contains models (entities and relations between entities) which are common to all information that could possibly exist within that knowledgebase. The expressive power of the representation format determines how much meaning (generally the many types of relations between entities) a knowledgebase can hold.

As expressive power increases, computational complexity increases and reasoning problems can result in unforeseen complexity-caused blowups. Expressive power should be useful-yet-harmless.

The goal is to properly balance the system with carefully chosen constructors and axioms such that typical applications with a requirement for reliable and efficient reasoning support which would include knowledge description constraints and knowledge entering or quality control constraints.

The best balance between expressiveness and complexity of reasoning depends on the intended application.

An extreme case is when a knowledgebase is not satisfied by any interpretation of any model in the knowledgebase. Such a knowledgebase is considered unsatisfied or inconsistent with the knowledgebase.  Another term used to describe these situations is undecidable.  In such vacuous cases where there are no interpretations, information is proven to be ambiguous.  Such information clearly has no utility. 

Therefore, avoiding such undecidable (unsatisfied or inconsistent) cases during information representation is prudent.  Rather than undecidable, a conclusion should always be reached as to the interpretation of a result from information within a knowledgebase.  A result should always be decidable. 

"Decidable" means that no interpretations that are not satisfied (unsatisfied or inconsistent) by at least one interpretation of the information in the knowledgebase exists. If a representation of information is not decidable then the represented information is ambiguous.  If any ambiguity exists, a meaningful exchange of information between the creator of the information and the consumer of information has not occurred.

There are two perspectives which can be adopted when evauating infomation in a knowledgebase: open world assumption and closed world assumption. In the open world assumption a statement cannot be assumed true on the basis of a failure to prove the statement. On a World Wide Web scale this is a useful assumption; however a consequence of this is that an inability to reach a conclusion (i.e. not decidable). In the closed world assumption the opposite stance is taken: a statement is true when its negation cannot be proven; a consequence of this is that it is always decidable.  In other applications this is the most appropriate approach.

The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax rules, domain semantics rules, and workflow/process rules.

First-order logic can be used to express a theory which fully and categorically describes structures of a finite domain (problem domain).  No first-order theory has the strength to describe an infinite domain.  Therefore, all problem domains must be made finite, boundaries must be established.

There are two key parts of first-order logic. First, the syntax which determines which collection of symbols is legal expressions in first-order logic.  Second, the semantics which determine the meaning behind these legal syntax expressions.

Description logics (DL) is a family of formal knowledge representation languages based on first-order logic. There are many varieties of description logics each with specific characteristics which are necessary for specific types of applications.  SROIQ is a description logic variety which is always decidable.

SROIQ description logic is a syntax.  OWL 2 DL is a syntax. XBRL is a syntax. The semantics of SROIQ description logic and OWL 2 DL were consciously made consistent.  The XBRL syntax is not consistent with SROIQ description logic and OWL 2 DL semantics in terms of expressive power and therefore semantics.

XBRL's ability to express semantics should be made consistent with OWL 2 DL and SROIQ description logic's ability to express semantics.

I am not sure that I have all of this correct.  I am trying to get it correct, to dial all of this information in.  I know that I am not there yet.

This is a summary of the key points from above:

• Meaningful information exchange: The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax rules, domain semantics rules, and workflow/process rules.
• Describe and constrain are two sides of the same coin:  Rules both describe and constrain.  Knowledge description constraints describes information and knowledge entering constraints control the quality of the information as it enters a system.  Description and quality control are two sides of the same coin.
• Expressing domain semantics rules: First-order logic can be used to express a theory which fully and categorically describe structures (entities and relations between entities) of a finite domain (problem domain).
• Semantics of a financial report: Financial Report Semantics and Dynamics Theory is a theory that describes the finite semantics of a financial report in human readable terms which an accounting professional can generally understand.  It is desirable to represent the axioms and theorems of this theory in machine readable terms such that machines can verify the internal consistency of the theory, verify using automated machine-based processes to determine if a digital financial report is represented consistently with the theory, and enable software programs to leverage the machine readable information to assist a business user making use of a digital financial report using software applications.
• Decidable: Decidable means that a conclusion can always be reached.  Decidable means that there are no interpretations that are not satisfied (unsatisfied or inconsistent) by at least one interpretation. Part of achieving a "decidable" state is to use the closed world assumption (CWA) as opposed to the open world assumption (OWA). It is not acceptable/appropriate for a result to be "undecided" in the system of digital financial reporting.
• Axiom: An axiom is a premise so evident as to be accepted as true without controversy.
• Theorem: A theorem is a statement that has been proven on the basis of previously established theorems or generally accepted axioms.
• Theory: A theory is an analytical tool for understanding, explaining, describing, and making predictions about a given subject matter or domain. A theory is described using axioms and theorms  (entities and relations between entities) and checking the theory against the real world.  A theory can be expressed in natural language which is understood only by humans.  A theory can also be expressed in machine readable terms such as decision logic, OWL 2 DL, or XBRL.
• Expressive power: A syntax can be used to express the semantics of a theory in machine-readable form.  The expressive power of the syntax determines the language's ability to express the axioms of a theory.

For the past 50 years or so, people have been trying to figure out how to use computers to perform useful tasks or work. Things were created and these things matured independently in many cases. Even before computers existed; philosophers, mathematicians, and biologists tried to create ways to describe things and classify things using tools such as first-order logic (theories, axioms, theorems). 

When computers were invented other things were invented to make these sorts of things "machine readable" or readable by computers: description logics, UML, RDF, OWL, relational database schemas, XBRL, object oriented programming, and so forth. These tools evolved and continue to evolve.

Some of the problems these things solved were sometimes different; some of the problems were the same.

Along came the internet which both pushed things along more quickly because there were more things a computer could do and focused people on standard approaches to accomplishing tasks and performing work.

OWL originally had only one version and it was hard to get that one version to meet every different use case. Ultimately OWL was "stratified" into several versions.  One version does everything the original version of OWL did (OWL FULL). The Description Logic people provided their input to get an OWL variant that did what they needed (OWL 2 DL). OWL 2 DL and SROIQ Description Logic provide the same semantic tools and was made to be able to do specific things.  The same things that OWL 2 DL and SROIQ description logic needs appear to be exactly what digital financial reporting and therefore XBRL need.

OWL 2 DL and SROIQ Description Logic were consciously and thoughtfully made consistent.  Why would it be the case that XBRL should not be consistent with OWL 2 DL and SROIQ Description Logic? What sort of representations that are required for other representation schemes are not necessary for representing a digital financial report?

It is perhaps true that XBRL does not need to express everything.  XBRL only needs to represent what would be contained in a business report which would include a financial report (i.e. a financial report is a type of business report).

XBRL only needs to represent certain specific things related to financial reporting and business reporting.  It seems that XBRL could leverage its specialized use case and provide a constrained set of higher-level building blocks to fulfill the patterns of known functionally required by financial reporting.

Blockly and Scratch (watch the video) are examples of what I mean by building blocks.  Why would software vendors enabling business professionals not do this? Higher-level building blocks will be easier to use by business professionals to make use of sophistocated functionallity. There is NO WAY business professionals will ever learn low-level tools such as OWL 2 DL, SROIQ Description Logic, or XBRL+DL (description logic) syntax. Those low-level tools are far too complex for business professionals.

For example, business professionals should not need to deal with complex to understand things such as symmetric and inverse and complement.  Rather, building blocks could be created the enable business professionals to put things together which have the proper low-level structures, but achieve this using higher-lever building blocks. Building blocks could likely be effective for creating common patterns that represent 80% of the tasks a business user would perform.  Perhaps 18% could then be created using wizards which guided a business professional through the creation process.  In the rare 2% of business use cases, business professionals could rely on IT professionals to satisfy their needs.

Why would this building block-type of approach be worse than requiring a business professional to construct 100% of what they need using low-level tools which use the OWL 2 DL-type or SROIQ Description Logic-type or XBRL+DL-type low-level semnatics which is and harder-to-use complex, low level constructors?

Learn more about description logic here:

• Description logic in a nutshell: 17 page PowerPoint-type brief overview of description logic.
• A Description Logic Primmer: A little technical but a good 17 page introduction to description logic.
• An Introduction to Description Logics: More technical 40 page introduction to description logic.
• Description Logic: Wiki page.
• From SHIQ to RDF and OWL: Making of a Web Ontology Language: Paper which describes the impact that description logic had on OWL 2 DL and why OWL 2 DL needed to exist, 31 pages.
• The Even More Irresistible SROIQ: 11 pages, very technical formal proof which shows why SROIQ is the right variant of description logic (i.e. decidable fragment of first-order logic).

If you go to this analysis of the disclosures of Fortune 100 public companies you will notice GREEN and YELLOW cells.  GREEN is consistent with the model.  YELLOW is inconsistent.  The goal is to get everything GREEN.  A big part of the YELLOW relates to lack of coordination related to the classes and relations between classes.

This DRAFT comparison shows what in necessary to synchronize XBRL with OWL 2 DL and SROIQ description logic.

This DRAFT set of XBRL arcrole definitionsshows an example of what is necessary to make this synchronization. Clearly this would need to be world class.  Then, software vendors understand what they need to implement in their software to truly support what business professionals need from digital financial reporting.

A good way to understand distributed extensibility is to contrast it to the more common term "extensibility". People throw that term "extensibility" around.  But what does it really mean?

How do you really know if something is "extensible" or not?  How do you know if the extensibility actually works?  Extensibility of what?  All good questions.

Consider this basic definition of extensibility as a starting point:

• Extensibility: You can add "stuff".

OK, you can add "stuff" what stuff?  Well, if you are looking at XBRL, you might want to add one of the following: a Network, a Table (hypercube), an Axis (dimension), a Member, a Concept, or an Abstract.  You might also add a new relation between, say, one Concept and another Concept such as a roll up relation.  Or you might want to represent the parts of a whole.  So, extensibility for XBRL is that you can add those sorts of things that exist within XBRL; "stuff" and "relations between stuff".

People sometimes use the terms "open taxonomy" and "closed taxonomy".  I have used those terms myself.  But those terms are not appropriate. 

I corrected myself, realizing that taxonomies can have openings.  The way that I see this now is that taxonomies MUST ALWAYS be "closed" or rather have conscious, known, understandable boundaries.  Or more precisely, a taxonomy provides specific, conscious "openings" where those reporting against the taxonomy can consciously articulate specific information and therefore extend the taxonomy in conscious, known, specific ways ONLY.

US GAAP-based financial reporting is open.  While US GAAP does prescribe many specific disclosures; a reporting entity can add additional disclosures as it sees fit.  An entity must provide the minimum, but they can supplement what they disclosue with additional information.  Also, some relations can be moved around to a degree.  But, US GAAP based financial reporting is not a "form" that you fill in and it is also not "random".

So, when you employ XBRL-based digital financial reporting and you want to "extend" what might be reported, how you provide that extended information is not random or arbitrary.  Recall the definitions of standard and arbitrary:

• Standard: used or accepted as normal or average; something established by authority, custom, or general consent as a model or example
• Arbitrary: based on random choice or personal whim, rather than any reason or system; depending on individual discretion (as of a judge) and not fixed by law

Consider that there is one SEC and that there are about 8,000 public companies and each of those public companies can "extend" the US GAAP XBRL Taxonomy.  How is the extension of the US GAAP XBRL Taxonomy coordinated by the SEC to each of the 8,000 reporting entities?  Well, that is done through the use of standards, the XBRL standard (technical standard) and US GAAP (domain standard) and other forms of cooperation and coordination.

I would throw out these two different types of "extensibility" (this is influenced by but different from what is described in this video which I pointed out in an earlier blog post):

• Distributed extensibility: Extensibility that is not explicitly controlled and coordinated by one organization but rather using standard-based mechanisms and rules.  For example, US GAAP-based financial reporting to the SEC is a type of distributed extensibility because while the entire system is controlled by some standard set of rules, each reporting entity has control and can extend the system; but they must stay within a set of rules which coordinates the extensibility.
• Local extensibility: Extensibility that is "inside the walls" of one organization and all extensibility is explicitly coordinated and controlled within and by one organization.  For example, a chart of accounts of an organization is an example of local extensibility.

Local extensibility is far, far easier to implement because there is less coordination necessary.  And generally local extensibility was all that was needed until the internet came along and interconnected everyone.  The interconnectedness blurs system boundaries.  What does "internal" mean for say the SEC EDGAR system.  Is only the SEC "internal" or are each of the entities that report to the SEC "internal" to the system also?

Coordinating and controlling a system when users of the system are allowed to change the system is very powerful functionality.  Not change the system in random or arbitrary ways.  But rather change the system in standard and agreed upon ways.

These "agreed upon ways" are the rules of system extensibility.  They explain exactly how the system can be extended.  This agreement is achieved by using appropriate rules.  I will repeat my mantra for anyone who might have missed it:

The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax rules, domain semantics rules, and workflow/process rules.

It is the rules which provide to control and coordination which makes the distributed extensibility work effectively. It is the rules which turn the guessing game into a reliable, predictable, repeatable and therefore useful distributed, yet coordinated, system.  It is the rules that form the agreement in a distributed environment. It is the rules which are a cooperation tool.

As I said in my book XBRL for Dummies, "Agreement is an important element that acts as the invisible glue to make XBRL really work."  Agreement does all sorts of powerful things.

Business professionals are taught a basic idea in business school, "If you cannot measure it, you cannot control it."  H. James Harrington puts it this way:

Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.

My disclosure analysis of the Fortune 100 is an example of measurement. Control is trying to get all the cells in the matrix GREEN which means that all parties agree.

The XBRL-based public company financial filings in the SEC's EDGAR system is an example of distributed extensibility almost done right.  Based on my measurements, the system appears to be about 90% correct. With just a little more coordination and cooperation in the area of defining classes and relations between classes, we will dial in the remaining 10%.

That, in my view, is an example of the utility of XBRL toward achieving distributed extensibility.

Digital Financial Reporting Principles provides additional details, building on and using the Financial Report Semantics and Dynamics Theory.

There are two primary uses for the Digital Financial Report Principles document:

1. Helpful information for accounting professionals creating XBRL-based digital financial reports such as public company financial filings submitted to the SEC.
2. Helpful information for software vendors creating software used by accounting professionals for creating XBRL-based digital financial reports.

As Henry Ford said:

Quality means doing it right when no one is looking.

Digital financial reporting is not only inevitable, it is imminent.  If implemented correctly, digital financial reporting is useful whether required by some regulatory mandate or not.  Most people look at digital financial reporting through the rear view mirror of the last 100 or so years of paper-based financial reporting.  Fifteen years ago when XBRL-based financial reporting began it took a pretty high-powered telescope to see the vision for what digital financial reporting could be.  Today, it only takes a good set of binoculars.

However, for the market for digital financial reporting to move from the 8,000 mandated public companies to the 28 million private companies, it has to (a) work and (b) provide significant value over the current status quo.

Digital Financial Reporting Principles provides many, many clues for those who understand how to use the resource correctly.

I tend to be a big picture person.  I have to understand the big picture in order to be sure I am considering the right details.  Rene van Egmond and I created the Financial Report Semantics and Dynamics Theory back in 2012 to get our heads around digital financial reporting.

But I can be incredibly detailed oriented also.  Rene and I came up with what was included in the first version of the Financial Report Semantics and Dynamics Theory based on years of analyzing what we called "patterns".  I then backed into the axioms and theorems that made up the theory based on observations made of every XBRL-based financial filing of public companies for fiscal year 2011.  I used a combination of commercial software and tools that I built, but I mainly had to rely on my tools because the commercially available software did not do the trick.

I repeated that process for fiscal year 2012 XBRL-based filings and then again for 2013 XBRL-based filings. This lead to an understanding of what I called "the minimum criteria", the fundamental accounting concepts and relations between concepts, report frames, and classes and relations between classes.

I repeated the process again for 2013 a couple of times using incrementally improving commercially available software and relying less on the limited software that I could create.  That ultimately led to a prototype which incorporated all of these ideas using mostly commercially available software and some HTML pages I created to summarize results the way I wanted to see them.

All that testing lead to significantly improved knowledge which I have incorporated into an improved version of the Financial Report Semantics and Dynamics Theory. You can go read the document, all changes can be seen as I left track changes on for now.  Both the additional testing and software implementations contributed to tuning the axioms and theorems which literally explain the semantics and dynamics of a digital financial report.  This document is proving very helpful in contributing to getting software created which is useful to business professionals.  The document is basically a communications tool.

The next step is to incorporate all of this information into the Digital Financial Reporting Principles document and then the Digital Financial Reporting book.  Eventually, all this information will be organized and synthesized into one resource for professional accountant.  But to do that, I need some software which hides the unimportant technical details from business professionals.  That software is slowly making its way into the market.

Why go through all of this effort?  Here is a reading list that will help you understand.

• Disclosure Checklist: This is one goal, automating as much of this disclosure checklist as possible. This provides additional details.
• Relation between expressiveness and reasoning capacity: This helps you understand what is necessary to achieve automation.
• Digital financial reporting harnesses computers for speed, accuracy: This helps you understand the sorts of things that can be automated.
• Digital financial reporting will change accounting work practices: This helps you understand the sorts of things that can be automated.
• Understanding Digital Financial Reporting: This provides additional details.

That's why.