Digital Financial Reporting

The US GAAP Taxonomy Architecture (and the current draft) has a term called a Compact Pattern Declaration (CPD).

Section 1.3 (Logical Model) of the US GAAP Taxonomy Architecture states:

Disciplined Extensions– The architecture internally enforces design rules to ensure that the base taxonomy from which others will need to extend is internally consistent. It is beyond the scope of the architecture to create a formal expression of extension rules to facilitate "disciplined" or "channeled" or "managed" extensions within systems that use it. We encourage systems that make use of the architecture to build such formal expressions for use within their systems. The Compact Patterns Declarations (CPD) is an example of such formalized expressions for the purpose of managing extension by filers.

Section 3.4 (Consistency and Comparability) of the US GAAP Taxonomy Architecture states (the emphasis is mine):

Systems which implement version 1.0 are expected to provide mechanisms for providing discipline around the extension of the base taxonomies. One example of providing such discipline or "channeling" or "management" of extensions is the compact pattern declaration (CPD). The CPD is a formal XML representation of a pattern [PATTERNS] that allows software to help a user follow exactly the same pattern and rules that were used to construct version 1.0 itself.

The US GAAP Taxonomy Architecture refers to two documents above and in Section 7 (References) in the architecture: UGT Compact Patterns Declarations (CPD) Module and [Patterns] or the UGT Patterns Guide (also called the USFRTF Patterns Guide).  These documents explain the patterns within the US GAAP Taxonomy.

There are two other places which show the sorts of things systems which implement the US GAAP Taxonomy are expected to do.  Section 4.5 of the US GAAP Taxonomy Architecture, Implementation of Tables, explains the [Table] is constructed within the US GAAP Taxonomy and how systems which use the US GAAP Taxonomy are expected to extend the taxonomy, such as SEC XBRL filings.

Another place to see how this can be implemented is by what XBRL Cloud.  You can see these rules here on this page and you can see the validation of these rules, as suggested by the US GAAP Taxonomy Architecture, here on XBRL Cloud's EDGAR Dashboard.  XBRL Cloud calls this an information model, rather than a Compact Pattern Declaration.  But it is the same thing.

The Business Reporting Logical Model also uses the term information model.  That logical model was basically created using ideas first created by the architects of the US GAAP Taxonomy. Those ideas were expanded on by the ITA Interoperable Taxonomy Architecture Group which was made up of the US SEC, IASCF, Japan FSA, and European Commission.

For years I had worked to build sample XBRL taxonomies and XBRL instances, I called these "patterns". You can see the history of that work here. I ultimately realized, partly from participation on the US GAAP Taxonomy Architecture Working Group, of which I was a member, that the patterns needed to be further condensed, this is what the Compact Pattern Declarations which expressed an information model were.  Now I refer to these as meta patterns.

For years I had been making a mistake about how I looked at those patterns or meta patterns and the information models they expressed. I realized this mistake when the FINREP taxonomy released their taxonomy without a presentation linkbase.

Business information is not random, it has patterns. There is not an infinite number of patterns within business information, there is some fininte amount. Here are some patterns which are hard to dispute, most of these are instantiated within the US GAAP Taxonomy:

• Hierarchy: A Hierarchy is an information model where there are relations between facts but the relations do not involve computations.  For example, accounting policies is a Hierarchy.
• Roll Up: A Roll Up is an information model which expresses relations where there is a simple computation between concepts. A Roll Up relation is basically A = B + C + n; where "n" is any number of concepts.
• Roll Forward: A Roll Forward is an information model which expresses a relation where a BASE (beginning + additions - subtractions = ending) type of relation exists.  Basically, a Roll Forward is a reconciliation between two instants in time. An example of a Roll Forward is the cash flow statement or a movement analysis for property, plant and equipment.
• Adjustment: An Adjustment is an information model which is similar to a Roll Forward in that it is a reconciliation; however the dimension or axis which is moving in the relation is the financial report's report date. An example of an Adjustment is the reconciliation of an originally stated balance to a restated balance for an accounting prior period adjustment.
• Variance: A Variance is an information model which is a computation between two different reporting scenarios such as actual and budget.  For example, the difference between the actual and budgeted values for the concept Sales.
• Other Relation: An Other Relations is an information model and is what amounts to a Hierarchy with business rules attached to the concept within the Hierarchy. An example would be the computation of weighted average common shares and earnings per share. These are computations too complicated for XBRL calculations to handle, but they are computations which exist.

The point here is that it is not XBRL which all of a sudden introduced the ideas of the information model.  Information models have always existed but we, as humans, understood what those were and we never really communicated at that level; it is pretty basic and we business users get those relations. But computers are dumb.  We need to break down business reporting so that we can explain the moving pieces to a computer application.  That is what meta patterns and an information model does.

The US GAAP Taxonomy and the filers who use the US GAAP Taxonomy for SEC XBRL filings don't have different information models for "Roll Up" or "Roll Forward", or whatever.  They are the same.  So, the US GAAP Taxonomy and the SEC filers who extend that taxonomy should be using the same information models.

