Digital Financial Reporting

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.