Digital Financial Reporting

I took the Comprehensive Example, created two additional copies (so that I have three companies), and now have the Comparison Example.

The Comparison Example is the capstone of what someone is likely trying to achieve in XBRL: comparison of some set of business information.  There are three ways business information is commonly used:

• Using a single information set:  For example, using one financial report.
• Comparing across periods: For example, comparing your financial report over a period of time.
• Comparing across entities: For example, comparing three entities at one point in time or for a period of time.

The Comparison Example was created to test these use cases. These three XBRL instances and related XBRL taxonomies are as identical as they can be.  Each company has its own meta data where it needs to.

When you look at this example, consider where the meta data is defined.  There are four levels here in this example:

1. Company taxnoomy: Defining concets at this level provides the least comparability as it is defined at the company level, but at the same time it provides the most flexibility because the company can define anything it wants.  If the GAAP taxonomy follows the FRLM and BRLM, then the compnay does also.
2. GAAP taxonomy: This gives improved comparability because different companies share the same GAAP.  It does not have to be this way, conceivably every company could create their own XBRL taxonomy and create great XBRL.  But, if every company did that individually, comparisons would still be possible, they would just be difficult becuase you would basically have to physically map one company to another.
3. FRLM (Financial Reporting Logical Model) taxonomy: This level provides comparability between GAAP taxonomies, should that be desired.
4. BRLM (Business Reporting Logical Model) taxonomy: This can be use by different domains who want to leverage the Business Reporting Logical Model.  The advantage here is that if a software application were developed at this level, anything above it in this list would be comparable with that software.  The software would still be XBRL compliant, i.e. the BRLM is 100% XBRL compliant.
5. XBRL: Defined by XBRL. Here, you have the least amount of flexibility (i.e. you must follow XBRL to be XBRL compliant) but you also have the most comparability. If everything was defined at this level it would be very comparable, but not very flexible. Basically, if everything were defined at this level it would serve one business domain and would basically be a form.

The level at which things are defined is determined by the business domain applying XBRL. The advantage of the BRLM level is that it allows users to be clear about the business semantics they are using and software applications can leverage that clarity, making the software and XBRL easier to work with.

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.

Many people I talk to are surprised when I tell them that XBRL is not just for financial information, that it can be used for other business information, any information in fact. While there are pros and cons to using XBRL and it is not right for everything, its utility goes beyond financial reporting.

I talked about XBRL's sweet spot in another blog post, I will summarize that sweet spot here:

