Digital Financial Reporting

In about 2000 or so I began experimenting with XBRL, modeling typical business use cases in XBRL to see how it was done. I literally began collecting these use cases. Over the years I have created at least seven iterations of what got referred to as "patterns", but I now use the term metapatterns and business use cases.

My latest iteration of metapatterns and business use cases can help professionals during your journey to mastery of digital financial reporting, helping you to make proper use of XBRL. These metapatterns and patterns have come full cycle. Back in about 2007 we used these patterns to help understand how to best construct the US GAAP Taxonomy. Ultimately, I created a model or reference implementation of an SEC XBRL filing to understand how to properly express financial information using XBRL. I then took what I learned from creating the model/reference implementation, cycled back, and have reconstructed the metapatterns and business use cases in these current versions to reflect what I have learned.

There is one additional step these models require which is to recast the model/reference implementation following the metapatterns and business use cases. This is crucial because the model/reference implementation shows clearly how the different pieces of a digital financial report relate to one another. You cannot get this understanding from the metapatterns or business use cases to the extent necessary because they are generally isolated examples to keep them focused on specific areas.

Be aware that the metapatterns and business use cases assume that you have the appropriate understanding of fundamental information such as the multidimensional model, the US GAAP Taxonomy/SEC logical model, etc.  While one resource which contains all this fundamental background material does not yet exist, I have put together an organization of material in one location for your use which collectively has all these fundamentals, should you need that background.  You can find that information summarized here on my blog.

Stepping through this information in order is crucial; there are no short cuts. Trying to understand how to use XBRL properly but skipping steps is like trying to understand algebra without knowing how to count or basic mathematics. Mastering this material will be easier when XBRL software has matured and much of this information is absorbed within software applications which help you use these technologies correctly. But regretfully, that is not the state of XBRL software today. A good sign that you are missing fundamental understanding is frustration and confusion.

For professionals who are investing in their skill sets, mastery of XBRL will pay dividends as we move to the paradigm of digital financial reporting. Making this investment today is harder than it will be five years from now; but being on the leading edge of this change has its advantages.

An Integrator's Guide to Inline XBRL is a helpful resource for learning about and working with Inline XBRL. Included with this tutorial is a sample 10-K for Massive Dynamic company.

The folks at OpenFilinghave made a couple of very useful resources available for those who are serious about learning how to model business information using XBRL.

The first is a video which shows, in detail, an approach used by FINREP to modeling information. The video titled FINREP 2012 taxonomy and the Data Modeler - ExcelXbrlGen (Excel add in) is 1 hour and 26 minutes long, but there are some good nuggets of information. It is worth the time for those who are serious.

The second is the Excel add in discussed in the video, Data Modeler: ExcelXbrlGen (Excel add in). The Excel add in appears to be written in .Net, is open source, and is described as follows:

Developed in order to facilitate creation of taxonomies according to the draft Eurofiling architecture out of the Data Points Model (DPM) in  MS Excel format automatic creation of primary items, dimensions, domains (structures of members) taxonomies consisting of schema files and linkbases (label and definition) out of the Excel DPM interface for definition and output of tables linkbase (according to Eurofiling draft rendering schema and algorithms)

While you may not need to create taxonomies according to the Eurofiling architecture, this is a great reverse-engineering opportunity and it helps you see an approach used by others in working with XBRL.

I have used the term logical model. Others have used the term conceptual model. And still others use the term reference model. Call it what you like, but to make digital financial reporting effective and efficient for business, another layer is needed above the complex XBRL technical syntax documented by the complex and technical XBRL Specification.

Evidence that such a model is necessary are things like the matrix schema created by the Bank of Italy, the logical model created by the US GAAP Taxonomy Architecture, the Business Reporting Logical Modeland Financial Reporting Logical Model which I worked on with the XBRL International Taxonomy Architecture Working Group for many months, and the comparison framework created by the Interoperable Taxonomy Architecture Group.

So what exactly is a reference model or conceptual model or logical model.  Wikipedia describes a reference model as having the following characteristics (paraphrasing):

Abstract: a reference model is abstract. The things described by a reference model are not actual things, but an abstract representation of things.

