Digital Financial Reporting

I have abandoned two terms I used to use, XBRLS and "general profile", in favor of a better term created by someone else.  That new term is NOLAP.

While traditional OLAP is a powerful and useful tool, OLAP has many known limitations including:

• There is no global standard for OLAP (A company created a product, ADAPT™, which reconciled different OLAP models to one standard model, but ADAPT™ is a proprietary model
• Cube rigidity
• Limited computation support, mainly roll ups; does not support other common types of computation-type relations such as a roll forward (changes between two periods), adjustment (difference between an originally stated and restated amount), variance (difference between two reporting scenarios)
• Limited business rule support and inability to exchange business rules between implementations
• Inability to transfer cubes between systems, each system is a "silo" which cannot communicate with other silos
• Inability to articulate metadata which can be shared between OLAP systems, for example standard dimensions or members used across many systems
• Focus on numeric-type information and inconsistent support for text data types
• OLAP systems tend to be internally focused within an organization and do not work well externally, for example across a supply chain
• OLAP tends to be read only

NOLAP or the "general profile" of XBRL overcomes these issues of OLAP.  This is the history of how I have arrived at this point.

Several years ago, in 2008 actually, after having spent a number of years traveling around the world, working on numerous XBRL taxonomy projects and other system implementations of XBRL; Rene van Egmond and I noticed some things about these taxonomies.  We wrote a paper which summarized this information: XBRLS: How a simpler XBRL can make a better XBRL.  In that paper Rene and I pointed out that:

• (a) XBRL taxonomies were not interoperable,
• (b) there is a need for a "general" implementation profile so anyone could just pick up XBRL and use it and not have to be an engineer/architect to figure out how to put all the pieces together correctly.

It was during that time that Rene helped me understand what semantics was and that semantics and syntax were different things.  This helped me understand a bunch of things about the taxonomies I had been creating.  At first I thought this was all about "patterns", then I thought that there was a missing logical model, spent time discussing and learning about this "stuff" as part of the XBRL International Taxonomy Architecture Working Group.

All that resulted in a few people actually understanding that XBRL was missing a high-level semantic model and the creation of the XBRL Abstract Model 2.0.  It wasn't perfect, but it was a huge step in the correct direction.

I spent the next three years poking and prodding SEC XBRL financial filings in order to understand them and reverse-engineering those filings to try and figure out how to make XBRL work correctly when the extension features of XBRL were used.  The goal was to understand how to get the extensibility to work correctly. The reason for that was to both understand how to employ XBRL for financial reporting and to understand how to use XBRL, with extension, in other business domains.

There were numerous discussions that I had with others, pulling together as much useful information that I could.  I took all of this information and created what I called a "general profile" for implementing XBRL.  That profile took all the best ideas which I had accumulated and pulled them together into one rock-solid architecture and implementation approach.

I took these ideas, tried to get some software vendors to understand them, and even got a handful of software vendors to implement them.  One day a software vendor who was not even in the XBRL space contacted me because they thought XBRL offered a solution to a problem that they had.

That collaboration resulted in two different problems being solved: mine and theirs.

I had been experimenting with RDF and OWL to see if they were the approach to solving a big problem that I was experiencing.  I eventually distilled the problem into one realization:

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

That statement was then "exploded" into all of the pieces which are necessary to make XBRL work if extensibility is employed: Attaining high semantic clarity and smart digital financial reporting tools.

Basically, none of this is "magic" or "rocket science".  It is not subjective in any way, it is objective. It all boils down to attention to detail.  Proof of this is looking at SEC XBRL financial filings and understanding why one fails at being able to use the information they contain.  You can see what works, you can see what does not work, and most importantly you can see how to fix what does NOT work to make it work.  Should one care to look, all this is summarized right here: Summary Information from Evaluating SEC XBRL Financial Filings.

You can also see that right here: SECXBRL.info.  If you know what to look for and if you look closely, you can see exactly how to represent financial information digitally and then query that information.

People who take the XBRL technical syntax, take that syntax and put it into a relational database, RDF triple store, or any other database and then try and query the information and try and use it will be disappointed.  SECXBRL.info did not make that mistake.  SECXBRL.info also improved upon my infosets.  My infosets were too rigid.  They provided one view of the information, from that of the creator.  SECXBRL.info improved upon my infoset format.  They even published how they did that, which you can find here.

So ultimately, SECXBRL.info provided two critically important things: (a) financial information represented in a proper semantic format within a database and (b) an easy to use query language to get at that information.  You can now look at the information, look at the queries, see what works and what doesn't work and most importantly WHY something does not work.  That allows you to fix what is broken to make everything work.

I have always looked at the pieces of an SEC XBRL financial filing as individual "cubes" or "hypercubes".  Others do also. If you go to the OLAP Cube page on Wikipedia you see the following as part of a description of an OLAP cube:

A cube can be considered a generalization of a three-dimensional spreadsheet.

One day out of the blue, 28msec started using the term NOLAP to describe those pieces of a financial report.  I had used the term "semantic spreadsheet". NOLAP means Not Only SQL based OLAP.  I think that is a great term.  I am abandoning the terms XBRLS and "general profile" for implementing XBRL.  That is what NOLAP is, a general form of implementing XBRL.

NOLAP is a global standard multidimensional model.  You can use whatever syntax you want internally in your system, but the model used should be the same across business systems.  If you want to exchange information or the model between business systems, XBRL is the syntax for doing that.  There is a lot more on that NOLAP Wikipedia page, check it out.

NOLAP brings business analytics to the NoSQL database.  Not sure what the current business intelligence vendors think about that.

Good idea?  Time will tell.  What do you think?