How to eliminate unnecessary extensions

What is an extension? An extension is a custom XBRL tag that isn't part of the standard US GAAP Taxonomy (UGT). Filers are allowed to create extensions when they feel the information they're tagging isn't represented by any of the standard tags from the UGT. Since everyone has different needs within his or her documents, why reduce the number of extensions?

The issue lies with the consumption of the XBRL data. One of the primary goals of having all of your financial information tagged is to allow for simpler queries and analysis of the data. The tools that use the XBRL data for analysis aren't able to easily compare across companies, industries, etc., when certain types of extensions are used.

The XBRL consumption tools are built to use the structure found in the UGT (e.g., tables and axes). When you extend for either the table structure or axes, the tools don’t know how to read the extended XBRL, and the data can't be read automatically.

Extensions for line items or individual accounting concepts can also be difficult to read automatically. As a result, either a person has to intervene during the analysis to interpret the data. Otherwise, the data simply goes unread.

You're probably thinking, "But my document is very specific to my company, so I need all of my extensions."

In some cases, you might need a few extensions due to the nature of your business, but in most situations you won't need any extensions. Unfortunately, it's not uncommon to see filings with well over 50 percent of the XBRL tags extended—there is definitely work to be done.

Fortunately, the EDGAR Filing Manual (EFM) provides guidance on how to select the appropriate tag. Following this process should reduce the number of extended concepts in your document:

• The definition of the tag should faithfully represent, in all material respects, the individual facts in the HTML financial statements. The definition for a standard element should not specifically exclude any material information about the tagged fact.


• Examples that are included with the definition are not exclusive. Just because the fact to be tagged does not conform to one of the examples does not mean that you should create a custom tag.


• If there appear to be multiple standard elements that faithfully represent a fact, in all material respects, pick the one with the narrowest definition.

 

Seems pretty simple, right?

However, the EFM doesn't define what is meant by material. As accountants, our natural inclination when we hear the word material is to think of de minimis or some other audit materiality level. But that's not necessarily the case. In essence, the EFM and thus the SEC, is telling us that close is good enough, as long as a user's understanding of the the tagged data isn't altered when using that data instead of maintaining the same data in the HTML financial statements.

Follow these three simple rules when searching for a standard tag:

1. Which taxonomy section are you in?
   While you can select a tag from anywhere in the UGT, you should search within the taxonomy section related to the statement or note you're tagging.


2. Make sure you're saying the same thing in XBRL as you are in the HTML financial statements.
   Your XBRL tags shouldn't be giving more or less information than the HTML financial statements. The phrase \"faithfully represent, in all material respects,\" means the selection should be close enough that a user's understanding won't be altered when using the tagged data instead of reading the same data in the HTML financial statements.


3. Use the predefined table structures and axes in the UGT.
   Don't use line items if there's predefined table structure in the UGT, and don't create an axis if the UGT has line items that provide the same information.

Reducing the number of extensions in your XBRL is about taking the time and doing the research to get as close as possible. Remember, your XBRL documents shouldn't be treated as static. You should frequently review your XBRL documents for updates and best practices, similar to the process for reviewing and improving your HTML document.