Entities and Relationships: A reference model contains both entities (things that exist) and relationships (how they interact with one another).

Within an environment: A reference model is used to clarify "things within an environment" or a problem space.

Technology Agnostic: A reference model is not useful if it makes assumptions about the technology or platforms in place in a particular computing environment. A reference model is a mechanism for understanding the problems faced, not the solutions involved, and as such, must be independent of the selected solutions in order to provide value to the practitioner.

I am not saying that what I have created in terms of an SEC XBRL financial filing logical model, clearly defining the report elements (i.e. entities) and relations between the report elements (i.e. relationships) is a reference model. But I think it might help show the utility of such a reference model and provides clues as to what such a model looks like.

What is clear to me though is that some reference model, logical model, conceptual model or whatever you want to call it; some additional layer is beneficial. Why else would so many different folks be approaching some sort of issue from such a variety of angles?

Over the years in trying to build XBRL taxonomies and testing XBRL I have bounced around between having about 30 different "patterns" that business reports followed to a point where I believed that I have distilled those 30 down into 3 unique metapatterns.

Well, I have settled on 9 metapatterns. I have documented those metapatterns, provided examples for each one, reconciled them to the terms used by the US GAAP/SEC XBRL financial reporting logical model, and here they are:

1. Hierarchy: A hierarchy information model denotes a hierarchy of concepts with no numeric relations. If no numeric relations exist, then the information model of the component is a hierarchy.  Basically, anything can be modelled as a hierarchy. It is the addition of additional relations, typically computations, which turns a hierarchy into some other metapattern.
2. Roll Up: A roll up information model computes a total from a set of other concepts. This information model is commonly referred to a "roll up", or the equation A + B = C.  All concepts involved in this information model have the same set of characteristics and all must be numeric.
3. Roll Forward: A roll forward information model reconciles the balance of a concept between two points in time. This information model is commonly referred to a "roll forward" or "movement analysis" or the equation: beginning balance + changes = ending balance. In this equation period [Axis] is as of two different points in time and the changes occur during the period between those two points in time.
4. Compound Fact: A compound fact information model is characterized by the fact that some set of other concepts or some other information model exists for a set of characteristics expressed by one or more [Axis]. For example, the salary information for the directors of an entity is a compound fact.  The salary information is made up of salary, bonuses, director fees which roll up into total salary and this set of compound facts can be expressed for any number of directors, the director being the characteristic or axis of the compound fact.
5. Adjustment: An adjustment information model reconciles an originally stated balance to a restated balance, the adjustment being the total change, between two different report dates.  An adjustment is similar to a roll forward in that it is a reconciliation, however rather than the period [Axis] changing; it is the Report Date [Axis] which changes: originally reported balance + adjustment = restated balance.
6. Variance: A variance information model reconciles some reporting scenario with another reporting scenario, the variance between reporting scenarios being the variance or changes.  For example, a sales analysis which reconciles the concept sales for the reporting scenarios of actual and budgeted is a variance.  The equation is: actual - budget = variance.
7. Complex Computation: A complex computation information model can be thought of as a hierarchy plus a set of commutations between different concepts within that hierarchy which are challenging to model as the parent/child relations of a graph. The type of computations can vary significantly, thus the challenging in modelling.  For example, the computation of earnings per share is a complex computation.
8. Text Block: A text block information model is an information model which contains, by definition, only one concept and that concept expresses what amounts to a narrative or prose as escaped HTML within that one concept. For example, the narrative associated with a set of accounting policies expressed as a list or a table presentation format is a text block. As there is only one concept, there can be no relations within the information model.
9. Grid: A grid information model is a pseudo metapattern which uses the presentation characteristics of the columns and rows of a table to model information.  Because the grid models presentation information and not business semantics, it cannot be considered a metapattern.  However, the grid is included in this list because the US GAAP Taxonomy uses a grid information model to model the statement of changes in equity.

These 9 metapatterns are hard to dispute. Each is unique and each models some business oriented characteristic of a business report.  There may be more yet undiscovered metapatterns. Fine, they can be added.

But these metapatterns are basic, fundamental building blocks which every business user should know. If you can understand the differences between these metapatterns, that information will take you a long way.