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.

I have updated the documentation for the meta patterns, business use cases, and the document which contains everything together, Modeling Financial Information Using XBRL (DRAFT). These are the same documents which are provide here. Things are more built out, there are more cross references to the sample/example files, etc.  Still more to do, but this draft will stand for a while because I need to move on to other things for a bit.

Here is a summary of the business use cases which have been distilled down to the small set of meta patterns. One additional thing which I have done is to break down these business use cases into categories: an accounting use case, a variation of another use case, or an alternative technical approach. This is not perfect yet, but it is making it easier to talk about these use cases.

My next step is to map my meta patterns to the US GAAP Taxonomy and to create examples of SEC XBRL filing pieces for each of the business use cases. That will likely help people see the breaking the pieces of the US GAAP Taxonomy down into meta patterns makes the taxonomy easier to understand and that the meta patterns can be leveraged to help make working with these business use cases easier for business users. This will also help to create a more consistent US GAAP Taxonomy.

• BUC01 Simple Hierarchy. Accounting use case. One level hierarchy.  No calculation relations.
• BUC02 Hierarchy. Variation of Hierarchy. Multi-level nested hierarchy.
• BUC03 Simple Roll Up. Accounting use case. Computation where A + B + n = C. Simple roll up.  No nesting of calculations.
• BUC04 Nested Roll Up. Variation of Roll Up. Nesting one calculation inside another calculation.
• BUC05 Inverted Roll Up. Variation of Roll Up. Multi-level nested calculations.
• BUC06 Multiple Roll Ups. Variation of Roll Up. One concept calculated in more than one way forcing calculations to be separated by extended links.
• BUC07 Simple Roll Forward. Accounting use case. Computation where beginning balance + changes = ending balance. Simple roll forward analysis. Also known as movement analysis.
• BUC08 Complex Roll Forward. Variation of Roll Forward. Movement of more than one concept modelled using items.
• BUC09 Simple Compound Fact. Accounting use case. Concepts which make up a set which must go together. This is actually another pattern with at least one more measure (dimension).
• BUC10 Repeating Concept. Variation of Compound Fact. Simple compound concept which repeats.
• BUC11 Multiple Periods Compound Concept. Variation of Compound Fact. Simple compound concept which has more than one period disclosed within the compound concept.
• BUC12 Roll Forward in Compound Concept.  Variation of Roll Forward. Variation of Compound Fact. Roll Forward within a compound concept.
• BUC13 Nested Compound. Concept Variation of Compound Fact. Compound concept within another compound concept.
• BUC14 Reconciliation of Balance. Accounting use case. Reconciliation of one instant to another instant.  (This is NOT a roll forward as the reconciling items are instants, not durations, and the balance concepts are different concepts, not the same.)
• BUC15 Text Block. Accounting use case. Many Facts modelled as a block of text.
• BUC16 Restatement. Accounting use case. Restatement of income.
• BUC17 Reissue Report. Accounting use case. Reissuance of an entire report.
• BUC18 Reclassification. Accounting use case. Reclassification of prior balances on a report to conform to current period classifications.
• BUC19 Prose. Accounting use case. Information containing multiple paragraphs, tables, lists, etc. which must appear in a particular order to be meaningful.
• BUC20 General Comment. Accounting use case. Using XBRL Footnotes to express general comments. Shows the difference between using standard roles and custom roles.
• BUC21 Pivot Table. Accounting use case. One concept used in a number of axis.  Common for a segment breakdown.  Data is similar to a pivot table. Multiple business segments.
• BUC22 Reason Not Reported. Accounting use case. Explaining why a piece of information has not been reported.
• BUC23 Simple Roll Forward Using Measure. Alternate technical approach to Roll Forward. Simple movement analysis modelled by Barry Smith's approach.  (This is the approach the IFRS is pushing)
• BUC24 Complex Roll Forward Measure. Alternate technical approach to Roll Forward. Movement of more than one concept modelled using axis.
• BUC25 Escaped XHTML. Alternative technical approach to Text Block. Same as the Simple Compound Fact, but expressed as one table in HTML for better formatting control.
• BUC26 Using JSON. Alternative technical approach to Text Block. Same as the Simple Compound Fact, but expressing the compound fact using the JSON syntax.
• BUC27 Flow. Accounting use case. Shows the notion of flow within a business report and how the ordering or sequencing is important and can be achieved.
• BUC28 Other Relations. Accounting use case.  Other more complex computations not covered by Roll Up, Roll Forward, Adjustment, or Variance. Other relations, usually complex computations
• BUC29 Variance. Accounting use case. Variance between actual and budgeted.
• BUC30 Classes. Alternate technical approach to Roll Up. Shows the notion of class.  Compare and contrast this to the Simple Roll Up.
• BUC31 Add Members Without Extension. Alternate technical approach to creating Measures. Show how extension can be achieve without the need to extend an XBRL taxonomy.
• BUC34 Adjustment. Accounting use case. Adjustment of a balance between two report dates. Calendar time remains constant.
• BUC35 Grouped Report. Variation of Compound Fact. Fact Group which contains multiple Measures unique to the Fact Group.
• BUC99 Non Financial Information. Variation of Compound Fact. Non financial information can be expressed in XBRL as well as financial information.

Meta patterns are the key to making XBRL easier for business people.  This is an updated explanation of what meta patterns are and how they make XBRL easier.

Recall that you can grab sample XBRL instances and XBRL taxonomies of the meta patterns I have created here.

