Digital Financial Reporting

A number of years ago after a meeting at the XBRL International Conference in Tokyo where I was showing some things I was working on to Geoff Shuetrim and Rene van Egmond, Geoff made the statement, "Charlie, you are like a guy who is trying to escape from prison using a teaspoon."

I am not sure if that was meant as a complement, but that is the way I took it. I have been trying to achieve something for, I don't know, three or four years and I have finally reached my goal!

The goal was to render the information contained within an XBRL instance in a human readable format given any XBRL taxonomy.

The journey included rendering a complete IFRS financial report of a Singapore company, the Deloitte model IFRS financial report, modeling the some 28 business reporting patterns I had pulled from those and other such financial statements, modeling the 29 USFRTF patterns document patternsused to understand how to create the US GAAP Taxonomy, re-modeling the USFRTF patterns into XBRLS business use casesin order to overcome issues discovered with the USFRTF patterns. Each of these contains a rendering, and each of the renderings was generally created by hand coding an XSLT style sheet.

I have one final iteration of these business use cases to create. I want to model the business use cases I have been collecting (really financial reporting use cases) using the Business Reporting Logical Model. I have created one use case already, the "Simple Hierarchy" which you can see below.  The others will follow.

The difference is that I will not code these renderings by hand, they will be 100% automated. I already have the process in place, it works, as can be seen from the renderings below.

How do you do this?

The following things are needed to automate renderings and generate something useable by humans:

1. You have to have a good information model, i.e. a good XBRL taxonomy. It has to be consistent. That is the starting point.  If the model is inconsistent or fundamentally broken, you will never achieve your result.
2. Your XBRL processor has to ouput two consistent info sets.  In the Business Reporting Logical Model the two sets are the Fact Groups and the Measure Relations.  (See the link above to understand this.
3. The semantics of the XBRL taxonomies need to be aligned.

Note that the first two have huge benefits, even if your semantics are not aligned. As long as the XBRL taxonomy is internally consistent, any XBRL instance can be reduced down to these two fundamental pieces: fact group and measure relations as they are called in the Business Reporting Logical Model.  You can call them anything you want, but you will need them.  XBRL Cloud, who helped by generating these in its format call them fact tables (here is a human readable version) and a logical model.

Again, let me repeat. 1 and 2 above is all you need for one taxonomy to work. To have interoperable taxonomies you need number 3.  That is provided by the Business Reporting Logical Model: aligned semantics.

Two Messages

There are two messages here.

First, XBRL already HAS a logical model, but most people cannot see it. This is shown by the fact table created by XBRL Cloud, or at least you can get a glimpse of that model.  Into that model will fit items, tuples, XBRL dimensions, typed dimensions, custom created segment and scenario metadata, etc.  This is an epiphany for me, I never really realized this. This is good because at a technical level, this provides very substantial leverage.

The second message is that there has to be some mapping between the XBRL syntax used and the semantics expressed. If this is achieved you get leverage across taxonomies and business users can make use of the functionality of these very technical tools without the need for help from the IT department.

The bottom line is this: I had always thought that XBRL's flexibility was the real problem. That is not the problem. The problem is the inconsistent use of semantics within and across XBRL taxonomies.  This is generally unconscious by most of those who create XBRL taxonomies because they tend to not understand how XBRL works.

My Automated Renderings

Here are the automated renderings I was able to generate. I will have more information later, there is a lot of stuff going through my mind as a result of going through this exercise.

The really good news is that teaspoon enabled my escape from the XBRL prison I have found myself in for the past 10 years, literally.  I am really seeing some things in a very new light.  More to come, stay tuned. I see some very significant positive implications.

Here are my renderings. Notice that this is a number of different XBRL taxonomies, each complying with the Business Reporting Logical Model:

Business Reporting Metapatterns (basic components of the business use cases):

• Sales Analysis, Summary:
• Sales Analysis, by Business Segment:
• Sales Analysis, by Geographic Area:
• Accounting Policies:
• Property, Plant and Equipment; by Component:
• Roll Forward of Land: (This rendering is not really acceptable, but it is readable. A better rendering algorythm and format is needed for this type of information model. I know what it should look like, just have not done the programming yet.)
• Director's Compensation:

State Fact Book:

• Population Trends:
• General Information for Period:
• General Information at Point in Time:
• Financial Information, by State:
• Financial Information, by State, Alternative Aggregation of Expenses:

Business Reporting Use Cases: (This is only the first of 28 business use cases which I will eventually create)

• Simple Hierarchy:

Transaction Use Cases: (This is a prototype I built for someone else which uses their dimensions but builds upon the Business Reporting Logical Model.)

• Demo Transaction: (Note that this had two typed measures)