Finally, the information model is not defined by the XBRL presentation linkbase, it is explained by the model itself, what the XBRL looks like.  A computer application can figure this out.  You can help a human understand that information model by articulating it within the XBRL presentation linkbase, like the US GAAP Taxonomy does, for example recall section 4.5 Implementation of Tables as discussed above.  But if you do express it in the presentation linkbase, you need to keep it consistent with the other underlying XBRL which really is what describes the real information model.  Eventually, perhaps the US GAAP Taxonomy will do like FINREP and not even provide a presentation linkbase because a computer can auto generate it based on the underlying information model.  But today, the US GAAP Taxonomy and the SEC require the presentation linkbase, therefore you need to keep it consistent with the underlying XBRL information model which is used to express your business information.

OK, so maybe I am a slow learner.  

The FINREP taxonomy got me thinking about something.  Someone asked the question "is there a presentation linkbase which can help business users view the taxonomy." At first I was appalled that someone would publish a taxonomy without a set of presentation relations.  How could you possibly read the taxonomy without the presentation relations.

Auto-generation of definition linkbase

I started to think about this further and thought, "Well, can't one simply generate a useful set of presentation relations from the definition linkbase which is provided?"  The reason I thought this is what when we created the US GAAP Taxonomy (I was part of the team which created that) we auto-generated the definition linkbase from the presentation linkbase rather than create both by manually.

If you look at the US GAAP Taxonomy presentation linkbases (here is one) you can see the metadata in the labels such as the "[Table]" and "[Axis]" and "[Line Items]" things tacked on to the end of the labels.  Also how the relationships are organized explains things about the information model.  The US GAAP Taxonomy Architecture explains these things which are tacked on to the labels and how the relations are organized (see section 4.5).  This approach to "documenting" the relations (called "styles" in the US GAAP Taxonomy Architecture) was developed to help people see these relationships more clearly.

So basically a careful organization of things in the presentation linkbase and validation helps to make sure you get this correct can allow you to auto-generate the definition linkbase from the presentation linkbase.  The US GAAP Taxonomy is pretty much guaranteed to have a 100% consistent relation between the presentation and the definition linkbase because the presentation needs to be correct in order to get the definition linkbase generated correctly.

Changing perspective by 180 degrees

When I really started thinking about this I realized that the definition linkbase metadata was very strict and enforced by XBRL.  When you expressed the relations information in the presentation linkbase (like the US GAAP Taxonomy) you had to build validation to enforce the relations.  Then I thought about the calculation linkbase.  That has metadata also.  There is also metadata about computation relations in the XBRL Formula linkbase for a properly constructed taxonomy, meaning that the computation relations in a roll forward (movement analysis) is needed.

This is when I had an epiphany!  The first part of the epiphany was that one could generate a presentation linkbase which looks like the US GAAP Taxonomy from metadata contained in the definition linkbase, the calculation linkbase, and XBRL Formula information which expressed computation relations which cannot be expressed in the calculation relations.  Not only could you auto-generate a US GAAP type presentation relations; you could generate ANY presentation "scheme" you desired.  All the presentation relations are is one organization of the real "information model".  The presentation relations themselves is NOT the information model, the metadata is the information model.  Basically, the mistake I was making was to think that the presentation relations WERE the information model!

Presentation can be created "virtually"

Taxonomies don't need a "presentation linkbase".  What they need is a way for business users can view the taxonomy.  What that is, it seems to me, is an organization of the metadata of the taxonomy in some useful form.  I can read those "tree view" interpretations, I have had to learn how because that is all that exists in today's software.  The typical business users will never be able to relate to those tree views, nor should they have to.  For example, think of the upside down calculation relations shown by most taxonomy tools and even by XBRL calculation validation reports.  Why can't these look more like the things accountants use today with the double underscore for the grand total at the bottom of the report, single underscores for sub totals, etc.

Well, it can.

The whole notion of "editing the presentation linkbase" and "editing the calculation linkbase" and "editing the definition linkbase" is a misdirection caused by thinking too much from an XBRL prespective and not enough from a business report perspective.  This is a mistake.

Is an information model important?  Absolutley!  Just like a database schema is important and a good data model is important, you do need to understand the data and follow good data modeling practices. But some contrived representation is not important, you can contrive any number of different ways of looking at the information model.  A tree view is only one.  The presentation linkbase is another, which can be expressed as a tree view.  But the information model and viewing the informtion model are two different things.

What business users need is more creative interfaces from software vendors.  To get that we need more consistent and well structured taxonomies.

Some possible issues

I can see a couple of possible issues.  The weights in calculations don't seem to be an issue, but potentially could be an issue.  It seems to me this would be more of a presentational issue, not an issue relating to a correct interpretation of the taxonomy metadata.  The hierarchies of the presentation linkbase might be an issue; although there are no restrictions of hierarchies in the definition linkbase.  Creating the XBRL Formulas for the roll forwards might be an issue, but I think not.  All that really needs to be expressed in a software application interface is the fact that there is a roll forward relationship between two concepts.  The XBRL Formula piece can be, again, auto-generated.

Bottom line

Business user, you care about this.  This is all about making XBRL easier to understand and use. Wouldn't that be nice?  Ask software vendors why they are forcing you interact with the XBRL syntax.

