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)

People might not get this, but this rendering of XBRL instance information (I am calling this a Level 1 Fact Group Rendering) is actually quite interesting from a number of perspectives.  I am not going to cover all the perspectives, just four. I hope I can make my points. I appologize for the colors, an artist I am not.

Fact Groups or Fact Tables

The rendering above shows a flat list of facts which are from one XBRL instance. There are several different fact groups.  Each fact group has different Measures (or some people call these dimensions or axis or aspects). Basically, each fact group (some people call these fact tables) is a fully complete table.  The different fact groups have different columns because each column contains the Measures appropriate for that specific fact group.

These fact groups are similar to business intelligence or online analytical processing (OLAP) "cubes".  XBRL uses the term hypercube rather than cube because a cube only has 3 dimensions where a hypercube can have any number of dimensions.

While it is true that the rendering is not all that great to use, it is certainly far better than looking at the XML of an XBRL instance. What if there were some default style sheet which rendered all XBRL as fact tables, in a consistent "more readable" format.  Would that be a good thing?  Maybe.  It could even be all you need for many different types of XBRL based information.  See the discussion about CSV files below.  Others need more rendering.  See the discussion about "Measure/Member Relations" below.

It seems to me that every XBRL instance can be expressed as a "more human readable fact table".  This includes XBRL which has no XBRL Dimensions (the context information is the dimensions), XBRL which has XBRL Dimensions (either explicit or typed members) and even tuples (the tuple is the Measure, the key concept is the Member collection of that Measure, and the other concepts are of the Measure-Concepts. I won't bore you with further details, but even non-XBRL dimensions can be expressed in this manner (i.e. the stuff you can put into the <segment> and <scenario> portion of an XBRL context.

Metadata "Levels"

You may want to go back and have a quick look at the graphic on this blog post. As I explain, the closer you are to the top of this inverted pyramid, the better the comparability you will experience.  Go back to the fact group rendering. Look at the namespaces table under "Report". There are five namespaces in that namespace table. Each of the namespaces corresponds to that diagram from the blog post (except I don't have a namespace for Regulator).

The point here is that who issues the metadata matters quite a bit. Each piece of metadata in the fact tables is explicitly defined as to who is providing the metadata except for two [Measure] values or these are sometimes referred to as "Members": brm:ReportingEntityMeasure and brm:CalendarTimeMeasure.  Basically, to reiterate and show more clearly that the blog post above, the more broadly used the metadata (the {Measure]s and the [Member]s) the higher the level of comparability which can be created.

Data as Contrast to Information

Take a look at this text file. For this you may want to go back and review this document which I referred to in another blog post. If you look at the text file you will probably not a number of things. First, it looks like a CSV (comma separated values) file.  Business people use these all the time to exchange information.  CSV files are easily loaded into spreadsheet applications such as Excel.

Compare that text file with the information in the fact group "[Network] gaap: http://xasb.org/gaap/SalesAnalysisByGeographicArea". Notice two things. First, the fact group rendering is way more explicit in describing the values than the text file.  Some of the context is missing from the text file, whereas the fact group is rather explicit.  Not everything is explicit.  You don't now if the information is audited or unaudited. You don't know if the information is actual or budgeted.

One point here is that information needs to be made as explicit as you might need it to be. It is up to the creators of the XBRL taxonomy and the consumer of the XBRL instance figure this out.  The other point is that XBRL can do everything that CSV can, but better.

Measure/Member Relations

Notice on the fact group rendering that the fact groups contain lists of facts.  There are no relations between the facts. Now take a look at this page which does show the relations between the Members used within the fact groups. You don't have to use them, but XBRL provides a way to document these or other relations.  CSV files (like above) don't have these relations expressed, that is one of the drawbacks of the CSV or table type formats.  They are flat.

You can apply the Measure/Member Relations and create far more useful renderings as is shown in the straw man implementation of the business reporting logical model.

This blog post briefly explains the notion of the intelligent business document. See this PDF for more details. For even more details, follow the links in that PDF to the details in the straw man implementation of the Business Reporting Logical Model.

I wish I could take credit for the term intelligent business document.  But I can't. Like is said, "Good artists borrow, great artists steal." I have used many different terms to describe this notion: neutral format table, interactive information hypercube, pivot table, data cube, etc. This has evolve since about 2006 or 2007.

So what is an intelligent business document? It is:

• Something that business users can create, without the help of the IT department, so that they can share business information with other business users without having to rekey the information.
• It has unambiguous business semantics.  As such, it can reliably feed information into and generate outputs from automated processes which can then be fed into other automated processes.
• It is 100% compliant with the XBRL syntax. But it can be serialized into any syntax because the semantics are unambiguous.
• It leverages something like the Business Reporting Logical Model, that is what enables the unambiguous business semantics.
• It leverages the flexibility of the multidimensional model.
• It makes is easy for the average business user to use.
• It is a global standard protocol, not a proprietary solution. It allows one business system to communicate with another business system effectively. (Keep in mind bullet point one; a business person achieving this integration without the help of the IT department.)
• It is dynamic. It is "interactive data" to use the term coined by the US SEC.  I prefer "interactive information" because it is really about information, not about data. You can pivot the information to suit your needs like an Excel pivot table or a Business Intelligence application allows you to pivot information.
• It could just be a boring form, but it is a form based on a global standard that every business system (literally, every business system) can both generate and consume.
• It will save business users time, money, and it will make their processes more effective and efficient.  It will improve the quality of their business information because information integrity is enhanced.
• It will allow drill down from top to bottom of an information "stack".
• It will provide an audit trail as information moves from point to point within that information stack.
• It works for financial reports, which are a form of business report. But non-financial information can also be expressed within an intelligent business document.

Take a look at the PDF which explains this in further detail.

Take a look at the straw man implementation which shows this is possible. I realize that is a lot of information, but it will be worth your while.

That is my vision for what XBRL could become.  You have a better vision?