Digital Financial Reporting

I learned something interesting that had never really occurred to be before as a result of fiddling around with trying to render XBRL.

This has to do with constraining fact values and is explained in more detail here in this document. An understanding of this helps you create better XBRL taxonomies because you are conscious of something which you may otherwise not realize.

In summary, XBRL has two mechanisms for filtering fact values you are working with and these mechanisms work differently:

• XBRL networks
• XBRL Dimensions hypercubes

This is not to say that one mechanism is better than another, but rather to point out that the mechanisms are different.

You seem to get less ambiguity, more precision and generally better control using XBRL Dimensions hypercubes as is explained in that document.  This is because you explicitly articulate the dimensions and the possible dimension values which are allowed for a hypercube when you define the hypercube.

By contrast, an XBRL network (i.e. an extended link of a particular role) only constrains the primary item (to use an XBRL Dimensions term) or the concept which can appear within a network.

Neither of these mechanisms can constrain the entity identifier or period which you can use within an XBRL instance.  This has some pros and it has some cons which you need to be aware of.

I could be wrong here, but the way I look at it is that if you use XBRL Dimensions, you always have two "typed members" (as XBRL Dimensions calls, sometimes referred to as implicit dimensions): entity identifier and period.  I say this because neither the entity identifier nor the period have a domain like explicit dimensions, nor do they have a hierarchy and they can be "open lists" of possible values for those dimensions.  Like I said, I could be wrong about this but they do seem to have many similarities to XBRL Dimensions typed members.

Yesterday I had a posting to my blog Consistent Semantics Leads to Automated Renderings Across XBRL Taxonomies which showed 14 different renderings of XBRL instance information, all created from only XBRL instance and XBRL taxonomy information.

Here is a document which walks you trough how the renderings are actually created. This document can be quite helpful in both rendering XBRL instance information and understanding were you might be creating rendering problems within your XBRL taxonomy.

I broke the process down into two primary steps:

1. Going from an XBRL instance to Info Sets.
2. Going from the Info Sets to the rendering.

I am not going to cover step 1 here.  That is extremely complex, requires an XBRL processor, and any XBRL processor can generate these Info Sets or something like them with the required information. Proof of that is that one XBRL processor that I know about already does.

I am going over going from the Info Sets to the actual renderings.  I show you how that is done, you can see how it works, and more people will be able to relate to this becuase it does not even use XML but rather I use a relational database, in my case Microsoft Access.

There is important information in the "Bottom Line" of that document, this is helpful to those creating XBRL taxonomies.  I summarize that information here:

• When you create an XBRL taxonomy it is important to articulate the function of an XBRL network, an XBRL Dimensions hypercube, and the relation between XBRL networks and hypercubes.  Not doing so causes ambiguity to those extending the XBRL taxonomy.
• Inconsistencies between XBRL presentation, calculation, and definition linkbases causes serious problems when one tries to use the information.
• Presentation relations are not necessary to articulate an information model, the information model can be figured out by looking at the information within the XBRL taxonomy.  Therefore, it is easy to test taxonomy extensions to see if an information model is being followed.

Finally, just as the FINREP taxonomy helped me to see that you don't need a presentation linkbase to understand a taxonomy's information model.  It can help, but software can do a better job of detecting a good or bad information model.  Likewise, you don't need a bunch of stuff thrown into a taxonomy to paint a logical model.  XBRL has a logical model.  I did not use to think this, but this exercise helped me to realize this.  While the little things I used to put into a presenation linkbase help a human see the information model and logical model, as long as the information model is logical and consistent, the data being pulled out will be usable.  If the information being pulled out of an XBRL instance is not logical and consistent, there is a strong possiblity that the underlying taxonomy is poorly created.  An XBRL taxonomy is basically a schema, similar to a relational database schema.

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)