Issued: September 5, 2012
Impact: All US GAAP

Issue

A large number of filings to date have incomplete calculation relationships defined in the extension taxonomies filed with the SEC.  The EDGAR Filer Manual Volume II version 21 states the following:

6.15.2    If the original HTML/ASCII document shows two or more line items along with their net or total during or at the end of the Required Context period, and the instance contains corresponding numeric facts, then the DTS of the instance must have an effective calculation relationship from the total element to each of the contributing line items.

A calculation relationship is a link:calculationArc with an xlink:arcrole attribute equal to ‘http://www.xbrl.org/2003/role/summation-item’. The Required Context is defined in EFM 6.5.19.

Examples:

  • A company’s Cash flow from investments for the most recent quarter is shown as the sum of two lines: Payments for plant and equipment, plus payments for marketable securities. Two calculation relationships are required.
  • An income statement shows the line items “Revenues”, “Cost of Goods Sold” and “Gross margin” as the net of the two values during the current quarter. Two calculation relationships are required. In this case, the relationship subtracting Cost of Goods Sold will have a weight attribute of -1.
  • A balance sheet shows assets as the sum of current and non-current assets, as of the date falling at the end of the period of the Required Context. Two relationships are required.
  • An income statement shows only earnings per share and diluted earnings per share, but no reconciling per-share amount. Calculation relationships are not required.
  • An income statement shows earnings per share before and after an adjustment for change in accounting principles, along with the adjusting amount. Two calculation relationships are required, from the net earnings per share, to its two contributing amounts.
  • A balance sheet shows Net Current Receivables with a parenthetical value for Allowances. Only two values are shown, so no calculation relationship is required. In general, parentheticals do not, by themselves, require calculation relationships.
  • A footnote for ABC contains a table in which the Revenue of its separately reporting subsidiaries DEF, GHI and JKL are totaled. But each of the four facts has a different contextRef attribute. Therefore, this does not require any calculation relationships.

There is no separate, independent requirement that every company-specific element be included in calculations. It is, however, one of the consequences of this rule that a company-specific monetary or other numeric item is often defined in such a way that it must participate in calculation relationships anyway.

Recommendations

Every rule in the EDGAR Filer Manual carries the same implications as all other portions of Rule S-T 405.  A submission that does not conform to 6.15.2, therefore, is not compliant.  However, it is not intended to be testable in the same way that an EFM chapter 6 syntax rule is testable (a violated syntax rule rejects the XBRL documents).

The reason this is not testable in the same way is that it is dependent on a comparison between the Original HTML/ASCII Document and the XBRL documents, and to some degree on the semantics of the financial information reported in that Original HTML/ASCII Document.

Simply indicating every numeric element that has facts but does not participate in any calculation relationships may be sufficient for a manual review for non-compliance.  Any face financial presentation group in which there are many line items without any calculations is prima facie rather suspect.

Understandably, though, it is desirable to automate a warning for preparers of XBRL documents that they may be violating this rule and to manually inspect questionable cases, while not flagging any false positives.  To do so requires implementation of an algorithm.

At this time, there is no authoritative algorithm for doing so.  Claims by software vendors to have implemented an authoritative algorithm, or third party claims that a vendor’s algorithm is authoritative, are therefore false.  Indeed, any effort to duplicate any algorithm or results from algorithms claimed to be authoritative should be avoided.  Reliance on such claims is no guarantee of compliance and no defense.

Here are some points that software developers should carefully consider while authoring such an algorithm.  It does NOT constitute an authoritative algorithm.

  1. 5.19 is assumed to hold in the filing. That is, it is implicit in this rule that in an XBRL filing containing financial statements, the end date of the Required Context represents the “as of” date of financial statements.  Discrepancies between such dates may mask violations of 6.15.2, but it does not waive them.
  2. EDGAR validation does not reject filings that have XBRL 2.1 calculation inconsistencies, but this does not mean that the calculation relationships are ignored. Downstream applications do use the calculation relationships.
  3. For purposes of testing 6.15.2, the calculation relationships that appear in the published US GAAP or other standard taxonomy but that are not in the DTS of the instance, are not relevant.
  4. 15.2 by itself imposes no requirement for the relationship between presentation relationship groups and calculation relationship groups. The rule requires certain calculation relationships to be present in the DTS, but not in any specific relationship group.
  5. The type of the element is the basis of determining where this rule applies. The term “line item” refers to a non-abstract element whose content is numeric and, therefore, cannot refer to any abstract or non-numeric element, thus ruling out domain members, axes, tables, strings, and so on.  Therefore:
    1. Although the Rendering Engine, particularly in Risk/Return Summary documents, may result in horizontal rows of adjacent numeric facts, unless the elements in the rows are numeric elements, it is not relevant.
    2. The horizontal or vertical layout of the Original HTML/ASCII Document is not relevant. Only the type of the fact and its relationship to other facts matters.
    3. Certain calculation relationships that exist in the document that when represented in XBRL are illegal in XBRL 2.1, such as between instant- and duration- type elements, and omissions of XBRL calculations do not contribute to non-compliance.  For example, a series of three line items representing a starting balance, a change, and a final balance, do not require any calculation relationships.
      1. This is relevant to the cash flow statement and equity statement which typically have a mix of duration and instant facts.
      2. This is also relevant to the income statement which has share elements and perShare elements.
  6. Using presentation relationships in instance documents to determine adjacency of line items for the purposes of 6.15.2 is only a partial basis for determining whether the rule applies. If presentation relationships do not correspond to the Original HTML/ASCII (as required by 6.13.3), then omitted presentation relationships will mask 6.15.2 violations, and extra presentation relationships may signal false violations of 6.15.2.
  7. Only if it is assumed that there is a reliable way of establishing completeness and correctness of presentation relationships with respect to the Original HTML/ASCII Document, could the following heuristics be used to suppress false positives:
    1. A “violation” would consist of a presentation relationship whose target element does not participate in the required calculation relationship. In other words, take into account that an element can appear in more than one presentation group.
    2. Perform an in order traversal of the presentation linkbase, ignoring abstract elements and elements that have no fact in any period.
    3. Identify the “runs” of three or more elements of the same data type and period type within a single presentation group.
    4. Any presentation relationship appearing in no “run” of length three or more anywhere in the DTS is not a violation.
    5. An element and its immediate children with respect to the summation-item relationship form a set; if first or last element of a “run” is the source of the calculation relationships and the other elements the children of a set, then those presentation relationships are compliant.