fbpx Skip to content

4 Most Common XBRL Errors

insightsoftware -
February 2, 2021

insightsoftware is a global provider of reporting, analytics, and performance management solutions, empowering organizations to unlock business data and transform the way finance and data teams operate.

Common Xbrl Errors Header

The SEC is paying close attention to the quality of your company’s XBRL tagging, and it is critical to avoid common mistakes. According to a study conducted by XBRL US, many common (and preventable) XBRL errors are committed each year come filing time. In this blog series, we will explore the four most common XBRL mistakes.

Common XBRL Error #1 –  Invalid member axis combinations

Accounting for over one third of errors identified by XBRL US, the invalid axis member combination is, by far, the most common XBRL error. This is a qualitative error that occurs when a member and axis are used together inappropriately and do not make “financial sense.” With the number of axes and members in the US GAAP Taxonomy, there are numerous possibilities for incorrect combinations.

Example 1:

The offense that XBRL US has noted occurs most frequently is the incorrect use of ParentMember under LegalEntityAxis. The intention of ParentMember and its home axis, EquityComponentsMember, is to identify the portion of equity that is attributable to the parent (i.e., excluding non-controlling interests). When filers place ParentMember under LegalEntityAxis, they combine equity reporting and legal entity concepts and this does not make sense in financial terms.

Part1 Figure 1

LegalEntityAxis should only be used with its intended member, ParentCompanyMember, which, by definition, is intended for the legal entity acting as a parent of a company in a parent/subsidiary relationship.

Part1 Figure 2

Some errors may be obvious when reviewing a company taxonomy, such as an asset type member housed under a liability type axis, but others may require a more detailed analysis as seen in the following example.

Example 2:

You may be reviewing your taxonomy and see SeniorNotesMember (a standard us-gaap element) under DebtInstrumentAxis and think that this is an appropriate combination; XBRL US, however, would disagree.

Part1 Figure 3

They advise against using any non-extended member in combination with DebtInstrumentAxis as this specific axis is intended for the name of company specific debt instruments (as indicated by the associated domain DebtInstumentNameDomain.) In this situation the appropriate action would be to investigate the tag to determine whether a replacement is needed for the member (which would be an extension) or the axis (which would be a more appropriate axis of either LongTermDebtTypeAxis or ShortTermDebtTypeAxis, etc.)

Part1 Figure 4

 

As we saw in the previous example, not all invalid combinations will jump out to the average user. It is important to carefully consider the member axis combinations by asking yourself the following questions (keeping in mind the overall goal of making financial sense out of the data):

  • Is the member appropriate for the concept being tagged?
  • Is the axis appropriate for the concept being tagged?
  • Are the axis and member appropriate for each other?
  • Is there a more accurate member/axis available in the taxonomy?

Filing with this type of error leaves inaccurate and potentially misleading data for public consumption and can be easily prevented, so consider incorporating some of the following preventative and correctives steps into your process.

Training: If your internal reporting staff is responsible for element selection, make sure they are properly trained to analyze member axis combinations for appropriateness.

Review New Taxonomy Items: Implement a review process for new member/axis/element selection. With the vast array of members and axes that are available in the taxonomy, two heads really are better than one at identifying those easy to miss member axis combination errors.

Review Existing Company Taxonomy: When you have some down time between filings (and hopefully you do), take some time to review your existing taxonomy structure for appropriateness. If you wait until crunch time in your filing schedule, it is more likely to get pushed aside for next quarter.

Validation: There are several validation tools out there that will identify this type of error, among others, and summarize them in a report which can then be addressed using the proper reporting narrative. Through our partnership with XBRL US this validation can be completed in the Disclosure Management platform.

The quality of your XBRL tagging speaks volumes about your company’s financial disclosures. A disclosure management platform can help you avoid these errors with a series of validation warnings.

Common XBRL Error #2 –  Negative Value Errors

The negative value error is the 2nd most common error committed by filers and accounts for over 12% of all XBRL errors.  This error occurs when a concept reported as a negative value is expected to have a positive value.  According to XBRL US, certain concepts should only have negative values in exceptional circumstances.  A validation tool is a great way to check for this type of error; however, with over 15,000 elements in the taxonomy and numerous unique company disclosures, it is important to review your negative values internally as an additional line of defense.

