Digital Financial Reporting

Web Filingshas released a free tool for having a look at XBRL taxonomies used for SEC XBRL filings.  You can find the tool here.

Here are two screen shots of the tool in action. I am using it to compare how different filers build their company extension taxonomies.

• Comparison of balance sheets 1: This PNG shows a comparison of the concept "Assets" on the balance sheets of six SEC XBRL filers.  Notice how each of the six companies used the same concept to organize their balance sheet.
• Comparison of balance sheets 2: This PNG shows a comparison of the [Axis] used on the balance sheet for six SEC XBRL filers. All six used the Legal Entity [Axis] on the balance sheet.

There are other things you can do with the tool such as browse the released version of the US GAAP Taxonomy and search for concepts.

Nice work Web Filings!  I look forward to other tools like this becoming available to help business users get the most out of what XBRL has to offer.  Imagine being able to compare the actual filings themselves in this manner.

If you become aware of a good tool, please make me aware of it.

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.

There are a number of ambiguities which you will need to overcome in your SEC XBRL filings.  Overcoming these ambiguities can help your renderings look better in the SEC XBRL viewer, enhance comparability of your reported information, help you improve the integrity of the information you report.

Further, if software vendors take advantage of these ideas they can implement easier to use software because the business users don't have to deal with these issues because the applications deal with the ambiguities for you behind the scenes.

Here is a list of the biggest issues which cause ambiguity and how to overcome the issue: 

• Lack of clarity of extended link and hypercube semantics.  What is the business semantics of an XBRL extended link? How about the business semantics of an XBRL Dimensions hypercube? What is the relationship between an extended link and XBRL Dimensions hypercube? There are no real rules articulated in the US GAAP Taxonomy as to exactly when you need to use an extended link and where, when you need to use a hypercube and where. How to overcome. The safest way to overcome this issue is to create one hypercube per extended link and to always use hypercubes.  Basically, you will end up with a lot of small consistent pieces.  Name and label the extended links and hypercubes so that they are the same or very similar. Another reason this is good is that you can get the most predicable representation of your information in the SEC XBRL viewer.
• Inconsistent information models. The concepts of an XBRL taxonomy are articulated in what amounts to a tree view in most software applications.  For example, the US GAAP Taxonomy has [Table]s, [Roll Forward]s, [Axis], [Line Items], and other pieces of the XBRL taxonomy organized in a specific manner.  There are other things in the taxonomy which are organized but not explicitly identified such as roll ups (calculations) and general hierarchies. There are two things which provide information about this organization which I refer to as the information model: the US GAAP Taxonomy Architecture document and the US GAAP Taxonomy itself. For example, section 4.5 of the document discusses how to build [Table]s.  Or, looking at the US GAAP Taxonomy can provide clues. The US GAAP Taxonomy itself and the SEC don't require that the information models be followed.  How to overcome. The best way to overcome this issue is to simply follow the information models consistently within your extension taxonomy.
• Inconsistency between presentation, calculation, and definition linkbases.  There are three different hierarchies of concepts (information models) that you can create. What does it mean if you have inconsistencies between your presentation, calculation, and definition linkbases? If they are inconsistent, which one is correct?  For example, if you have a concept in your presentation relations but that does not exist but SHOULD exist in the calculation relations; how should determine which one is correct? How to overcome. The best way to overcome this issue is to make sure your presentation, calculation, and definition linkbases are consistent.  Clearly this does not mean that they will look the same, rather it means that if you build your presentation information model in a certain way then you can predict what the calculations and definition relations look like.
• Extension points. What areas of the US GAAP Taxonomy are you allowed to extend and what areas are best not extended? For example, certain higher level areas of the US GAAP Taxonomy probably should not be changed.  Lower levels of hierarchies are more likely to be appropriately modified.  How do you know the difference?  How to overcome. When you are making changes to higher levels in the US GAAP Taxonomy be able to explain why you are making the change.  If you can rationalize the change to yourself, you can probably rationalize it to others. If you cannot, you probably have not thought through the modification throughly enough.
• Extending as an concept or a dimension of a concept. There are two ways that new information can be articulated within the US GAAP Taxonomy: create a new concept or create a new [Member]. The US GAAP Taxonomy does both, in fact they do both for exactly the same information. Go to the US GAAP Taxonomy and look up the subclasses of Property, Plant and Equipment (Land, Buildings, Furniture, etc.).  You will find the exact same information articulated as concepts and as [Members] within an [Axis] of those concepts.  Why would you need both?  How to overcome. First off, if you don't understand what I am talking about here, you need to learn.  Being unconscious of this issue is a good recipe for making a mistake. After you understand the issue, pick one approach and stick with it consistently.
• Information integrity of numeric values.  Your numbers need to add up correctly.  All of them, whether the US GAAP Taxonomy contains the relations or not. XBRL calculations cannot achieve this result.  Roll forwards, dimensional aggregations, and other such computations cannot be verified using XBRL calculations.  Not checking the numeric relations will lead to errors.  How to overcome. Every numeric value which has a relation with another numeric value should be checked in some manner.  One way to do this is using XBRL Formulas. But the SEC does not allow you to submit XBRL Formulas with your SEC XBRL filing.  No problem, create the XBRL Formulas to verify you XBRL instance and don't submit it to the SEC. You will need these XBRL Formulas to also be sure your current period numbers tie to your prior period filing.  Using a calculator and a human to do this is both too costly and insufficient and will lead to errors. If your information model is consistent, most of the XBRL Formulas can be auto-generated by software.

Following these recommendations can lead to better renderings of filed information and better comparability both between filing periods and with other public companies. Further, if software vendors implement ways to hide these issues from users, it can make the software and dealing with XBRL significantly easier.