Common EFM References

Commonly cited sections from EDGAR Filer Manual (EFM). Quotes from EFM (Volume II) EDGAR Filing (Version 52) September 2019.

Start & End Calendars

6.5.9 Pairs of contexts must not overlap by 24 hours or less

"If the duration of a context is more than 24 hours, then its endDate datetime value must be greater than the startDate datetime of any other context by 24 hours or less.
...
For example, a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the beginning of 2008-06-01 (the current fiscal year). It must not have any contexts with start date of midnight at the beginning of 2008-05-31, and no contexts with end date of midnight at the end of 2008-06-01."

More Precise Values

6.5.12 Fact Duplication

"An instance must not have more than one fact having S-Equal elementThe representation of a financial reporting concept, including: line items in the face of the financial statements, important narrative disclosures, and rows and columns in tables. names, equal contextRef attributes, and if they are present V-Equal unitRef attributes and xml:lang attributes effective values, respectively, unless their values are consistent, as described below, in which case the distinct facts are consolidated into a single fact for all other validations.
...
For numeric facts, all such values must be consistent with having been rounded from a single value. ...
Consistent numeric facts are consolidated into a single fact having the value of the fact with the maximum specified decimals value for purposes of validation and rendering.

For non-numeric facts, the values are consistent only if they are V-Equal.
...
Calculation inconsistencies have no impact on the validity of EDGAR submissions, and therefore the effect of numeric fact duplication in XBRLExtensible Business Reporting Language (XBRL) is an XML-based standard for defining and exchanging business and financial performance information. 2.1 section 5.2.5.2 is moot."

Required DEI Tags

See tables of required tags in section 6.5.20 and 6.5.21.

6.5.21 The required contexts must contain all required entity information facts.

"An instance must contain one non-empty fact for each required Entity Information element, each with a contextRef attribute referring to a Required Context. The value of an EntityPublicFloat fact in an instance will be 0 for an entity that has only public debt. ..."

Non-Numeric Data

6.6.1 Fiscal year contexts for non-numeric facts.

"In an instance reporting a fiscal year, non-numeric facts containing text about any portion of that or a prior year must have a contextRef attribute to an xbrli:context for the reporting period year. For example, in a fiscal year 2009 report a company describes litigation settled in fiscal 2007. Nevertheless, the disclosure text should be in a context for fiscal 2009. A reporting period begins at 00:00:00 of its first day and ends at 24:00:00 of its last day, which is the XBRL 2.1 default for periods. Only the date, not the time part of the ISO 8601 date-times, should be used in contexts."

6.6.2 Fiscal year-to-date contexts for non-numeric facts.

"In an instance reporting a fiscal year-to-date, the non-numeric facts containing text about any portion of the year-to-date or prior year must have a contextRef attribute to an xbrli:context representing the year-to-date. For example, a company completes an acquisition in its second fiscal quarter. In its 3rd quarter fiscal report, the Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context for the first nine months (that is, the year-to-date)."

Using Nil

6.6.15 Nil facts.

"The xsi:nil="true" attribute must be used only to convey a value that is different from both “zero” and different from not reporting the fact at all, or to identify a fact detailed only by a link:footnote. For example... [on the] balance sheet: Commitments and Contingencies ..."

Facts Requiring Tags

6.6.17 No extra facts.

"An instance must not contain facts that do not appear in the corresponding official HTML/ASCII document. The information in interactive data format should not be more or less than the information in the related registration statement or report, with the exception of "dei" facts required by 6.5.20, 6.5.21, 6.5.26 and 6.5.40."

6.6.22 Level 4 (Detail) Tagging

"An instance must contain separately each monetary value, percentage, and number in each footnote in the corresponding official HTML/ASCII document, as a fact, if the document type requires “level 4” tagging. An instance may also contain dates and narrative disclosures as level 4 facts. ..."

Element Selection

6.6.24 Alignment of numeric facts and element definitions

"If an element used in numeric facts representing amounts in one or more periods has a definition, then the scope of that definition must include the material amounts reported for that line item in the corresponding official HTML/ASCII document.

...

The definition is an element’s most important attribute and must be consistent with the financial concept reported. An element should be interpreted by the substantive meaning provided in its definition. Definitions cannot be changed. As important as they are, all definitions have limitations, so preparers should not base their choice of an element simply on minor, immaterial differentials in definitions. Determining whether a definition is consistent with the financial concept requires judgment, and other attributes of the element must be considered."

6.6.25 Numeric element definitions.

"An element must not be used in numeric facts representing amounts of a line item in different periods if it has a definition that explicitly excludes one or more of the material amounts in the corresponding official HTML/ASCII document. For example, the definition for element “Other Restructuring Costs” states that it “excludes costs associated with the retirement of a long-lived asset and severance costs associated with established compensation plans.”

6.6.26 Selecting elements based on definitions.

