From EDGAR Filer Manual Volume II version 20:
6.6.30 Invert the sign of a numeric fact whose element has an xbrli:balance value that is inconsistent with the true direction of the reporting concept being reported.
Often, this means entering a negative value into the instance, irrespective of whether that negative value will subsequently be rendered without brackets as a result of applying a negated label.
The value of xbrli:balance (debit or credit) is assigned to monetary elements in a standard taxonomy namespace from the perspective of the income statement and balance sheet. This perspective may be inconsistent with the presentation of the element in the financial statements. For example, a financial concept in the cash flow statement may be represented by an element that was assigned an xbrli:balance based on the income statement. As a result, the xbrli:balance may be different from preparers’ expectations. A different xbrli:balance value for an element must not influence the registrant in deciding whether the element is appropriate for the fact representing a financial concept, and registrants should not create a new element if an element in a standard taxonomy namespace is consistent with the financial concept reported in all respects except xbrli:balance.
Use an element in the UGT if its attributes are consistent with the reporting concept in all other respects even if its xbrli:balance is not the balance type expected.
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.6.30, 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 causes EDGAR to reject the XBRL attachments).
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.
The overwhelming majority of numeric facts should be positive by virtue of a combination of factors:
- EFM 6.15.2 which requires calculation relationships: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.
- XBRL 2.1 Specification Section 5.1.1, Table 6:Table 6. Constraints among the balance attribute and calculation arc weights
balance attribute of “from” item balance attribute of “to” item illegal values of the weight attribute on calculationArc debit debit Negative (< 0) debit credit Positive (> 0) credit debit Positive (> 0) credit credit Negative (< 0)
- EFM 6.8.11 which gives guidance on custom elements:6.8.11 An xsd:element with a type attribute equal to ‘xbrli:monetaryItemType’ must have an xbrli:balance attribute if it appears on a statement of income or balance sheet.
- The conventions by which monetary elements are assigned balance attributes in standard taxonomies, particularly US GAAP taxonomies.
On the other hand, facts can appear in a context with a segment dimension and member that reverse their natural sign. For example, 6.6.8, there are eliminations:
6.6.8 In a consolidating instance, facts that apply only to eliminations between subsidiaries must have contexts whose xbrldi:explicitMember elements have a dimension attribute of LegalEntityAxis and value ConsolidationEliminationsMember.
Other combinations of dimension and member that reverse the natural sign:
- ConsolidationItemsAxis / IntersegmentEliminationMember
- StatementEquityComponentsAxis / TreasuryStockMember
An odd number of such Axis/Member combinations in a context should reverse the natural signs of their facts. We refer to these as “negating contexts”.
6.6.30 does not specifically refer to the SEC rendering engine and its use of the “preferred label” attribute in the presentation linkbase to render a value with a “sign flip.” This seeming omission from 6.6.30 is deliberate. 6.6.30 concerns the data in the instance; rendering is not relevant to compliance with this part of the rule. Unfortunately, because 6.8.11 separately provides guidance as to how to make a positive value render with brackets (or a negative value without brackets), many first-time filers have tripped up on this important distinction between the value of a fact and its appearance as rendered.
Because most fact values in an instance should be positive, there are simple ways to alert preparers of XBRL documents that they may be violating this rule:
- In rendered output, highlight rows (or columns) to which a negated label has been applied.
- In rendered output, highlight in a different way, facts whose underlying value is negative.
Another simple idea is to highlight areas for manual inspection that have been known to present filers with issues:
- TreasuryStockValue on the Balance Sheet; a value that is positive but conventionally rendered with brackets
- Dividend payments and capital expenses, which are positive values in the cash flow statement, also conventionally rendered with brackets
- Line items that appear among the adjustments to reconcile net income to cash provided by operating activities
- Facts whose element names begin or end with “Net,” contain the string “IncreaseDecrease”, “ProfitLoss”, “GainLoss” and are from a standard taxonomy
- Elements that are near synonyms presented in different statements, for example, Dividends and PaymentsOfOrdinaryDividends
Items A through D above result in a network of valid calculation relationships applying to monetary and other numeric elements. This has a beneficial effect: fact values having the wrong sign are almost certain to lead to calculation inconsistencies. Even though EDGAR does not reject filings that have calculation inconsistencies, when a filing does have calculation inconsistencies, it is an indicator of sign problems.
Understandably, though, it is desirable to automate a warning that does not miss violations, and it is important to do so while not flagging too many 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.
The following is a sequence of some of the filters that tools should support.
- Identify exactly one income statement and one balance sheet statement in the filing, and enforce 6.8.11 for all custom elements presented in those presentation groups.
- Identify potential violations of 6.15.2 (see separate note).
- Resolve all calculation inconsistencies that occur in contexts with an instant or end date at the end of the reporting period.
- If there is a detailed note with consolidation eliminations, resolve calculation inconsistencies there also.
- Identify all contexts with an odd number of reversing axis/member combinations. As noted above, these “negating contexts” reverse the natural sign of numeric facts.
- Inspect facts with positive values in negating contexts.
- Any remaining numeric facts should be manually inspected if:
- they do not appear in calculation relationships, and
- they have negative values and are not in a negating context; or
- are presented with negating labels.
- they do not appear in calculation relationships, and
These filters highlight the general principles that (a) EFM 6.8.11 and 6.15.2 are intended to reduce the frequency of improperly reported negative fact values (b) calculation relationships are an important tool for identifying facts with incorrect signs, and (c) both negating labels and negating contexts are known trouble areas.