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.

I have completed what I call the comprehensive example. Whether you are a business user of XBRL or a technical user of XBRL, there is a lot for you to learn from this high quality, robust example of XBRL. While the details are all there, I have not yet provided the summaries needed to walk you through the comprehensive example so you can get the most from this resource.  Those summaries will be created over the coming weeks.

For now, start at the top of the page, work your way down, and dig into the details which interest you most. There really is a lot there to learn.

Want some smaller more focused examples? If that is the case be sure to check out the business reporting use cases.

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.