In order to perform a negative value check, you will need to filter by instance document values. In Certent’s Disclosure Management Platform, you can quickly pull up all negative instance document values and navigate directly to their location in the document with a click of your mouse.  Once you have identified the negative values in your document, it is important to understand why it was reported as negative in order to make any appropriate corrections.

Example 1: Reverse Sign and/or Negate Label

There are certain situations in which a change will always have a negative effect; the repurchase of common stock, for example, will always reduce shareholders’ equity.  For this reason the element TreasuryStockValueAcquiredCostMethod (which would typically be applied to this concept/line item) has a balance type of debit in the US GAAP taxonomy.  When this element is applied without being negated, a negative value error is created.  Following is an example of a concept that is susceptible to negative value errors – treasury stock.  Stock repurchases have a negative effect on shareholders’ equity and are presented in the equity statement in parentheses.

Part2 1

 

Microsoft Corporation 2015 10-K

If TreasuryStockValueAcquiredCostMethod is applied to this line with a standard label role, the balance type of the element (debit) combined with the negative presentation gives us a negative debit, or a credit, and a credit balance type is incorrect for a concept that reduces equity.  This particular element should, therefore, have a reverse sign and negated label applied.  Reversing the sign changes a value to the opposite sign in the instance document (i.e., negative to a positive or positive to a negative.)  Once the instance document value is positive, it will also show as positive in the XBRL rendering.  This needs to be corrected by changing the preferred label role in the company taxonomy to NegatedLabel, which will cause the values tagged with the negated label to be presented as the opposite sign.

Another example of a common area that requires a reversed sign and negated label is a standard stock option activity roll forward table.  In this standard disclosure, exercised, cancelled, and expired shares are typically presented as negative values because they reduce the number of options available for grant.  It isn’t possible for a negative number of shares be exercised, cancelled, or expired, however, so these concepts also require reversed signs and negated label roles. SEC XBRL Staff Observations identify additional examples of concepts that should only have positive values.

Part2 2

Yahoo! Inc. 2013 Form 10-K

Example 2: Incorrect Element Use

There are two types of elements in the taxonomy when negative value errors are being discussed: one-way elements and two-way elements.  One-way elements are intended to capture a one way change in a concept – a derivative gain, for example.  Two-way elements capture both increases and decreases (i.e., gains and losses on derivatives.)

Part 2 Fig 3

 

It is important to make the proper element selection for your company’s individual situation.  If a concept in your document will almost always have the same balance type, and therefore almost always be presented as either positive or negative (but not both), it is better to choose the element with the narrower definition.  If the balance type of the concept fluctuates between debit and credit, however, it would be more appropriate to use a two way element.  If you come across a negative value associated with a one-way element in your review, you may want to consider replacing it with an element that is more specific to the concept being disclosed.

Example 3: Dimensional Qualification (Members)

The third type of negative value error is related to missing dimensional tags, or members.  Sometimes there are legitimate reasons to have a negative value for a concept that is expected to be positive, such as accounting adjustments and inter-company eliminations.  The structure of the taxonomy for these types of disclosures generally provides for the use of members such as RestatementAdjustmentMember and ConsolidationEliminationsMember.  These types of members allow concepts that typically should be positive to be negative, without causing errors.  Some other members that can indicate reductions in otherwise positive values may include text such as “reconciliation,” “netting,” and “adjustment.”

Part2 4

 

Common XBRL Error #3 – Required Value not Reported

As the third most common XBRL error, required value not reported accounts for just under 10% of XBRL errors. This error occurs when a required value or a combination of values are not reported as a fact(s) in the instance document. The missing, required elements that cause this type of error consist of common concepts that are either explicitly defined in the US GAAP taxonomy, Accounting Standards Codification (such as earnings per share), or elements in the US-GAAP taxonomy that are defined generically (such as Assets.) It can be difficult to identify missing concepts in the sea of values that make up financial statements, so this error is best prevented by use of a validation tool. However, there are steps you can take to try and prevent them from occurring in the first place.

