Digital Financial Reporting

I remember back in, oh I think it was 2001 or 2002 when a few of the technical people introduced the linkbase to XBRL. Most people did not "get it" back then. I did not "get it" at first. But, with the help of some really good technical people, I eventually understood what a linkbase was, why it was important, and why we needed to use them in XBRL.

A linkbase is basically the way XBRL expresses a semantic network. A semantic network is an artificial intelligence technology.

I am not going to go into explaining what a semantic network is, I have a different point.  My point is that if you are a technical person or a business person and you don't understand the meaning of terms such as network, graph, syntax, semantics, RDF, OWL, SKOS, metadata; then you are at a significant disadvantage.

Why do I say this?

The world of financial reporting is about to change in a very big way.  It is already changing. If you don't understand where financial reporting is going then you likely don't know how to get there. Let me give you one specific example.

In a prior post, I mentioned Risk Modeling at the SEC: The Accounting Quality Model.  In that speech; Craig M. Lewis, Chief Economist and Director, Division of Risk, Strategy, and Financial Innovation at the SEC; described some things the SEC are doing.  Do you believe that what the SEC will do will work and to what extent?  Do you know how the SEC is going to build what they are proposing? Do you understand what to do to build counter measures so you don't unnecessarily stick out on the SEC radar?

There will be many layers to this notion of The Accounting Quality Model.  The first layer is basic financial semantics.  If your financial report does not have an identifiable balance sheet, if that balance sheet does not provide expected concepts such as "Assets" and "Liabilities and Equity" and "Equity", if your balance sheet does not balance, if your "Assets" and "Liabilities and Equity" don't foot; you will be flagged.  Why?

Accurate processing of the subsequent layers is impossible unless the first layer processing is successful.  The more sophisticated processing which the SEC seems to be envisioning by that speech cannot be achieved unless all the first layer ducks are all in a row.  Now, one could take the view, "Hey, let's just hinder the SEC's attempts at higher level processing by making sure we have issues which block their ability to process our information."  Some people will likely take this approach, but that will not last long.

But forget about the SEC and SEC XBRL financial filings; I am only using that as an example of what is possible.

What if your organization could apply similar approaches to your internal systems?  What if your organization had an internal Accounting Quality Model-type or some other semantic model that you used to evaluate all sorts of things similar to how the SEC is going to use all that XBRL information?

Welcome to knowledge management!

If you don't understand what a graph is, what a network is, what metadata is, how RDF inference engines work, why semantics are more important than syntax; then it is highly unlikely that you "get" what I am saying here.  Thus the need to understand.

If you don't understand these terms, if you don't understand that XBRL linkbases are semantic networks, then it is highly unlikely that you are a business person who is pushing for the correct software applications or that you are a software developer who is architecting or otherwise developing the correct software.

If you are a business person and you don't understand those sorts of terms, then it is highly unlikely that you can communicate appropriately and convince other business people where things are going.

If you are a business person and you don't understand those sorts of terms, then it is highly unlikely that you can articulate to a software developer what software they should be building.

A business user needs to understand these sorts of things in order to understand what metadata they need, why they need it, and how to properly express that metadata.

A technical person who does not understand what a graph is won't realize that when most people create XML, the generally create trees which are more limited than graphs.

I could go on and on but if you will get my point, you probably already have.

Folks, syntax does not matter (or maybe it is better to say that it is only one thing that matters), it is the semantics that matter. XBRL is a technical syntax.  It is just a format that you output to when you need the things XBRL has to offer.  And XBRL has a lot to offer.  It's status as a global standard is very important.  All those standard taxonomies for financial reporting are important.  But the biggest benefit XBRL offers is its business rules engine.  RDF/OWL does not have this functionality.  XML alone does not have it either.  XBRL alone also has its disadvantages, for example limited functionality for expressing metadata.

RDF/OWL has its advantages, such as its inference engines.  Anyone who thinks that they don't need to use XBRL or RDF/OWL because they already use XML does not understand the differences between those three technical syntaxes.

Semantics is where all the action is.  That is what enables the sort of thing the SEC envisions and describes in that speech.  You can have that sort of sophisticated processing also, internally, in your organization. This type of processing is by no means limited to external financial reports.

Interested in RDF?  This Introduction to RDF provided by IBM is a good place to start. This RDF Tutorial is also quite helpful.