|Home | Jobs |
Fast Answers | Site Map | Search
Staff Interpretations and FAQs Related to Interactive Data Disclosure
Last Update: January 26, 2016
From time to time, the staff of the Division of Economic and Risk Analysis will publish interpretations and FAQs to help filers understand how to comply with the Commission's interactive data disclosure rules.
The answers to these frequently asked questions represent the views of the Staff of the Division of Economic and Risk Analysis. They are not rules, regulations or statements of the Securities and Exchange Commission. Further, the Commission has neither approved nor disapproved them.
For further information please also review the Division of Corporation Finance's Compliance and Disclosure Interpretations for Release 33-9002.
Question A.1 (formerly Question 1)
Q: Are submissions under the Voluntary Filing Program (VFP) validated the same way as those under the mandatory program adopted in Release 33-9002?
A: No. Interactive Data submissions are EX-101 attachments validated according to EDGAR Filer Manual Chapter 6. VFP Data submissions are EX-100 attachments validated as in EDGAR Filer Manual Chapter 5.
Question A.2 (formerly Question 2)
Q: How does the EDGAR validator validate HTML embedded into Block Text?
A: In all SEC submissions and attachments (other than Ex. 100 and Ex. 101), EDGAR rejects HTML that does not conform to a restriction of HTML 3.2 DTD, in particular rejecting anything that could pose a security threat to a recipient. On that general principle, the EDGAR Validator will analyze Interactive Data content that, when un-escaped, may be interpreted as HTML, and will reject it if it contains content that the existing DTD would reject. EDGAR Filer Manual Rules 6.5.15 and 6.5.16 address this currently. Note that Block Text content must also be well formed XML. This is a stronger requirement than validating against the EDGAR HTML 3.2 DTD.
Q: How can I tell whether a warning or an error from my test filing validation is related to XBRL and what would have happened if the filing had been live?
A: An EDGAR filing can be accepted with ‘Warnings’ even if some of its attached exhibits have errors. Exhibits that have errors are stripped from the filing before it is accepted into EDGAR. XBRL files are exhibits. Therefore, an error message that looks like this “WRN: XBRL Error…” means that the XBRL files will be stripped from a live filing, but the rest of the filing will be accepted into EDGAR. If this happens the filer must submit an Amendment with the corrected XBRL.
A message that looks like this “WRN: XBRL Warning…” means that there is a minor error in the XBRL exhibit, but the XBRL file will not be stripped. We encourage filers to fix these errors in their subsequent filings. A message that looks like “ERR:” or “WRN:” but does not mention XBRL is not an XBRLproblem, and is due to some other aspect of the submission.
Question B.1 (formerly Question 4)
Q: Can I still view submissions made under the Voluntary Filing Program?
A: No. The older Voluntary Filing Program Data Viewers are separate from the Interactive Data Viewer and are currently not supported by the SEC.
Question B.2 (formerly Question 5)
Q: If a filer uses the Interactive Data Previewer, is there any guarantee that end users will see the same rendering?
A: Yes. If Interactive Data pursuant to the rules in Release No. 33-9002 is previewed using the Interactive Data Previewer, then the rendering will be the same.
Question B.3 (formerly Question 6)
Q: How do I ensure that a statement renders with periods as rows rather than as columns, with a specific axis as columns, ignoring some axis, or other arrangements?
A: There are some rules in the EDGAR Filer Manual oriented toward rendering. For example, EDGAR Filer Manual rule 6.7.12 explains how to order the pages to be rendered from a submission by manipulating the link:description element of link:roleType declarations, rule 6.13.4 describes how parentheticals should be arranged in the presentation linkbase, etc.
The general approach of the rendering engine is to infer layout from the contents of the instance first, then use the presentation linkbase to adjust it, then use key words in the role definition to further adjust it. Here are the basic rendering strategies:
The personal renderer, which can be downloaded from http://www.sec.gov/spotlight/xbrl/renderingenginelicense.htm, contains a document with more detailed information about the personal renderer and how it works.
Question B.4 (formerly Question 7)
Q: Will Inline XBRL submissions be accepted in the future?
A: The conditions under which Inline XBRL may be accepted, and how the processing may be integrated into the EDGAR validation and the Interactive Data Viewer processes have not yet been determined.
Question B.5 (formerly Question 8)
Q: What does the Interactive Data Previewer do with filings that do not pass validation?
A: The previewer does not test the validity of the filing; you must do this separately either by submitting it as an EDGAR test filing or using a commercial validation software product that tests filings against the Commission's rules. The previewer renders invalid filings as best it can, but may fail in a way that does not identify the root cause. Additionally, the previewer may produce results that “look” right, even if the filing has errors that could cause the XBRL to be removed from a live filing if submitted For these reasons, we encourage the use of a test filing prior to final submission.(See A.3).
Question B.6 (formerly Question 9)
Q: How do I arrange for facts with different types to appear on the same row?
A: For the most part, the viewer cannot render facts of different types on the same row.
The rendering engine does have the ability to render complex dimensional data layouts, including rows with a mix of data types, by “embedding” table layout commands into text blocks; this is described in the Risk/Return Rendering guide (see C.1).
Question B.7 (formerly Question 11)
Q: I got some of the label linkbases for my submission from a site that used xml:lang="en" instead of xml:lang="en-US", will they render correctly?
A: It does not matter whether they render correctly in the previewer or not, the submission should be rejected by the Validator if facts use a mix of "en" and "en-US" labels. (See B.5).
Question B.8 (formerly Question 12)
Q: Why is some of my escaped HTML rendering as raw HTML?
A: Make sure that the embedded HTML appears inside of elements whose type is nonnum:textBlockItemType. It is not enough for the element name to end with "TextBlock". Different versions of the XBRL US GAAP Taxonomy may have more or less consistent element naming conventions, but it is the element type that is important, not the element name. See EFM 6.5.16 for examples of correct escaping.
Question B.9 (Reserved)
Question B.10 (formerly Question 21)
Q: What does it mean for the presentation to "match" the original HTML/ASCII document?
A: EDGAR Filer Manual rule 6.13.1 states this requirement more precisely. The presentation relationships within a given role (for a statement, say) must be the same as the original ordering. Also, the indentation of real financial statements is much "flatter" than the deep nesting of a typical standard taxonomy, and the presentation linkbase should reflect that. Also, EDGAR Filer Manual rule 6.13.4 forces parentheticals out of the main statement roles, and into separate roles specifically for parentheticals.
This is why standard presentation linkbases are usually not in the list of taxonomies on the SEC website. Consider: the element order must match the order of the Original HTML/ASCII file. If a standard presentation linkbase (for a statement or a disclosure) were included in the DTS of an instance, then any change of order (due to a difference in materiality, for example) would require both a prohibiting relationship as well as the new label. In the case of the XBRL US GAAP Taxonomies 1.0 standard presentation linkbases, only a small percentage of those presentation relationships even in the smaller statements and disclosures are likely to be a match to the ordering of a filer's financial statements. The EDGAR Validator lets the filer construct the presentation order appropriate for the instance, and requires no other presentation relationships. A filer should expect their company presentation linkbase to change in some way with every new filing, though perhaps not as much as the instance and labels change.
Question B.11 (formerly Question 32)
Q: How do I make a text block appear by itself in a presentation link role as 6.12.3 seems to require? Do I have to provide a heading?
A: The way to satisfy these rules is to use an abstract to be the parent of the text block, in each of the separate roles. For example,
06100 — Disclosure — Business Segments (Level i)
06101 — Disclosure — Oil Reserves (Level i)
And so on.
Question B.12 (formerly Question 41)
Q: Should filers use a certain naming convention for presentation group titles?
A: As noted in B.3 above, EFM section 6.7.12 describes the technical format of the presentation group “description” field, of which the “Title” is one part. While there is no requirement to follow a standard naming convention for the Title, we encourage filers to use the presentation group titles described below:
Also, EFM section 6.7.9 defines the technical format of the presentation group’s ‘roleURI’ attribute which ends with a “mnemonic name in LC3 format”. It is not necessary for that mnemonic name to match the group title word-for-word.
Q: Should filers use a certain ordering convention for presentation groups?
A: The rendering engine has been updated to allow users to more easily navigate through the rendered interactive data. Hyperlinks to sections of the filing are now grouped under expandable standard headings. This navigation structure is based on the presentation group ordering currently in use by virtually all filers, so filers should not need to change their existing presentation group ordering to use this structure. Information is provided here to show the standard headings and give examples of presentation groups found under each heading, and for troubleshooting purposes if filers experience an unexpected result with this structure.
To take advantage of this navigation structure, presentation groups should appear in the following order:
The following table shows the standard headings in the navigation structure and the presentation groups that appear under each of the standard headings. If the presentation groups are in a different order, groups may inadvertently appear under the Uncategorized heading. For example, if “Policy” appears after “Table”, all groups after “Policy” will appear under the Uncategorized heading. Note that using the plural form in a presentation group name, for example “Statements” or “Policies”, will not affect whether the group appears under its designated standard heading.
Q: How should EFM 6.6.7, 6.6.8, 6.6.9, 6.6.10, and 6.13.3 be considered when modeling dimensions on the face financial statements?
A: When applying dimensional modeling to the face financial statements, the XBRL viewer is programmed to render line items with an Axis (dimensions) after those without an Axis (dimension). Due to this rendering programming, it will not be possible to satisfy the requirements of EFM 6.6.7 through 6.6.10 and 6.13.3. Therefore, when using dimensions on the face financial statements, one should apply EFM 6.6.7 through 6.6.10 rather than EFM 6.13.3
Question B.15 (02/05/2013)
Q: When tagging a line item with multiple text descriptions in the original HTML presented in a roll forward for 3 years, the line item element requires three different negating labels which limit the available label roles, does rule 6.11.1 still apply?
A: Yes, to accommodate this scenario, merge the text from the three periods in a way that is readable and does not lose any information.
Q: Is there any guidance published by the SEC on XBRL for risk return summary filings?
A: Yes. Please click on the following link to find the Mutual Fund Risk Return Summary Preparers Guide: http://xbrl.sec.gov/rr/2012/rr-preparers-guide-2012-03-26.pdf.
Also please click on the following link to access the Mutual Fund Risk Return Summary rendering guide, http://xbrl.sec.gov/rr/2010/rr-rendering-2010-02-28.pdf.
Question D.1 (formerly Question 15)
Q: Which files from a standard taxonomy can an Interactive Data submission refer to?
A: The schema files of a taxonomy that define elements, types or roles are listed on the SEC website (http://www.sec.gov/edgar/info/edgartaxonomies.shtml) as soon as the taxonomy is available for use in EDGAR.
Linkbase files of a taxonomy cannot generally be used except in specific circumstances, in which case the linkbase will appear in the list. Specific circumstances may include:
Entry point schemas (schemas with no elements or types but only linkbase references) will generally not be allowed, except where they support exceptions (a) and (b) above.
Question D.2 (formerly Question 16)
Q: What does it mean to "use the US GAAP Taxonomy" if EFM 6.3.6 prohibits a filing from referring to the US GAAP Taxonomy schema files?
A: US GAAP Taxonomy linkbases are to be used as templates to copy from during the preparation process, but their inclusion in an EDGAR filing tends to load unused linkbases and therefore introduces unwarranted complications such as unused extended links and a need for many prohibiting relationships. Reducing the amount of content in the DTS of the instance to its essentials frees users to more easily link the submitted documents to the linkbases of their particular interest for analysis.
Question D.3 (formerly Question 17)
Q: What does it mean to "use the C&I Industry Taxonomy" if the filing cannot refer to C&I Taxonomy linkbases?
A: As EDGAR Filer Manual rule 6.6.29 says:
The calculation, definition, and presentation linkbases published along with standard taxonomies schemas are extremely useful ways to communicate how elements are related to each other, but these linkbases are to be used as templates by preparers to build their own linkbases to communicate their own intended relationships. Also, any element in a standard taxonomy schema may be used in an instance that has the schema in its DTS independently of which "industry" linkbases it might have appeared in. Therefore it is the elements standing by themselves with their definitions, references and attributes that are definitive.
Question D.4 (formerly Question 18)
Q: Do all the rules in EDGAR Filer Manual chapter 6 apply to the standard taxonomies?
A: No. The rules in EDGAR Filer Manual chapter 6 apply to company extensions and instances. Although the standard taxonomies are consistent with many of the EDGAR Filer Manual rules, here are some exceptions:
Question D.5 (formerly Question 19)
Q: Does 6.9.3 forbid the use of 'prohibited' arcs because such an arc would then cause some arc to be 'ineffectual'?
A: The rule applies only to arcs in the company extension taxonomy. If the company extension taxonomy has a 'prohibiting' arc that prohibits an arc in a standard taxonomy, then it's the standard taxonomy that has the 'ineffectual' arc, not the company extension.
Q: EDGAR Filer Manual rule 6.5.21 requires some forms to contain a “Document Fiscal Period Focus” entity information element in the Required Context. What values should filers use for this element?
A: Filers should use the following values:
FY — Fiscal Year, used for annual filings
Q1 — First Quarter of the fiscal year, used for Form 10-Q filings
Q2 — Second Quarter of the fiscal year, used for Form 10-Q filings
Q3 — Third Quarter of the fiscal year, used for Form 10-Q filings
Question D.6.1 (02/05/2013)
Q: I am preparing a FORM 10-KT for a period other than 12 months (e.g., 1/1/2012 thru 8/31/2012), should I use “FY” for the DocumentFiscalPeriodFocus?
Question D.7 (02/05/2013)
Q: I am preparing a company's FORM S-4 that also includes XBRL for the acquiring company. Should I include the EntityCentralIndexKey element with our CIK number for the acquiring company?
A: You must provide one EntityCentralIndexKey element in the required context and it should be for the parent (consolidated) company. Note that required contexts are distinguished by having no xbrli:segment elements (e.g., dimension members).
Question D.8 (02/05/2013)
Q: Once a new taxonomy (e.g., US GAAP taxonomy) is approved and available for use, when should a filer make the transition to the new version?
A: The U.S. GAAP taxonomy is subject to accounting standards and changes. In general, we only support two versions of the U.S. GAAP taxonomy at one time. Indication that the updated taxonomy is available for use will be made via the standard taxonomies page at http://www.sec.gov/info/edgar/edgartaxonomies.shtml. The SEC staff strongly encourages filers to use the most recent version of the US GAAP taxonomy release for their Interactive Data submissions to take advantage of the most up to date tags related to new accounting standards and other improvements.
Question E.1 (formerly Question 3)
Q: Characters that are "special" are forbidden by EDGAR Filer Manual 6.10.6 but they appear in the Original HTML/ASCII, so how do I get them into labels?
A: Use the XML numeric character codes from the column titled Character Reference (Dec) of the table in section 184.108.40.206.
Question E.2 (formerly Question 20)
Q: What does it mean for an element label to be "the same" as the original HTML/ASCII document?
A: EDGAR Filer Manual rule 6.11.1 states this more precisely. Roughly speaking, all the contents of the Original HTML/ASCII Document must appear somewhere in the EX-101 attachments, and all contents of the EX-101 attachments must appear somewhere in the Original. The rules adopted in Release 33-9002 do not require identical appearance, and neither does the EDGAR Filer Manual. Achieving adequate correspondence is the source of many of the "semantic" rules in EDGAR Filer Manual Chapter 6.
This is why standard label linkbases are usually not in the list of taxonomies on the SEC website. Consider: all element labels must match the exact wording in the Original HTML/ASCII file. If a standard label link base were included in the DTS of an instance, then any label that would be different would require both a prohibiting relationship as well as the new label. In the case of the XBRL US GAAP Taxonomies 1.0 us-gaap standard label linkbase, the file is 9MB, containing some 12,000 element labels, yet a very small percentage of those are ever likely to be an exact match to the line item of a filer's financial statement. The EDGAR Validator lets the filer assign a label to each element that is used in the instance, and requires no other labels. A filer should expect their company label linkbase to change in some way with every new filing, just as the instance will change.
Question E.3 (formerly Question 22)
Q: Am I required to use existing linkbase roles or make up my own? Can they change with every submission?
A: EDGAR Filer Manual rule 6.7.12 explains that filers should develop an ordering and naming scheme that is appropriate to the organization of their Original HTML/ASCII Document while supporting a sensible (though obviously not identical) rendering. That implies filer-specific roles. Changing the roles frequently is akin to frequently changing the elements used in the instance: there is no rule against it, but given such freedom to define the roles at the outset, a reasonable amount of forethought should lead to a stable arrangement.
Question E.5 (Reserved)
Q: The submission I am tagging requires the public float, so what context should I use?
A: Please refer to the EDGAR Filer Manual section 6.5.21 for examples of the required context.
Q: Am I required to put in a value for AmendmentDescription when I set the value to true for the AmendmentFlag?
A: Yes. AmendmentDescription should be a nonempty fact if and only if the AmendmentFlag is set to true (EFM 6.5.20).
Question E.8 (Reserved)
Question E.9 (formerly Question 28)
Q: Can the content of a text block be in a language other than US English (“en-US”)?
A: Yes. Starting with the 2009 US-GAAP taxonomy, a filer may use a language other than US English; Please see EFM 6.5.14 for conditions..
Question E.10 (formerly Question 29)
Q: Since the target of the dimension-default and dimension-domain relationships must be a domain or member, why not also the domain-member relationship?
A: That restriction would not work because the domain-member relationship also represents the hierarchy of primary items.
Question E.11 (formerly Question 30)
Q: Does 6.16.2 allow for multiple dimension-default effective arcs as long as they all have the same source and target?
A: Note that XBRL Dimensions 1.0 specification would require a validation error to be signaled if the targets were different, no matter in which link role they appeared. Furthermore, if the duplicated arcs had the same link role and priority one of them would be ineffectual and thus forbidden by rule 6.9.3.
Question E.12 (Reserved)
Question E.13 (formerly Question 33)
Q: EDGAR Filer Manual 6.7.10 seems redundant with XBRL 2.1's prohibition on duplicate role declarations.
A: XBRL 2.1 forbids duplicate role declarations in a schema file; 6.7.10 applies to the entire DTS.
Question E.14 (formerly Question 34)
Q: EDGAR Filer Manual 6.8.1 seems to contradict Section 405(c)(1) of Regulation S-T (17 CFR §232.405(c)(1)), which requires each data element and label contained in the Interactive Data File to reflect the same information in the corresponding data in the Related Official Filing.
A: Section 405(c)(1) of Regulation S-T (17 CFR §232.405(c)(1)) takes precedence.
Question E.15 (formerly Question 36)
Q: Should elements for line items appearing with a dash ("-") in the original HTML/ASCII version be tagged with a "0"?
A: A filer may simply not tag the element for line items appearing as an empty field or a dash. For example, if "Notes Receivable" appears on the balance sheet with a $1,000 balance this year-end and a dash last year-end, the filer can simply not tag the "Notes Receivable" element for last year's balance. Taking this action will render an empty field by our rendering engine for last year's balance. Our rendering engine will not currently render dashes. If the filer wants to tag one or more line items that appear with an empty field or a dash with a zero value because that's what management believes the item represents, and they think the distinction is useful, they can choose to do so. This guidance applies to all the financial statements, including the statement of shareholder's equity, the financial statement schedules, as well as to footnote data tagged at Level IV.
For the Commitments and Contingencies line item on the balance sheet where all columns are either blank or have dashes, the filer should set the NIL attribute to true without tagging the element with any information. This guidance is described under Edgar Filer Manual Section 6.6.15. Taking this action will render an empty field under all columns by our rendering engine.
Also, a filer may have a line item such as Preferred Stock on the balance sheet where all columns are either blank or have dashes. This could be the case when there are authorized shares, but none are issued. To tag monetary items such as this, the filer can set the NIL attribute to true without tagging any information, similar to the Commitments and Contingencies line item as described above. Taking this action will render an empty field under all columns by our rendering engine. Alternatively, the filer can tag the element with zeros if they believe the distinction is useful.
Question E.16 (Updated 02/05/2013) (formerly Question 38)
Q: Should filers use the pre-defined table structures and axes in the US GAAP Taxonomies?
A: We strongly recommend that filers utilize the pre-defined table structures and axes as they exist in the US GAAP Taxonomies. Creating new hypercubes (tables) and dimensions (axes) should generally be avoided. Custom tables and axes have a negative impact on analysis of the financial information affecting comparability and should be avoided wherever possible. In addition, filers should also avoid creating new domains or changing default member elements for pre-defined dimensions.
For example, when filers are tagging a Property, Plant and Equipment note at Level 4, they should use the pre-defined dimensional Schedule of Property Plant and Equipment [Table], and axes; extending members or line items only when necessary. Similarly, filers tagging components of inventory presented with columns for each balance sheet period should use the pre-defined non-dimensional elements for that disclosure.
Question E.17 (formerly Question 43)
Q: What are some of the nuances associated with preparing an interactive data file in situations involving separate entities filing a single set of financial statements, where multiple CIKs are concerned—such as by a filer who is a consolidated parent company with wholly-owned subsidiaries (which have their own CIKs), or by dual listed companies with their own CIKs?
A: The Division of Corporation Finance's Compliance and Disclosure Interpretation for Exchange Act Forms 104.16 explains that, in cases of dual listed companies the filer may choose which CIK to use but should continue to use that CIK in every filing as long as the companies continue to be dual listed and file joint reports. Though not addressed in a CDI, in the consolidated parent company case, the CIK of the consolidated parent company must be used. In either of the aforementioned cases, that CIK must then be used uniformly throughout all the XBRL "identifier" elements in each filing, and the same CIK must be used in the identifier element consistently in every filing thereafter. This entity is referred to as the Consolidated Entity and is the "default legal entity," as described in EDGAR Filer Manual rule 6.6.3. When the facts about more than one entity are contained in a single instance document, it is known as a "consolidating instance" (see EDGAR Filer Manual rule 6.6.4). EDGAR Filer Manual rules 6.6.3 through 6.6.8 detail how to model a consolidating instance, and while they have been summarized in the table below, filers should consult the EDGAR Filer Manual for complete details.
EDGAR Filer Manual rules 6.6.3 through 6.6.8 contain examples and detail the technical structure of the dei:LegalEntityAxis, domain, and members. Additional information can also be found on the Public Seminar on Interactive Data Reporting Requirements Webcast, held Wednesday, June 10, 2009. Part 2 of the archived webcast, at approximately the 20 minute mark, provides additional detail about the multiple-registrant reporting scenario. Slide numbers 38-41 from the Panel 2 Slides (the slide deck which accompanies the webcast) specifically pertain to this portion of the webcast.
Question E.18 (formerly Question 44)
Q: Can I report the CIKs associated with the various subsidiaries as referred to in Question E.17?
A: Currently, the CIKs of subsidiaries are not required to be reported within the single set of financial statements that satisfy the reporting obligations of reports such as Form 10-K. Because of that, the CIKs associated with the various subsidiaries are not required in the respective dei:EntityCentralIndexKey. The EDGAR system allows their inclusion but does not require them. For example, suppose the consolidated entity has a (hypothetical) CIK 9876543210. Then all of the "identifier" elements in the instance must contain 9876543210, and the value of dei:EntityCentralIndexKey in the Required Context must be 9876543210, and the value of dei:RegistrantName in the required context must be the name of the entity with CIK 9876543210. But suppose another (hypothetical) CIK, 8765432109, is reported in the same instance for subsidiary Abcd. In that case the filer may, but is not required to, include facts for dei:EntityCentralIndexKey and dei:RegistrantName that are in a context for which the dei:LegalEntityAxis has the member AbcdMember.
Q: What context period should be used for an event that occurred during the second quarter for a 12/31 fiscal year end registrant?
A: For an element with period type ‘instant’, if the disclosure includes the actual date, then use the date on which the event occurred. If the disclosure mentions that the event occurred in the month of May, then use the last day of the month, e.g. 5/31. If the disclosure only mentions that it occurred in the second quarter, then use the second quarter reporting end date of 6/30. For an element with period type ‘duration’, if the disclosure mentions that the event occurred in the month of May, then use the duration period 5/1 to 5/31. If the disclosure only mentions that it occurred in the second quarter, then use the second quarter period of 4/1 to 6/30.
Question E.19.1 (02/05/2013)
Q: What context period should be used for a duration element when the actual date is specified (e.g., "on Sep 14, 2012")?
A: A duration period may use any period that EDGAR validation will allow and whose end date reflects the specified date.
Q: EDGAR Filer Manual rule 6.8.6 prohibits the use of company-specific or period-specific information in element names. Does this apply to all item types?
A: EFM 6.8.6 applies to elements with item types other than ‘domainItemType’. 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 member with the name "AbcSegmentMember".
Q: How are units (units of measure) used in an interactive data filing?
A: Every amount in an XBRL submission is associated with an XBRL item type, an underlying data type, and a unit (short for “unit of measure”), determined by the element selected and the nature of the amount being reported. Common XBRL item types include Monetary, Shares, Decimal, Integer and Pure. These may be further distinguished as to data type, which could be the same as the item type or a specialization of it; for example, the Monetary data type allows any number to appear; the Non Negative Monetary data type excludes negative amounts. The US GAAP taxonomy and SEC taxonomies mainly use data types defined in XBRL 2.1 itself or in the standard Data Type Registry (DTR).
The XBRL item type and data type are still not enough in most cases to completely define an amount, and so XBRL 2.1 requires every amount to have a unit. In this way, XBRL item types, particularly Decimal or Integer item types, use units to further distinguish the nature of the amount. For example, the unit used for earnings per share amounts reported in US dollars is “USD per Share”. Specialized units also are used to report nonmonetary measurements. For example, amounts may be reported in units of measure such as megawatts, millions of barrels, millions of bushels, or employees.
The Pure XBRL item type is used with elements that describe percentages, rates, and ratios, and typically use the Pure unit. However, the staff has observed some filings to date in which the Pure unit has been used for other item types. The staff recommends as a best practice and to promote consistency and comparability that the Pure unit only be used with the Pure XBRL item type, and not with other item types. Additionally, the staff recommends that the Pure unit be used only for amounts which are percentages, rates or ratios.
Under EFM 6.5.35, if a standard numeric data type registry namespace is in the DTS of an instance, then the unit used for an item type must be the unit listed in the registry for that item type. Currently, the standard units registry is not yet available. The Staff expects that it eventually will be included in a future version of the DEI (Document and Entity Information) Taxonomy and notice will be provided of its inclusion. Until it becomes available, the staff recommends as a best practice that filers select the unit type that most closely fits with the item and data type. The following table gives examples of commonly used XBRL item types, data types and corresponding units:
Q: Can an interactive data submission contain more than one EX-101.* attachment of any given type?
A: It depends on the type. Only one EX-101.INS (instance) is required and allowed. However, as EFM 6.3.10 implies, the submission must contain at least one EX-101.SCH (schema) but may contain more. In general there can be any number of EX-101.PRE (presentation linkbase), EX-101.LAB (label linkbase), or EX-101.DEF (definition linkbase) attachments (EFM 6.8.2). The total number of attachments is subject to any overall limit on attachments imposed by EDGARLink Online.
Additionally, EFM 6.7.4 and 6.7.5 together allow the targetnamespace attribute of each schema to have formats such as “http://example.com/20111231”, “http://x.example.com/20111231”, “http://y.example.com/20111231” and so forth.
Question E.23 (02/05/2013)
Q: Can a company extension schema contain unused elements and their linkbase relationships (e.g., presentation, calculation)?
A: Yes. Unused elements (i.e., those elements which do not appear in the current instance document exhibit) and their linkbase relationships may be contained in the extension schema to simplify maintenance and reuse (e.g., between quarterly and annual reports) of the extension schema. However, it is recommended that unused elements and relationships that serve no further purpose be removed from the extension schema.
Question E.24 (02/05/2013)
Q: Are calculations allowable for elements with amounts outside of a “required context”?
A: Yes, calculations that meet the EDGAR Filer Manual rules for calculation linkbases (see EDGAR Filer Manual rules in sections 6.14 and 6.15) outside of a required context are optional. Note that required contexts are distinguished by having no xbrli:segment elements (axes and dimension members).
Question E.25 (02/05/2013)
Q: My FORM 10-K includes line items in the original HTML/ASCII that come under the EDGAR Filer Manual calculation rules in sections 6.14 and 6.15. However, those same line items are presented in both a primary statement and a footnote. Furthermore, the footnote contains additional line items which are not found in the primary statement. Will a single set of calculation linkbase relationships which include all required line items in the footnote satisfy the EDGAR calculations requirements for both sets of items?
A: Every required calculation relationship applies to the entire filing. An element should be the source (e.g., current liabilities) of only one calculation relationship for any one target (e.g., current portion of long-term debt), without regard for base set (e.g., balance sheet, debt footnote). See EDGAR Filer Manual section 6.15 for additional detail.
Question E.26 (02/05/2013)
Q: If a company changes its name or ticker symbol, should the XBRL file names and recommended namespace prefix be changed to conform to the new name?
A: EDGAR Filer Manual rule 6.3.3 indicates that document names should begin with the registrant’s ticker symbol or some other mnemonic abbreviation and should be the same as that used for the instance in the same submission. Although not a requirement, if a company subsequently changes names or ticker symbols, we suggest the file names and recommended namespace prefix mnemonic abbreviation be updated to reflect the change.
Question E.27 (New 01/26/2016)
Q: What are the conditions for determining when a calculation relationship is required?
A: The Commission's rules require filers to include calculation relationships for certain contributing line item elements for financial statements and related footnotes. Required calculation relationships in XBRL company taxonomies provide key information that shows the relationships among elements and their corresponding numeric facts, and how they add and subtract to each other. In addition, required calculation relationships enhance data quality by:
The EDGAR Filer Manual (Volume 2), Chapter 6, Sections 6.14 and 6.15 set out specific calculation relationship requirements, including certain examples and exceptions. Section 6.14 addresses the syntax restrictions of calculation relationships. Section 6.15 addresses the content of calculation relationships.
Item 6.15.2: Determining when calculation relationships are required
Item 6.15.2 of the EDGAR Filer Manual states:
"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."
If a line item satisfies all of the following five conditions, as set out by Item 6.15.2, the line item requires a calculation relationship:
Condition 1. In the HTML/ASCII filing, does the line item appear in either the financial statements or the footnotes? (Note: If the line item appears in both the financial statements and the footnotes, you should answer "yes" to this question.)
Condition 2. In the HTML/ASCII filing, does the line item appear with at least one other line item and the net or total of those line items?
Condition 3. Does the line item belong to a context period that represents a duration or an instant that has the same end date as the Required Context (See Item 6.5.19 of the EDGAR Filer Manual)?
Condition 4. Does the line item have a corresponding numeric fact in the instance document?
Condition 5. Does the numeric fact appear in the instance document with at least one other numeric fact other than the net or total?
Additional questions related to Item 6.15.2:
Question F.1 (formerly Question 37)
Q: Should the formatting of footnote tables that result from tagging at Level 4 match exactly the format presented in the original HTML/ASCII version?
A: No. There is no requirement that facts tagged at Level 4 render in such a way to match the formatting in the original HTML/ASCII version. For example, the axes may be reversed in the XBRL table structure from that presented in the original HTML/ASCII version and there may be blank cells in the XBRL table structure where "-" appear in the HTML/ASCII version. In addition, facts appearing within the same footnote in the original HTML/ASCII version may be incorporated into the table structure for tagging purposes.
Question F.2 (formerly Question 40)
Q: Does the EDGAR Filer Manual rule 6.8.6 limiting the use of company-specific elements apply to tagging at Levels 2, 3, and 4?
A: Yes, but see the clarification in Question E.20.
Question F.3 (02/05/2013)
Q: Outside of the primary financial statements, is superscripted text at the bottom of a footnote table allowed to be included in an XBRL footnote link element?
A: Yes, including the superscripted text at the bottom of a footnote table in an XBRL footnote link is optional. Note that any required amounts in superscripted text must be separately tagged as part of Level 4 tagging requirements.
Question F.4 (02/05/2013)
Q: When tagging a narrative disclosure using "no" or "none" such as "There were no impairment losses for the years ended December 31, 2012, 2011, and 2010, respectively should a value of zero be tagged for each of the disclosed periods”?
A: In general, if you can replace the word "no" or "none" with a zero and it does not change the meaning of the sentence, then you are disclosing an amount. From Compliance and Disclosure Interpretations - Regulation S-T Question 130.04 - “Each amount, whether expressed numerically or textually, must be tagged separately under Rule 405(d)(4)(i). This guidance also applies to tagging each amount within the financial statement schedules under Rule 405(e)(2)(i) of Regulation S-T. Each tagged amount must be mapped to the applicable monetary, decimal, percent, integer or shares data type element”.