"When there is a choice among different elements that have definitions consistent with a set of facts in one or more periods, use the element with the narrowest definition. For example, while in principle, eleven possible word combinations may be derived from “depreciation”, “amortization”, “impairment”, and “depletion”, all eleven might not be included as distinct elements in a standard taxonomyDictionary-like XBRL classifications that describe the context of data in financial statements and business documents. namespace. If the line item being reported consists only of depreciation, then use an element such as DepreciationAndAmortization; do not use any of the alternative elements whose definition also includes impairment or depletion."

6.6.27 Selecting elements based on data types.

"If there is a choice among different elements whose type attribute is consistent with a set of facts in one or more periods, use the element with the most specific type attribute. For example, a footnote contains the sentence “The assumed discount rate is 2%” or, equivalently, “The assumed discount rate is two percent”. There is a numeric element declared in a standard taxonomy for the value of assumed discount rates, and another element for “assumptions”. Use the numeric assumed discount rate.

Another example is if a fact is a dollar amount and there are some potential elements that are monetary and others that are strings or text blocks, the monetary elements must be used. Similarly, “per share” dollar amounts must be tagged with “per share” elements."

6.6.28 Selecting elements based on authoritative references.

"When there is a choice among different elements having distinct link:reference elements in a standard taxonomy, use the element with the most specific reference. Reference linkbases containing link:reference elements do not have to be in the DTS of the instance as submitted but they should be used during the preparation of the instance.

For example, an element with a link:reference to a specific paragraph in a FAS is likely to be a better choice than an element that simply refers to the entire FAS. Determining whether references supporting the definition are consistent with the financial fact requires judgment, and other attributes of the element must be considered."

6.6.29 Precedence when selecting elements.

"When choosing the most appropriate element for facts in one or more periods, the element’s link:reference elements take precedence over the xbrli:periodType attribute, which takes precedence over the type attribute, which takes precedence over the element’s documentation string if present, which in turn takes precedence over the standard label string. The calculation, definition, and presentation linkbases published along with standard taxonomies schemas communicate how elements are related to each other. Preparers use linkbases that organize common sets of tags as a starting point. However, these linkbases are to be used as templates by preparers to build their own linkbases to communicate their own intended relationships. Any element in a standard taxonomy schema may be used in an instance that has the schema in its DTS independently of the calculation, definition and presentation linkbases that it might have appeared in. It is the elements standing alone with their authoritative references, period and data type attributes, and standard documentation labels that are definitive.

The name attribute of an element is a mnemonic, not a definition; do not use the name attribute of an element as a definitive indicator of its meaning."

6.6.30 Selecting signs based on the balance attribute.

"Invert the sign of a numeric fact whose element has an xbrli:balance value that is inconsistent with 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 negating 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 even if its xbrli:balance is not the balance type expected."

Digits As Shown (Precision)

6.6.32 Selecting the decimals attribute.

"The value of the decimals attribute of a fact must correspond to the accuracy of the corresponding amount as reported in the official HTML/ASCII document. The decimals attribute influences how numbers are interpreted in XBRL and any value for the decimals attribute other than the value INF implies rounding or truncation..."

Fact	Value	Value of decimals attribute
A federal tax rate of (exactly) 46%	.46	INF
An management fee of (exactly) 10 basis points	.001	INF
A (rounded) profit margin of 9.3%	.093	3
A (rounded) change in NAV of 12 basis points	.0012	4
A (rounded) inventory “in thousands” of 100	100000	-3
A (rounded) inventory “in thousands” of 100.2	100200	-2

Footnotes in Face Financials

6.6.39 Page level footnotes of the face financials.

"Text that is shown in the official HTML/ASCII document at the bottom of a page on the face of the financials preceded by a superscript must appear in the corresponding instance as the text of a link:footnote element. The content of link:footnote should not contain the superscript symbol or number originally appearing in the official HTML/ASCII document.

Financial statement “footnotes” (Notes to the Financial Statements) do not appear in a link:footnote."

6.6.40 Distinct page level footnote facts.

"Distinct texts that are shown in the official HTML/ASCII document at the bottom of a page on the face of the financials preceded by distinct superscripts must appear in the corresponding instance as the text of distinct link:footnote elements."

Choose US-GAAP Over Extensions

6.8.4 No duplicative custom element declarations.

"Wherever possible, registrants should assign a standard and other labels for an element defined in a standard taxonomy schema in preference to declaring a new element in a company schema. A standard label is a link:label element with an xlink:role attribute equal to

‘http://www.xbrl.org/2003/role/label’; other labels use other xlink:role attribute values.

Defining a company-specific element should be done only under specific circumstances discussed in items 6.8.6 – 6.8.23 with respect to each type of element.

When the disclosure intended by the preparer is effectively a synonym for a disclosure represented by the element’s authoritative references and documentation label, registrants should assign a label to the standard element, in preference to defining a custom element.

For example, there may be an element “GrossProfit.” In a standard namespace. The standard namespace does not include “Gross margin,” because this is defined the same as “Gross Profit”: both are used to mean “excess of revenues over the cost of revenues.” A registrant presenting “Gross margin” in a statement should not define a custom “GrossMargin” element; instead, use the “GrossProfit” element and define the label for this element as “Gross margin”.