• Larger transactions which tend to change (i.e. such as a 50 or 100 page regulatory report with perhaps thousands of facts exchanged, as opposed to a small transaction with 10 data points)
• Zero tolerance for errors in the information (i.e. everything must tick and tie and if things don't add up, bad things happen)
• Information which needs to be reconfigured(i.e. not a form, although XBRL can be used to expressed what amounts to a form, it excels when that "form" needs some flexibility)
• Business people changing the metadata, no IT involvement required (i.e. XBRL has a good balance between power and ease of use)

No why are the examples I createmostly related to financial reporting? Well, a couple of reasons. First, I am a CPA so that is my domain of expertise. Second, I am a CPA and I want to help the financial reporting domain figure out XBRL in order to use it effectively within that domain. Third, it does have a lot of uptake in terms of using XBRL.

I do create non-financial reporting examples.  See the "State Fact Book Prototype" which I created.  Also, this may seem strange but have a look at it. Here is a non-financial reporting example.  Visualize this by looking at the PDF.  I am using placeholder text use for prototyping marketing information for the concepts expressed in the XBRL taxonomy and reported in the XBRL instance.  It still works.  No debits or credits, no balance sheets or income statements, not financial reporting related.

When you look at the business use cases forget about the specifics of what you see in the use cases. Just like mathematics is used in accounting and engineering and physics and medicine and whatever domain; those patterns of what I am expressing goes beyond financial reporting. Look at the examples in more general terms.  I thought about creating 100 non-financial reporting uses for XBRL, which I still may do one day.  For now, I am focused on financial reporting and figuring out how to best use XBRL in that environment.

I have reached a big milestone in updating the business reporting use cases which I am putting together. You can get to those from this index page which contains the use cases plus some other things relating to the use cases. This is a direct link to 31 business use cases.

Several points about these business use cases.

• You can download the complete set, see the download link on the page.
• Each use case has been validated by 4 different XBRL validators and all of those validators report no errors.  (The XBRL Formula stuff used is only validated by one validator.)
• I would consider these use cases "very safe" areas of XBRL.  This is because of the consistency in the validation across 4 different validators, each provides the results expected, XBRL extension works as expected, and all approaches used come from years of fiddling around with different approaches to articulating these use cases in XBRL. (Considers techniques use in the most current US GAAP taxonomy, IFRS taxonomy, COREP, etc.
• All the visual stuff in the taxonomy such as the "[Fact Group]", "[Member]", "[Measure-Concepts]", "[Roll Forward]", "[Roll up]" (and so forth) is only visual eye candy and is unnecessary.  Those things appended to the concepts and labels only helps one visualize the taxonomy given the lack of assistance provided by software these days.
• While I did provide a presentation linkbase, the presentation linkbase is not necessary.  Basically, the presentation linkbase can be autogenerated from the definition linkbase.
• The presentation, calculation, and definition linkbases are consistent.
• While I did use the substitutionGroups of the business reporting logical model schemaand doing so is very helpful in creating a consistent XBRL taxonomy, doing so is not necessary.
• While I did use the measures of the financial reporting logical model schema, I really did not have to because these taxonomies are only demos.  However, the technique of using those measures does enhance comparability across XBRL taxonomies if that is desired.
• These XBRL instances and XBRL taxonomies do follow the useful practices of the Financial Reporting Instance Standards (FRIS) and Financial Reporting Taxonomy Architecture (FRTA), they do not necessarily follow the useless syntactic constraints imposed by FRIS and FRTA.  On the other hand, the XBRL instances and XBRL taxonomies do follow a number of best practices which would be a good idea for something like FRIS or FRTA (or whatever replaces them) should make use of. So, don't expect that these comply with FRIS or FRTA validation.

I do intend to provide additional documentation which explains the subtle characteristics of these use cases which one can miss if they are not pointed out.  Not sure when. My next goal is to create a comprehensive example which tests these use cases by seeing how they interrelate with one another within one larger business report.

I am continuing my work to document business use cases and how one can express them in XBRL taxonomies and XBRL instances and I have, I belive, determined that there are two new metapatterns.

To summarize, the Roll Forward metapattern is overloaded, in my view, and really should be broken out into three metapatterns:

• Roll Forward: This is what exists now. The Roll Forward reconciles a balance at one point in time to a balance at a different point in time.  This is a simple thing that most people learned in their auditing class most likely: BASE.  Beginning + Additions - Subtractions = Ending. In the XBRL world you have one concept which is an instant (the balance) and one concept which summarizes the changes (the additions and subtractions).  The only dimension which changes is the period (Calendar Time [Measure] in the business reporting logical model.  Here is a very basic example.
• Adjustment: This is new.  I had always tried to model this as a Roll Forward, but it is really something different than a Roll Forward. For an Adjustment, the period (Calendar Time [Measure]) does not change, it stays the same.  What changes is some other dimension.  Here is a basic example. In the example, the balance of retained earnings is restated for prior period adjustments.  The equation is: Originally Stated Balance + Adjustments for Prior Period Errors = Restated Balance. In the example (look in the XBRL instance at the contexts), what changes is the Report Date [Measure]. Frankly, I believe that the definition of an adjustment is a change in the report date. If one looks at the details, you can see the differences between a Roll Forward and an Adjustment.
• Variance: This is new. I had always modeled this as a Roll Forward also. Here is a basic example to help you visualize what is going on. In that example, we have Actual - Budget = Variance. The variance seems to be the difference between two Members of the same dimension or called Measure in the Business Reporting Logical Model. While the Roll Forward appears to specifically relate to changes in the period and the Adjustment appears to relate to changes in the report date; the Variance appears to be generally applicable to any dimension (Measure). The Domain of the dimension (Measure) is what expresses the actual variance value.

So while I do want to check with the super smart XBRL people that I know to be sure that breaking the Roll Forward out like this is the thing to do, I would contend these are in fact metapatterns.

Alternatively, one could perhaps argue that the Adjustment and Variance are specializations of the Roll Forward.  But, if one were to look at the details in the XBRL instance and the XBRL taxonomy, I really do think someone knowledgeable about XBRL and business reporting would break these out into separate metapatterns.

Have a look at the details, let me know your vote. I will get back to you with what others think at some point in the future.