The US GAAP Taxonomy has meta patterns. [Table]s, [Roll Forward]s, and a few others are explicitly identified.  It has [Roll Up]s and [Hierarchy]s which are not explicitly itentified, but they do exist. Leveraging patterns like these is done all the time by information technology professionals. Soon, business reporting tools will leverage these meta patterns to make working with XBRL easier for business users.

I have a hypothesis that all business information can be reduced to three meta patterns. Or rather, perhaps this is not a hypothesis at all but rather an axiom or a postulate.  Either way, this is what I see.

Everything can be Expressed as a Hierarchy

Let's start with this: Everything can be expressed as a hierarchy. This has to be true for two reasons. First, that is all that an XBRL presentation linkbase is, parent-child hierarchies.  If it is not true that all business information cannot be expressed as a hierarchy, then something is missing from XBRL. Now, I am NOT saying that all information about business concepts can be expressed in the XBRL presentation relations.  What I am saying can pretty much be summed up in the second reason this must be true.  The second reason is that a hierarchy is nothing more than parent-child relations which can be used to express pretty much anything.  There are no relations really.  An set of XBRL presentation relations is a hierarchical list of "stuff" with no further meaning per XBRL than "parent-child" relation.

Roll Ups and Roll Forwards

OK, so everything can be expressed as a hierarchy.  But if you start looking in that hierarchy, patterns appear.  There are two clear patterns that I have seen in my 10 years of working with XBRL.  This is from intimate involvement in constructing the IFRS and US GAAP Taxonomy.  Here are the two patterns:

Roll up: A + B = C (this is what XBRL people generally call a "calculation")

Roll forward: Beginning Balance + Additions - Subtractions = Ending Balance (this is what XBRL people call a "movement" or a "roll forward", another term for this is "BASE")

These two terms are not XBRL terms.  If you look at business information you see these all the time. The term "BASE" for "beginning + additions - subtractions = ending" was learned in college in my auditing class.

So, these are definitely patterns as I see it and empirical evidence would prove this out should one bother to look (I have looked).

As such, I can comfortably say that I see three meta patterns:

• Hierarchy (everything except roll ups and roll forwards)
• Roll ups

• Roll forwards

What are NOT Meta Patterns

I started working on the idea of "patterns" in about 2002.  Patterns started out as on thing and evolved into something different as I learned about what patterns were in information technology circles (remember, I am a CPA, not an IT person).  My first set of patterns had about 20 business reporting use cases in it.  The second set, the USFRTF patterns, build on the first but increased the set to about 28.  During the process of creating these it was pointed out that these were not really patterns at all, but more use cases which used patterns, or better termed meta patterns to express the business use cases.

As a result, I reduced the set of 28 USFRTF patterns and the 20 others from my first set into what I thought were 5 XBRLS meta patterns.  These are: Schedule, Calculation, Movement, Record and Hierarchy.

However, several of these are not really patterns.

• Schedule is not a pattern.  What I build is really a hierarchy and shows the "schedule" structure which organizes the upper level of the meta patterns.  The schedule is somewhat of a container.
• Record is not a pattern.  A record (or also revered to as a set) is really some other pattern or patterns which repeat, some people thing of this as a "tuple".  But what is really going on is that it is some other pattern with one specific axis which people look at as repeating.  For example "Director" repeats because you can have more than one director.  But, like I said, this is really a hierarchy or a calculation (depending on what information you show) with an axis which is used to articulate the different directors.

That leaves:  hierarchy, calculation (really a roll up), and movement (better called roll forward).  This is consistent with my conclusion above.

There Has to be More than Three!

This is what most people say, "There simply has to be more than three."  Well, that is what I thought also.  I started with 20, built that up to 28, reduced it down to 5, and then again down to 3.  For years people have been coming to me saying "I found a new pattern" on taxonomy projects I have worked on.  Every time it turns out that they really have not discovered a new pattern, what they have discovered is that they don't understand the other patterns, usually because they are focused on "presentation" instead of modeling information.

Syntax

Then I realized that I may be making a mistake due to a number of conversations I was having with people. To cut to the just of it, I started to realize that maybe I did not even need "meta patterns".  What if I just defined the information in terms of business rules using XBRL Formulas?  That would consistently express relations, or at least most of them, everything other than hierarchies where there really is no relation.  I think that I realized that the way that I was creating the meta patterns within an XBRL taxonomy was just a "syntax".  XBRL Formulas is also just a syntax.

What we Really Need Appears to be a Grammar

Someone said this to me about six months ago I believe which is:  It is not about the meta patterns, it is about a grammar.  I did not see the difference, and I still don't think I see the difference between meta patterns and grammar.  But, I do see that you can, say, a roll up or a roll forward in a presentation linkbase and auto generate an XBRL Formulas to express the relations articulated in the meta pattern expressed in the presentation relations; or alternatively you could articulate the XBRL Formula and auto generate the presentation relations!  So, why do you even need the presentation relations to articulate the meta patterns???

Not Sure What I Really See Here

To be honest, I really don't understand exactly what I am seeing here.  I have no formal training in computer science.  But, what I do see is that I can articulate every business use case I have run across in financial reporting using three meta patterns:  Hierarchy, Roll up, Roll forward.

OK, so let's say I missed a few meta patterns.  For argument's sake let's say that I missed 50!  Some smart soul can go through what is expressed as hierarchy type relations and identify 50 new meta patterns!  Excellent, I say.  Now we have 53 meta patterns rather than some unknown set of inconsistent ways to create XBRL taxonomies.

What do you think about these observations?