Email Sales

Email Sales

Need product support? Please visit our Customer Support page.





Back to Blog

XBRL Errors from a User’s Perspective: Why They Matter

Merrill Disclosure Solutions | October 30, 2012

[Merrill Corporation - Dimensions eNewsletter - October 2012]

By Alex Rapp, Calcbench

Alex Rapp

Recently, there has been a tremendous amount of talk about errors in XBRL filings, and I do not want to rehash this conversation. Rather, I would like to give the perspective of a very eager user of the data everyone is creating and talk about how the errors by filers complicate our work.

At Calcbench, we maintain for our XBRL applications an “adjusted” cloud-based database of the entire universe of XBRL SEC financial data (about 25 to 30 million data points and counting). We consider data quality to be hugely important, and we spend a lot of time examining filings for errors and correcting the ones we find. Our goal is to provide our customers with an error-free data universe. Naturally, everyone can help us with this.

Errors of Scale

First, the good news: From what we've seen, very rarely does a filer actually get the facts wrong (for example, typing a 6 where there should have been a 9). The exception to this, of course, is errors of scale. An example of a scale error is where the filer reports its assets as $500 trillion instead of $500 million, or $500 thousand instead of $500 million. One place we often see this problem is in the share count, but we have seen it in all parts of the filings. We have seen filings where every monetary value is off by an order of one million, and others where the values are incorrect in just one particular statement.

A TIP ON CHECKING FOR SCALE ERRORS: They are hard to spot by naked eye! Many software packages (including the one the SEC uses on its own website to render XBRL filings) automatically cut out zeros in order to make the data easier to read. For example: Your assets are $550 million, but they appear on screen like this: $550. You need to read the fine print to be sure it is accurate. The phrase In Millions, except Share data in Thousands, unless otherwise specified (see illustration below) would mean you got it right. On the other hand, if it says In Thousands? Well, that would be a problem!

Illustration 1

Document and Entity Errors

By our count, 3% to 5% of all filings have something wrong in the Document and Entity section. (This is the very basic set of standard info that goes at the top of every filing, stating what company, what period, etc.)

To me, an error here is like writing your name wrong on top of your homework assignment. Embarrassing, no?

To the best of our knowledge, pretty much everyone gets the company name and CIK code right. But things fall apart pretty quickly after that. In particular, the information we care most about are the dates: fiscal-year-end date, period-end date, fiscal year, and fiscal period. The most common mistake we see is where filers simply forget to update one or more of these values. They send in a new filing but forget to change Q1 to Q2, for example.

Here is an example of a filing with dates that just do not add up:

Illustration 2

Why is this important? The dates in this section provide context to everything else. Whether you are an analyst simply searching through a pile of filings, or someone like us, loading the data into a 'filing agnostic' solution, it is essential to know basic details, such as your fiscal year-end date! Knowing whether something is 1Q or 3Q is essential to an analyst, and necessary for doing comparisons across companies. It also set the expectations for what we will find in this particular filing, which guides us in what else to look for.

Sign Errors

By now, most people know about sign errors, which usually happen when the filer slaps a minus sign in front of a number that is tagged to an element which represents a positive amount (like reporting a negative Cost of Goods Sold, for example). This can be confusing, which is why the errors keep occurring. Certain software programs and output reports can be useful in detecting some of these sign errors before filing.

Merrill comment: The proper entry of signs in XBRL requires an understanding of the meaning of the fact being disclosed and an understanding of the element that has been selected to tag the fact. A preparer who understands both can then determine the correct sign. Fortunately, most elements are structured so that only a positive amount should be entered for that element. Many elements in the US GAAP Taxonomy, however, can properly have either a positive or a negative amount entered. For those elements, it is important to understand both the fact disclosed and the element selected, which then allows the preparer to evaluate the fact and enter the proper sign.

DIY Extensions Can Ruin Everything

I know, I know . the taxonomy provided by FASB is a framework, and companies can deviate where necessary. But honestly, from the perspective of an analyst who is trying to use the XBRL data directly, customizing is almost never necessary, at least not in the primary statements. (The detail tags? Well, that's another story.) Currently about 20% of all facts are going into extensions tags, and I feel so many of these are superfluous. For example, if you consider capitalized software costs to be part of your property plant and equipment, more power to you! But you do not need to let everyone know that by creating a custom tag, such as PropertyPlantAndEquipmentAndCapitalizedSoftwareNet. Actually, an existing tag like PropertyPlantAndEquipmentNet is just fine.

Merrill comment: Extensions in the primary financial statements usually occur when either a company reports a unique item or when the company aggregates certain amounts in the financial statements and the US GAAP Taxonomy does not contain an appropriate element. A higher percentage of extensions on the primary financial statements appears on the Statement of Cash Flows and the Statement of Stockholders' Equity than on the other primary financial statements. This higher percentage is due primarily to (a) the detailed section of the Statement of Cash Flows, which shows the adjustments to reconcile net income to net cash provided by operating activities; and (b) the detail in the Statement of Shareholders' Equity, which includes the impact on equity from transactions unique to the company. Although extensions are much less common on the primary financial statements than in the notes, extensions are necessary in the primary financial statements to properly disclose certain information that the company deems material to the financial statements and for which no appropriate US GAAP Taxonomy element exists.

I had a high school teacher who was fond of saying: “I won't tell you what to do, but the better students will do this.” In that spirit, I will suggest what the better students would do. But first, some trivia. What has been the most common extension tag? WeightedAverageNumberBasicDilutedSharesOutstanding. It has been adopted by 380 different companies, and it is easy to see why: The FASB had a tag for basic shares and a tag for diluted shares but, until the 2011 US GAAP Taxonomy, no tag for the filers who like to report both in a single line item.

But stop for a second and think. Does this not completely defeat the purpose of XBRL? It is not about presentation, but rather about analysis. It seems fine to put basic and diluted in one line item for presentation purposes. But the better students will recognize that basic and diluted represent two separate concepts and should be entered as two separate facts (even if they are identical) in the XBRL filing.

Realizing the Dream

I know the past year has been a blur for filers, and most of the focus on XBRL quite frankly has been on just getting it done. But going forward, that is not going to be good enough.

Certainly not for the analysts who are eager to use this data, but also not for the regulators. The good news is that we are well on our way to realizing the dream of XBRL, and this dream is going to benefit everyone. If we all keep on plugging, I think we are going to be there very soon.

Alex Rapp is the co-founder of Calbench, based in Cambridge MA. The company has a proprietary platform using XBRL data to instantly retrieve, analyze, and share financial information from US-listed companies. It won the first XBRL Challenge, created by XBRL US to uncover the best open-source analytical tools that can mine XBRL-formatted corporate financial data from the SEC's EDGAR database .

I agree

This site uses cookies to offer you a better experience. For more information, view our privacy policy.