Company Specific Information in Extensions

6.8.6 Use company- and period-specific names only for domainAn element that represents an entire set of other elements. The domain and its members are used to classify facts along the axis of a table. For example, "Arkansas" is a domain member in the domain "States," and would be used to classify elements such as revenues and assets in Arkansas, distinct from other states. When a fact does not have any domain member specified, it applies to the entire domain. members.

"Do not include company-specific or period-specific information in an xsd:element name attribute for elements having other than type ‘domainItem Type’. Elements with other item types, including (but not limited to) monetary, percent, integer, shares, per share, string, or text block item types, should not include company-specific or period-specific information in the element name. Domain members may include company-specific or period-specific information in the element name.

For example, filers should not create a monetary element with the name “AcquisitionOfDefCo” or “FourthQuarterAdjustment”. However, they may create a domain memberAn element representing one possible setting within a domain. with the name “AbcSegmentMember”.

Balance Attribute

6.8.11 Custom elements requiring a balance attribute.

"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. An xsd:element “appears on a statement of income or balance sheet” if the xsd:element is the target of a presentation relationship in a link:presentationLink with an xlink:role attribute with a link:definition that contains phrases such as “income,” “balance,” “financial position.”

The xbrli:balance attribute values ‘credit’ and ‘debit’ serve to disambiguate the meaning of a positive (or negative) fact value in an instance. In combination with the xbrli:periodType attribute, a user can identify all monetary facts on the income statement and balance sheet as assets, liabilities, income or expenses no matter what their name attribute."

Total Members

6.8.19 Do not declare 'total' domain member elements.

"Do not declare an xsd:element with a type attribute equal to or derived from ‘domainItemType’ in a standard taxonomy schema target namespace as an explicit “total” domain member. Elements with a name attribute ending in Domain, as the default member of an Axis, already serve as a total."

Balance Attribute for Monetary Elements

6.11.5 Monetary elements without a balance attribute.

"An xsd:element with a type attribute equal to ‘xbrli:monetaryItemType’ that does not have an xbrli:balance attribute must have a definition that disambiguates its sign. In most cases the registrant does not need to provide a definition label (that is, one with an xlink:role attribute equal to ‘http://www.xbrl.org/2003/role/documentation’. However, a special case arises when a monetary item could take on a positive or negative value in different periods, and there is potential for confusion because it is not required to have an xbrli:balanceType attribute. The registrant must therefore either assign an appropriate xbrli:balanceType attribute or assign a label with an xlink:role attribute equal to ‘http://www.xbrl.org/2003/role/documentation’ containing text that makes the meaning of a positive (or negative) value explicit.

For example, a registrant defines an element called “Other Loss Adjustments, Net” with a type attribute equal to ‘xbrli:monetaryItemType’ but does not provide an xbrli:balanceType attribute. The text of the documentation is “A positive adjustment value indicates a net increase in cumulative losses.”

Duplicate Elements in a Top Level Group

6.12.5 When distinct preferredLabel attribute values are required

"If an element used in an instance is the target in the instance DTS of more than one effective presentation relationship in a base set with the same source element, then the relationships must have distinct values of the preferredLabel attribute. This rule prevents the same fact from appearing twice in a set of line items, except when it is, for example, shown as both the beginning and ending value of a roll forward."

Calculation Link Base

.6.15.2 When calculation relationships are required

"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.
...
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."

6.15.3 Alternate calculations for a single fact.

"If a footnote in the original HTML/ASCII document contains alternate line items that sum to the same total amount, then the XBRL instance document for that footnote must have calculation relationships for the original and alternate line items in distinct base sets.

For example, a tax liability is shown in a tax footnote as the sum of current and deferred tax liabilities, and elsewhere in the same footnote as the sum of domestic and foreign tax liabilities. There are two base sets, each containing two calculation relationships."

6.15.4 Each element source and target pair should only appear in one calculation relationship.

"A fact in an instance whose element is the source of an effective calculation relationship in the instance DTS should not have the same calculation relationship target in more than one base set.

Note that this rule refers to the calculation relationship, not the element; an element can occur in any number of face financial statements or footnotes. Legitimate exceptions to this rule occur when an element is shown in different parts of the financial statement as a sum of different, but overlapping, sets of other elements.

Examples:

The income statement contains amounts pre-tax income, tax, and post-tax income. There are two line items and their net; therefore two calculation relationships are required in the base set for the balance sheet. In the tax footnote there is another occurrence of pre-tax income, tax, and post-tax income. The tax footnote does not need two calculation relationships, because the same relationship already exists on the income statement.
A balance sheet shows Net Current Receivables with a parenthetical value for Allowances. Only two values are shown, so no calculation relationship is required. A footnote also includes an analysis of (the same) Net Current Receivables including, among other details, amounts for Gross and Allowances. The footnote has those two line items and their net and therefore a need for two calculation relationships. Whether any of these facts also appear elsewhere is relevant only if it would result in duplicated relationships."