The XBRL filings of SEC companies provides insight into why an information model is important. Consider this one presentation linkbase from the US GAAP Taxonomy: Statement of Income. If you click on that link and look at the page, you will notice that the presentation network of the income statement starts off something like this:

Income Statement [Abstract]             {ID1}

Statement [Table]                       {ID2}

Statement, Scenario [Axis]  {ID3}

Statement [Line Items]       {ID5}

You can click on the page and get to that presentation arrangement by collapsing or expanding the line items of that network. The IDs on the right just help you see which nodes I want you to focus on.

Why is the income statement organized in this manner, as a [Table]?  Well, there are two primary reasons reasons.  The first reason is that an income statement have a number of dimensions, for example it could be actual or budgeted, it could be for a consolidated group or for a subsidiary, or there are other breakdowns or "dimensions" which could be provided.  Those dimensions can be expressed using the "Statement, Scenario [Axis]" and the facts for which values are expressed are provided within the "Statement [Line Items]".  The second reason this [Table] is organized in this manner is because the US GAAP Taxonomy Architecture says that all [Table]s are to be organized in this manner (see the US GAAP Taxonomy Architecture, section 4.5 Implementation of Tables, page 34).

In fact, it is not that just this one [Table] is organized in this manner, ALL [Table]s in the US GAAP Taxonomy are organized in this manner.

However, look at the following sample of XBRL filings to the SEC:

http://www.xbrlsite.com/demos/console/TreeView-0001047469-09-007400.html#ID1([Table], [Axis], and [Line Items] used just like US GAAP Taxonomy)

http://www.xbrlsite.com/demos/console/TreeView-0000950123-09-030335.html#ID505 ([Table], [Axis], and [Line Items] used just like US GAAP Taxonomy)

http://www.xbrlsite.com/demos/console/TreeView-0000950123-09-029921.html(Table on balance sheet just like US GAAP Taxonomy, but no Axis on the income statement)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-046329.html#ID1 (No table, no axis, no line items)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-048234.html#ID50 (No table, no axis, does have line items, but not modeled using [Line Items] marker)

http://www.xbrlsite.com/demos/console/TreeView-0001310243-09-000085.html#ID1 (Table, line items, but no axis)

http://www.xbrlsite.com/demos/console/TreeView-0000004904-09-000117.html#ID1 (No table at all)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-047977.html#ID1 (Line items, but no table or axis)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-046313.html (No table, no axis, no line items)

http://www.xbrlsite.com/demos/console/TreeView-0000037748-09-000037.html (Table and line items, but no axis)

Why the inconsistency between the filings?  Why the inconsistency between the filings and the US GAAP Taxonomy?  The reason is that no "model" is being enforced as to how, in this case SEC filers, create their extension taxonomies.  There is no "information model" or manner specified to construct this component of the XBRL taxonomy and no automated validation to ensure that the model is being followed.

An articulated information model achieves many things, not just consistency within an XBRL taxonomy or between a base XBRL taxonomy such as the US GAAP Taxonomy and those who extend that taxonomy.

• The first benefit is that if the information model is articulated (specified) then automated validation processes can be created in order to help those creating extension taxonomies to do so in accordance with the intentions of the creators of the taxonomy which is being extended.
• The second benefit is that because of the consistency, rendering of the XBRL instance information is easier because the XBRL taxonomy is more consistent (both the base taxonomy such as the US GAAP Taxonomy and the extension taxonomies created by in this case SEC filers).
• The third benefit is that the entire process of extending can be vastly easier for users of the taxonomy.  The automated validation is only the first step.  Literally, software applications can be built in a totally different manner BECAUSE OF THE KNOWN CONSISTENCY!  Business users tend to miss this point.  Literally, the entire notion of a [Table] can be hidden from the user because software applications can be constructed to leverage the consistency, hiding the complexity of working with an XBRL taxonomy from the user.

The third benefit about is by far the most important, but it is only achieved if you also have the first two: the consistency of an articulated information model.  This points out another challenge working with the US GAAP Taxonomy: when is something a [Table]?  This problem can be easily overcome by doing what the creators of the COREP taxonomy did: make EVERYTHING a [Table].  Now, the COREP taxonomy does not call them [Table]s, they use the XBRL term hypercube. But, everything within the COREP taxonomy is constructed in one very easly to explain and leverage information model.

BOTTOM LINE

The bottom line here is this. If you articulate an information model, meaning a formal set of rules as to how that taxonomy is to be constructed, then those rules can be used to ensure that your taxonomy was created consistently and to ensure that those extending your taxonomy do so consistently. The consistency can be taken even further making using the taxonomy significantly easier if every area of the taxonomy is created in the same manner, in this case we are using [Table]s but actually [Table]s are a way to implement the multidimensional model.  If, say, every component of the taxonomy works in a similar manner, that similarity can be leveraged by software creators to make the experience of using that taxonomy easier, significantly easier in many cases.

There are a number of other entries on this blog which discuss the notion of an information model.  Also, you can read more about this in my book which will be available next month, XBRL for Dummies.