Digital Financial Reporting

I have shown the graphic below before.  The graphic summarizes the relative expressiveness and related relative reasoning capacity of various knowledge representation languages.  I stole this idea from this blog post and this presentation which show the same information, I just organized some things slightly differently and added various XBRL implementation strategies: (see my original blog post here)

(Click image for larger view)

Here is another good graphic that compares relative expressiveness of different languages also:

From Harry S. Delugach, Common Logic in Support of Metadata and Ontologies, bottom of page 2

The vast majority of people are familiar with the level of expressiveness which can be achieved using relational databases.  Experience with relational databases for past 25 years helps us undertand that.  See my blog post Characterizing Truth: Semantics in Databases which explains the expressiveness which has generally been expressed within databases and specifically this graphic which tries to show limitations of databases.

But things are changing.  Here are some changes that I see occurring:

• Richer information is being stored in databases: Contrast storing the information for an invoice in and accounting system with storing the information from an XBRL-based public company 10-K financial report.  Both can be seen as transactions.  But the relative richness of information in the financial report exceeds the relative richness of the information in the invoice.  In the past, things like financial reports were not even structured.  More and more information will be structured in the future.
• Business rules are moving from code to metadata: In the past, the information used to verify something like an invoice was stored in the code of an application, in the programming logic. That made it hard to add new rules or change rules because it took a programmer.  This approach was costly and made such rules hard to maintain.  Ronald G. Ross is the "father of business rules". Business rules are metadata which is properly separated from programming logic and maintained by business professionals.
• More business rules are necessary because information is richer: Because the richness of information is going up, the quantity of business rules that keep the quality of the information high also must also go up.
• More transactions and business rules are external to an organization: People could look at their systems as "silos" in the past.  The Internet is changing that all that.  Today sets of transactions can be shared between enterprises.  Business rules are shared also.  Think supply chain.

So those are the changes that are occurring.  There are different camps of software vendors trying to provide products and solutions that address with these changes.  There is the "semantic web" camp which seems to be pushing RDF/OWL and new types of databases such as triple stores and reasoners/inference engines and SPARQL queries.  And you have your "NOSQL" camp that seems to be pushing NOSQL databases as the answer to these changes.  And of course there are the entrenched incumbents, the relational database vendors, where a boatload of information is currently being stored, there is a heavy investment in such relational databases, and the relational database has morphed more than once in order to keep up with the changes that are occuring.

But I don't think anyone has pulled all the pieces together and gotten this right yet.

No one product/solution has put all the right pieces together and balanced the system correctly. For me, if the pieces are put together correctly you get an expert system.  In this blog post I summarize the benefits offered by an expert system.  Think "smart database".

Remember the Law of Conservation of Complexity and the notion of irreducible complexity.  Remember that irreducible complexity is explained as follows:

A single system which is composed of several interacting parts that contribute to the basic function, and where the removal of any one of the parts causes the system to effectively cease functioning.

Partial solutions will not work.  Complete solutions are necessary.  What are the evaluation criteria which one should use to determine is some product or solution will fit your needs?  Here are the general, high-level criteria as I see them:

(Click image for larger view)

It will be interesting to see what software vendors come up with. Balancing all these pieces and creating the proper equilibrium will be a valuable tool for business professionals.

The Securities and Exchange Commission is allowing Inline XBRL to be filed.  Here is a filing from one public company that was submitted in Inline XBRL and accepted by the SEC:

https://www.sec.gov/Archives/edgar/data/920760/000162828016017488/0001628280-16-017488-index.htm

You can go to that page and click on the link for the first document, the 10-Q HTML file, and you will be taken to the new SEC Inline XBRL Viewer. (Or just click here)

The SEC is seeking feedback.  Please be sure to provide your feedback.  That is how things get improved.

******** MORE INFORMATION ******

SEC Inline XBRL Mockup Provided: https://www.sec.gov/ix?doc=ixviewer/samples/bst/out/bst-20160930.htm

Consider this.  A public company takes information about their financial position and financial condition out of a database and/or electronic spreadsheet.  The put that information into the XBRL format and send that financial information to the U.S. Securities and Exchange Commission (SEC).  The SEC, and others, take that financial information and put it into another database.

The database the information came out of typically does not understand the the information that is coming out of the database.  The database has no understanding of business context, it just stores data.

The XBRL-based format does have context, but most XBRL processors don't understand that context.  Just because current XBRL processors don't understand the context does not mean that the context is not there. For example, just because public companies and software vendors make basic mistakes in representing the information in the XBRL format does not mean that the context does not exist.  The context does exist within the XBRL format.

The database that the information ends up going into typically does not understand the context of the information being put into the database.  The 28msec database, SECXBRL.info, is a little different in that the context of the information from the XBRL is stored.  Not the XBRL technical syntax, the context of the information.  There is a big difference between the two.  Now, the 28msec database does not understand much of that context such as the relations between facts in the database such as "Assets" and "Liabilities and Equity".  Why?  Because they don't have the machine-readable rules that articulate that context.  But what if their database did have those machine-readable rules?  They do have some.

The graphic below tries to show what I am talking about.  The graphic was inspired from another graphic which I modified to better communicate what I am trying to point out. Here is my version of this graphic:

(Click image for larger view)

The paper Semantics in Databases points out many issues related to storing and working with semantics in database management systems (DBMS).  The first thing the paper points out is the many different ways people use the term "semantics" in computer science. The paper goes on to point out that DBMS incomplete and partially unsound facilities for handling semantics.  This statement from the paper succinctly articulates the issue:

"The same statement must have a stable interpretation and cannot be differently interpreted by different computer systems."

That statement gets to the same point that I have been making for many years: achieving a meaningful exchange of information.

This is perhaps a little bit of a leap.  But, what if XBRL was a global-standard facility for expressing, exchanging, and verifying DBMS semantics?  Could it be that XBRL is a solution to some of the issues pointed out by that paper?

That paper makes the statement, "This widespread usage of the term 'semantics' has led to very different goals, methods, and applications."  Why would ISO create a global standard for Common Logic? What, some people did not have anything better to do one weekend?  I don't think so. Why are people creating RuleML?

It seems to me that the semantic web is struggling.  While there are issues with getting XBRL to work, the folks creating electronic medical records are having similar sorts of issues. Will the vision of the semantic web ever be realized?  Does XBRL have a role in that vision?  I think it does.

What do you think?

******MORE INFORMAION*********

Book, Semantics in Databases.

The quality of XBRL-based public company financial reports to the SEC as measured using a set of about 22 fundamental accounting concept relations continues to improve. Several software vendors/filing agents are closing in on 100% consistency with these basic expected accounting relationships.

About 84% of all public company financial filings are consistent with what is expected for these fundamental accounting concept relations.

Note that I am going to start publishing this information once every quarter or when important milestones are met.

Breakdown by software vendor/filing agent: 

Breakdown by individual test: 

(Click image for larger view and more details)

Comparison of Current Results with 2015 and 2014 End of Year Results:

(Click image for larger view)Be sure to read this updated version of the conceptual overview of XBRL-based structured digital financial reports.  Also, this updated outline of knowledge engineering basics for accounting professionals helps you understand why quality matters.

* * * PRIOR RESULTS * * *

Previous fundamental accounting concept relations consistency results reported: March 31, 2016; February 29, 2016; January 31, 2016; December 31, 3015; November 30, 2015; October 31, 2015; September 30, 2015; August 31, 2015; July 31, 2015; June 30, 2015; May 29, 2015; April 1, 2015; November 29, 2014.