A required value not reported error indicates that certain concepts or other required elements, such as earnings per share, are not reported in the instance document. Unless you are a non-public company that is not required to report earnings per share, a missing earnings per share fact indicates incorrect XBRL reporting. Usually earnings per share is missing because the concept was tagged with a custom element extension, and since the Accounting Standards Codification explicitly defines this concept, the company’s disclosure of earnings per share will almost always be consistent with the element provided in the US GAAP taxonomy. Another example of an inappropriate custom element extension would be the extension of an assets element. The US GAAP taxonomy defines this element generically in order to avoid unnecessary extensions.

In addition to unnecessary extensions, the required value not reported error is caused by inappropriate US GAAP element selection. The most frequent error related to missing required information occurs on the Cash Flow Statement.

Example: Cash Flow Statement

In the Cash Flow Statement of Exxon Mobil Corporation below (which does not represent their actual element selection,) it may appear that the elements selected for the total of the operating, investing, and financing activities sections are correct. After all, the selected elements appear to be the given total elements, but a closer look at the structure of the taxonomy is required.

Part3 1

 

Exxon Mobil Corporation 2015 10-Q

The definition of all three selected elements indicate that discontinued operations are included in the calculation. Since no discontinued operations exist in this statement, however, the selected elements are inappropriate. The actual error that results from this incorrect element selection is the missing Continuing Operations and Discontinued Operations elements that are expected to be included with an element that is defined as the total of both. XBRL US provides best practice guidance including additional information and recommendations on this cash flow statement issue.

This error does not just occur during a taxonomy build, it also occurs when circumstances change, but the associated elements do not. For example, Accounting Standards Update number 2014-08, issued in April 2014, changed the criteria for reporting discontinued operations. This modification caused a number of filers to reclassify disposals from discontinued operations to continuing operations. If all discontinued operations were completely reclassified and the operating, investing, and financing activities total elements were not updated, then the result is incorrectly reported concepts and a required value not reported error.

Common XBRL Error #4 – Date Error

According to XBRL US, date error is the fourth most common XBRL error committed by filers and accounts for over 9% of all XBRL errors. This error occurs when concepts in an XBRL document are tagged with incorrect dates in relation to the end date of the reporting period. The date error can also pop up when a concept is tagged with the appropriate calendar, but has not been properly dimensionalized. With proper training and a thorough review processes, this error can be easily avoided.

Example 1: Future Amortization Expense

Part4 1

Microsoft Corporation 2015 10-K

Above is an excerpt from Microsoft Corporation’s 2015 10-K “Goodwill and Other Intangible Assets” note. Since future dates are stated in this disclosure, one may be inclined to tag each line with the associated fiscal year calendar. That would be inappropriate, however, as this table consists of an estimate at reporting period end of future expenses, not an exact amount. The US GAAP taxonomy contains “future” elements that indicate the associated concept as an estimate of a future recognition. If this type of element exists in the taxonomy for a particular concept, the appropriate treatment is to use a date context of the end of the reporting period of the document.

Part4 2

2015 US GAAP Taxonomy Future Elements

Example 2: Subsequent Events

Naturally, most concepts in a 10-Q or 10-K will be tagged with a calendar that is prior or equal to the documents period end date since that is the period being reported, but subsequent events, by definition, occur after the end date of the reporting period. Accordingly, they should be tagged with the date on which the subsequent event occurred. It is important, however, to make sure that the event is also specifically indicated as a subsequent event with SubsequentEventMember. Visit XBRL US for additional guidance on subsequent events.

Part4 3

Starbucks Corporation 2014 10-K: Subsequent Events Note

Example 3: Forecasts

Not every forecast in a financial report will have an existing future element in the US GAAP taxonomy, so in some cases a different approach must be taken. In the example below, the two values in boxes represent the planned number of closures, and since no one can provide assurance of the future, they are forecast for the periods indicated. In this case it is appropriate to tag the values with the future date indicated in the document, but it is important to further identify them with ScenarioForecastMember since they are not actual facts that have occurred.

Part4 4

Staples, Inc. 2014 10-Q for the period ended November 1, 2014

It is important to review your XBRL for proper use of future dates and take corrective actions. In Certent Disclosure Management this can be done by using a date filter to sort and navigate to specific dates in your document. Since a document can change numerous times during the reporting period, this review, is best left for the week prior to filing (or when the tagging largely completed). For additional guidance on tagging forecasted information visit XBRL US.

Incorporating checks for the most common XBRL errors in your document review process will ensure accuracy of your data and enhance the quality of your filings.