Digital Financial Reporting

I mentioned that I was updating the business use cases or patterns that I had been nurturing along over the years in another blog post.

I am making more progress and am up to 20 business use cases and have added a bunch of new features.  In particular check out:

• The additional use cases added.
• A landing page for each pattern, here is one example.
• Something to help you find the business use case you are looking for.
• An index page which puts everything together.
• A JPEG image for each business use case (see the landing page).
• Creative Commons licences in key areas to make it clear all this is there for others to make use of as they see fit.

Thanks to all those who have sent ideas and have made me aware of errors so that I can correct them.

I have created an updated set of metapatterns, business use cases (i.e. patterns), comprehensive example, and basic example of using XBRL. I have nurtured these examples over the years and have not adjusted them to comply with the Business Reporting Logical Model created by the XBRL International's Taxonomy Architecture (TA) working group, of which I am a member.  These examples are constructed to help come up with that Business Reporting Logical Model and to prove that model.

You can find this information here in various stages of completion. If anyone has ideas on things they might like to see, please contact me directly and I will see what I can do to add what you feel you might need if it makes sense.

Creating these ultra-high quality (my opinion, I can back it up) examples has been a long process. Over the years I have had a lot of help from a lot of people. While I created these examples and take full responsibility for any errors (although I have validated each of these using three different XBRL processors), I would like to thank those who have helped in the past, these could not exist without their help. At this stage, I would particularly like to thank Herman Fisher and Frederic Chapus, both of UBmatrix, for their help with XBRL Formulas. I would also like to thank Cliff Binstock of XBRL Cloud for his help in generating his fact tables and getting those converted to the Business Reporting Logical Model. I would also like to thank those who are members of the XBRL International Taxonomy Architecture working group for their efforts to create and drum up support for this work. (We still need more members.)

• Metapatterns: Basic building blocks from which the Business Use Cases were built. All of the business use cases can be distilled down to these metapatterns. (Complete.)
• Business Use Cases: Follow the metapatterns. Contributed to figuring out what the metapatterns were. (At this point I have 11 of about 30 business use cases completed.)
• Basic Example: Takes the metapatterns and puts them all into one basic XBRL taxonomy which is quite simple, but shows how the metapatterns relate to one another. Tests the relations between the metapatterns. (Complete except for detailed documentation.)
• Comprehensive Example: Puts each of the business use cases into one XBRL taxonomy and XBRL instance, testing the interrelation of the business use cases.  Also, intended to look like a financial report; but not as complex as a real financial report. (Still have a ways to go on this, I want to finish the business use cases first.)

Keep checking back if you are interested in this sort of thing.  XBRL is not going away any time soon. While this information is quite detailed, I contend that it is worth diving in. Investing in understanding these details pays dividends in many different ways. Also, again, feedback is welcomed. Good ideas to make it even easier to use in particular.

If you are familiar with XBRLS, this new set of examples is intended to replace XBRLS.  Use this stuff instead.

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.