Staff Interpretations and FAQs Related to Interactive Data Disclosure
From time to time, the staff of the Division of Economic and Risk Analysis (DERA) will publish interpretations and FAQs to help filers understand how to comply with the Commission's interactive data disclosure rules.
For further information, please also review the Division of Corporation Finance's Compliance and Disclosure Interpretations for Release 33-9002.
The DERA staff have prepared the following responses to questions about EDGAR submissions with eXtensible Business Reporting Language (XBRL) data and expect to update from time to time our responses to additional questions. These responses represent the views of the DERA staff. They are not a rule, regulation, or statement of the Securities and Exchange Commission (Commission). The Commission has neither approved nor disapproved its content. These responses, like all staff statements, have no legal force or effect: they do not alter or amend applicable law, and they create no new or additional obligations for any person.
- A. Validation
- B. Presentation and Rendering — All Submissions
- C. Presentation and Rendering — Risk/Return Summaries
- D. Standard Taxonomies
- E. Company Extensions and Instances
- F. Detail Tagging
- G. Element Selection
FAQ's
A. Validation
Question A.1 (Reserved)
Question A.2
Q: How does the Electronic Data Gathering Analysis and Retrieval (EDGAR) validator validate HTML embedded into Block Text?
A: In all SEC submissions and attachments, EDGAR rejects HTML that does not conform to the EDGAR-specific restriction of HTML 3.2 or 4.0 Document Type Definition (DTD), in particular rejecting anything that could pose a security threat to a recipient. On that general principle, the EDGAR Validator analyzes Interactive Data content that, when processed, may be interpreted as HTML, and will reject it if it contains content that the existing DTD would reject. EDGAR XBRL Guide section 9.1 addresses this. Note that Block Text content must also be well formed eXtensible Markup Language (XML) as described there. This is a stronger requirement than validating against the EDGAR HTML 3.2 or 4.0 DTD.
Question A.3
Q: How can I tell whether a warning or an error from my test filing validation is related to eXtensible Business Reporting Language (XBRL) and what would have happened if the filing had been live?
A: In general, an EDGAR filing can be accepted even if some of its attached exhibits have errors. Exhibits that have errors are removed from the filing (“stripped”) before it is accepted into EDGAR. However, primary documents, such as the “10-K” attachment to submission type “10-K”, with errors (such as invalid HTML) will always result in filing suspension.
If a submission has an Inline XBRL primary document with an XBRL error, EDGAR will suspend the entire submission. See section 5.2.5 of the EDGAR Filer Manual (Volume II) for more information.
Some exhibits are XBRL files. Therefore, an error message that reads “WRN: XBRL Error” means that those files will be stripped from a live filing, but the rest of the filing will generally be accepted into EDGAR. If this happens, the filer must submit an Amendment with the corrected XBRL.
A message that reads “WRN: XBRL Warning” means that there is a less severe error in the XBRL data, but the XBRL file will not be stripped. We encourage filers to fix the warnings in their subsequent filings.
A message that starts with “ERR:” or “WRN:” but does not mention XBRL is not an XBRL problem, and is due to some other aspect of the submission.
B. Presentation and Rendering — All Submissions
Question B.1
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 no longer supported.
Question B.2 (Reserved)
Question B.3
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: Section 7 of the EDGAR XBRL Guide contains rules oriented toward rendering, including restrictions on statement rendering. Some special treatments are allowed for the Cash Flow Statement (section 7.12) and the Statement of Changes in Shareholder Equity (section 7.13).
Question B.4
Q: Do operating company financial statements and fund prospectus risk/return summary submissions need to be in Inline XBRL?
A: Yes. All relevant phase-in periods ended in September 2021. See Release No. 33-10514 and 17 CFR 232.405(f) for additional details.
Question B.5 (Reserved)
Question B.6
Q: How do I arrange for facts with different types to appear on the same row?
A: For the most part, the renderer cannot place 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 EDGAR XBRL Guide chapter 7, “Instance Rendering”.
Question B.7
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: Any label linkbase without labels in language “en-US” would never appear in the edgartaxonomies.xml file, so a submission referencing such a linkbase would be rejected by the Validator prior to rendering. When copying labels, the filer should edit the labels to use en-US.
Question B.8
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 dtr-types:textBlockItemType. It is not enough for the element name to end with "TextBlock". Different versions of the US GAAP Financial Reporting taxonomy (GAAP taxonomy) may have more or less consistent element naming conventions, but it is the element type that is important, not the element name.
Question B.9 (Reserved)
Question B.10
Q: What does it mean for the presentation to "match" the original HTML/ASCII document?
A: For a taxonomy that requires the use of specific presentation links (for example, the Self-Regulatory Organization (SRO) taxonomy) see the associated Taxonomy Guide for description of any filer-controlled presentation decisions. In custom taxonomies, as defined in the EDGAR XBRL Guide chapter 5, the presentation relationships within a custom role should be the same as the ordering in the Related Official Document as defined in the EDGAR XBRL Guide section 6.1. EDGAR XBRL Guide chapter 6 describes several different tagging decisions that affect whether the presentation will match, and chapter 7, particularly sections 7.11, 7.12, and 7.13, describe features of the renderer that will affect appearance of financial statement data.
Question B.11
Q: How do I make a text block appear by itself in a presentation link role as EDGAR XBRL Guide section 6.7.1 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 1) Segment Disclosure [Abstract] + Segment Disclosure [Text Block]
-
06101 — Disclosure — Oil Reserves (Level 1) Oil Reserves Disclosure [Abstract] + Oil Reserves Disclosure [Text Block]
And so on.
Question B.12
Q: Should filers use a certain naming convention for presentation group titles?
A: Sections 7.12, 7.13 and 10.2 of the EDGAR XBRL Guide define these conventions.
Question B.13
Q: Should filers use a certain ordering convention for presentation groups?
A: Section 7.2 of the EDGAR XBRL Guide addresses presentation groups, including rules around ordering.
Question B.14(Reserved)
Question B.15
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 EDGAR XBRL Guide section 5.10.1 last paragraph 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.
C. Presentation and Rendering — Risk/Return Summaries
Question C.1
Q: Is there any guidance published by the SEC on XBRL for Risk/Return Summary disclosures?
A: Yes. The Risk/Return Summary disclosure guidance is included in the Open-End Fund (OEF) taxonomy guide. Please visit https://www.sec.gov/data-research/standard-taxonomies/investment-companies for the latest OEF taxonomy guide.
D. Standard Taxonomies
Question D.1
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, and that may have embedded linkbases with calculation, definition, label, and presentation relationships are listed on the SEC website https://www.sec.gov/data-research/standard-taxonomies as soon as the taxonomy is available for use in EDGAR.
See EDGAR XBRL Guide chapter 6 for an overview of the relationship between filer type, submission type, attachment type, and taxonomy entry points.
Question D.2 (Reserved)
Question D.3 (Reserved)
Question D.4
Q: Do all the rules in EDGAR XBRL Guide apply to the standard taxonomies?
A: No. The rules in EDGAR XBRL Guide apply to company extensions and instances. Although the standard taxonomies are consistent with many of the EDGAR XBRL Guide rules, here are some exceptions:
- File names, namespaces, schemaLocation and xlink:href attributes of a standard taxonomy are not restricted by any of the EDGAR XBRL Guide rules.
- Element declarations: A standard taxonomy might include elements that do not follow the LC3 naming convention, non-numeric types with period type “instant”, or other variations.
- Role declarations: A linkbase xlink:role might be defined as being used on only one type of linkbase instead of all three, or its “description” field may vary from what custom taxonomies may use.
- Linkbases: Although always valid with respect to XBRL International recommendations, there may be any number of EDGAR XBRL Guide violations.
Question D.5
Q: Does EDGAR forbid the use of “prohibited” arcs because such an arc would then cause some arc to be “ineffectual”?
A: This restriction applies only to arcs in the company extension taxonomy. See validation checks in EDGAR XBRL Guide section 10.4. 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. In practice, arcs in a standard taxonomy usually have priority=10 meaning that in EDGAR they cannot be overridden at all.
Question D.6
Q: EDGAR XBRL Guide section 3.1 discusses expected facts in the required context. One of these elements in the required context is “Document Fiscal Period Focus”. 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
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?
A: Yes.
Question D.7
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 (i.e., no dimension members).
Question D.8
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: Updates to the U.S. GAAP Taxonomy are subject to accounting standard changes and taxonomy improvements. In general, we support only 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 https://www.sec.gov/info/edgar/edgartaxonomies.shtml. The SEC staff strongly encourages filers to use the most recent version of any 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.
Whether a submission uses the current year version or prior year version of the U.S. GAAP Taxonomy, the version of other taxonomies used in the submission must be compatible. In general, that would mean the same version year as the U.S. GAAP Taxonomy. The only exception to this compatibility rule is the time period between EDGAR’s acceptance of the new U.S. GAAP Taxonomy and other SEC taxonomies for that year, and the new International Financial Reporting Standards (IFRS) Taxonomy for that year, due to the IFRS Taxonomy being accepted in EDGAR at a different date.
Question D.9
Q: Where is the information on compliance dates for XBRL tagging?
A: Compliance requirements for any given filer may depend on considerations of filer type, size, fiscal year end, prior registration under the ’33, ’34, or ‘40 acts, and many other details, and this information is found in the relevant rule release text. To avoid redundancy, discrepancies and frequent updates, details about compliance dates are not repeated in EFM chapter 6, the EDGAR XBRL Guide, nor in taxonomy guides.
Question D.10 (Reserved)
Question D.11 (Reserved)
Question D.12 (Reserved)
Question D.13 (Reserved)
Question D.14
Q: Sometimes the sample instance zip files only contain the schema and HTML, and do not include linkbases. Is this the only acceptable way to file? Can filers continue to file with linkbases, and if so, for how long?
A: As long as the linkbases follow sections 5 (Custom Taxonomies) and 10 (Validation Details on Custom Taxonomies) of the EDGAR XBRL Guide, filing with linkbases is allowed.
Question D.15 (Reserved)
Question D.16 (Reserved)
Question D.17 (Reserved)
Question D.18 (Reserved)
Question D.19 (Reserved)
Question D.20 (Reserved)
Question D.21 (Reserved)
Question D.22
Q: If a closed-end fund has risk factors that are not considered principal risk factors to the fund, do those non-principal risk factors have to also be tagged?
A: Item 8.3.a of Form N-2 requires funds to discuss the principal risk factors associated with an investment in the fund specifically, as well as factors that are generally associated with investment in a fund with investment objectives, investment policies, capital structure, or trading markets that are similar to the fund’s. General Instructions I.2 and 3 of Form N-2 require information provided in response to Item 8.3.a to be tagged. Therefore, to the extent that any non-principal risk factors are disclosed in response to Item 8.3.a, the fund would need to tag those.
E. Company Extensions and Instances
Question E.1
Q: Characters that are "special" are forbidden by EDGAR Filer Manual (Volume II) 5.2.2.1 and 7.3.4.3 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 EDGAR Filer Manual (Volume II) section 5.2.2.6.
Question E.2
Q: What does it mean for an element label to be "the same" as the original HTML/ASCII document?
A: EDGAR XBRL Guide (EXG) section 5.10.1 last paragraph states this more precisely. Roughly speaking, all the contents of the Related Official Document (EXG section 6.1) 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 EXG. See EXG section 6.5 for additional discussion on the relationship of the concept being tagged and its custom label.
Question E.3
Q: Am I required to use existing linkbase roles or make up my own? Can they change with every submission?
A: Filers should develop an ordering and naming scheme that is appropriate to the organization of their Related Official 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.4 (Reserved)
Question E.5 (Reserved)
Question E.6
Q: The submission I am tagging requires the public float, so what context should I use?
A: Please refer to EDGAR XBRL Guide section 3.1.15, “Public Float”.
Question E.7
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. See EDGAR XBRL Guide section 3.1.6.
Question E.8 (Reserved)
Question E.9
Q: Can the content of a text block be in a language other than US English (“en-US”)?
A: Yes; however, EDGAR XBRL Guide section 9.9 requires instances containing a fact in a language other than US English must also contain a fact using the same element and all other attributes with an xml:lang attribute equal to “en-US”. For example, an US English fact can appear in an instance without the French fact, but the French fact cannot appear without the US English fact.
Question E.10
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 that are not themselves members.
Question E.11
Q: Does EDGAR allow for multiple dimension-default effective arcs in distinct extended-type links as long as they all have the same source and target?
A: They would be redundant, because the dimension-default arc affects the entire DTS, not just the link they appear in. 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. See EDGAR XBRL Guide section 10.4.
Question E.12 (Reserved)
Question E.13
Q: One of the validation checks in EDGAR XBRL Guide section 10.2 is the DTS does not contain more than one link:roleType having the same roleURI attribute value. It seems redundant with XBRL 2.1's prohibition on duplicate role declarations.
A: XBRL 2.1 forbids duplicate role declarations in a schema file; EDGAR XBRL Guide section 10.2 applies to the entire DTS.
Question E.14
Q: Does EDGAR XBRL Guide section 5.6.2’s discussion around the use of an updated namespace contradict Rule 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: No. The use of the same element’s local name in a subsequent version of a namespace is not considered “different” for purposes of complying with Rule 405(c)(1) of Regulation S-T.
Question E.15
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. The renderer will not 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 (with an appropriate value of the decimals attribute to indicate missing digits) 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 4.
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 xsi:nil attribute to true without tagging the element with any information. This guidance is described under EDGAR XBRL Guide section 6.3.4. Taking this action will render an empty field under all columns by our rendering engine. A different reason to use the xsi:nil attribute is that the layout of the shareholders' equity in EDGAR XBRL Guide section 7.13 may produce unwanted results when too many period start and end values are left untagged. This is a case where adding “nil” valued facts will often resolve this dilemma.
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. See also Question F.4.
Question E.16
Q: Should filers use the pre-defined table structures and axes in the U.S. GAAP Taxonomy?
A: We strongly recommend that filers utilize the pre-defined table definition and presentation links and axes as they exist in the U.S. GAAP Taxonomy. 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 copy the pre-defined dimensional Property Plant and Equipment [Table], and axes, from the U.S. GAAP Taxonomy linkbase; extending members or line items only when necessary.
Question E.17
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 Interactive Data-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 XBRL Guide section 6.2.1. When the facts about more than one entity are contained in a single instance document, it is known as a "consolidating instance" (see EDGAR XBRL Guide section 6.2.2). EDGAR XBRL Guide sections 6.2.1 through 6.2.6 detail how to model a consolidating instance, and while they have been summarized in the table below, filers should consult the EDGAR XBRL Guide for complete details.
For a Consolidated Registrant with Subsidiaries: | For Dual (or Multiple) Registrants: |
---|---|
Use the CIK of the Consolidated Entity in the instance; this is the result of complying with EDGAR XBRL Guide sections 6.2.1, 6.2.2, and 8.2. | The CIK of any of the registrants can be used as the "consolidated" entity, but it must be used consistently in subsequent filings (EDGAR XBRL Guide sections 6.2.1, 6.2.2, and 8.2). |
Create a separate domain member element for each subsidiary. Typically, the element name for subsidiary Abcd would be "AbcdMember". Use the dimension srt:ConsolidatedEntitiesAxis for subsidiaries (EDGAR XBRL Guide section 6.2.3). | Create a separate domain member element for each company other than the Consolidated Entity. Typically, the element name for Abcd would be "AbcdMember". Use the dimension dei:LegalEntityAxis for each entity that is not the Consolidated Entity (EDGAR XBRL Guide section 6.2.3). |
For facts that apply to the Consolidated Entity, do not provide any value for srt:ConsolidatedEntitiesAxis. It is the "default" member, in XBRL terminology (EDGAR XBRL Guide section 6.2.1). | For facts that apply to the Consolidated Entity, do not provide any value for dei:LegalEntityAxis. It is the "default" member, in XBRL terminology (EDGAR XBRL Guide section 6.2.1). |
Use domain member element srt:ParentCompanyMember for facts that apply only to the parent holding company, corporate headquarters, or similar legal entity not associated with any specific subsidiary (EDGAR XBRL Guide section 6.2.4). | There is no need to use a parent company element. |
EDGAR XBRL Guide sections 6.2.1 through 6.2.6 contain examples and detail the technical structure of the srt:ConsolidatedEntitiesAxis, dei:LegalEntityAxis, domain, and members.
Question E.18
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.
Question E.19
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
Q: What context period should be used for a duration element when the actual date is specified (e.g., "on Sep 14, 2021")?
A: A duration period may use any period that EDGAR validation will allow (see validations in section 9.7 of the EDGAR XBRL Guide) and whose end date reflects the specified date.
Question E.20
Q: EDGAR XBRL Guide section 5.6.3 prohibits the use of company-specific or period-specific information in element names. Does this apply to all item types?
A: EDGAR XBRL Guide section 5.6.3 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".
Question E.21
Q: What are the rules around using unit types in an Interactive Data filing?
A: See section 9.8 of the EDGAR XBRL Guide for the unit type registry restrictions.
Question E.22
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 ever allowed. However, most submissions will contain at least one EX-101.SCH (schema) but may contain more, defining different namespaces compliant with EDGAR XBRL Guide section 10.1. 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. The total number of attachments is subject to any overall limit on attachments imposed by EDGARLink Online. The number of distinct attachments can be reduced by embedding any or all of the linkbases into the EX-101.SCH attachment.
Question E.23 (Reserved)
Question E.24
Q: Are calculations allowable for elements with amounts outside of a “required context”?
A: Yes, calculations that meet the EDGAR XBRL Guide rules for calculation linkbases (see EDGAR XBRL Guide section 5.9) 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
Q: My Form10-K includes line items in the original HTML/ASCII that come under the EDGAR XBRL Guide section 5.9. 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: Yes. Every 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 XBRL Guide section 5.9 for additional detail.
Question E.26
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: Yes. 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
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:
- Providing vital context for interpretation of custom element extensions;
- Supporting company data continuity; and
- Reducing the number of incorrect amounts.
The EDGAR XBRL Guide, chapter 5, section 5.9 sets out specific calculation relationship requirements, including certain examples and exceptions.
Item 5.9.1: Determining when calculation relationships are required
Section 5.9.1 of the EDGAR XBRL Guide states:
"If a financial statement shows two or more 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 custom taxonomy must have a calculation relationship from the total concept to each of the contributing items."
If a line item satisfies all of the following five conditions, as set out by section 5.9.1, the line item requires a calculation relationship:
Condition 1. In the Related Official Document, 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.)
- If yes, continue to Condition 2.
- If no, then no calculation relationship is required for that line item.
Condition 2. In the Related Official Document, does the line item appear with at least one other line item and the net or total of those line items?
- If yes, continue to Condition 3.
- If no, then no calculation relationship is required for that line item.
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 section 3.1.2 of the EDGAR XBRL Guide.
- If yes, continue to Condition 4.
- If no, then no calculation relationship is required for that line item.
Condition 4. Does the line item have a corresponding numeric fact in the instance document?
- If yes, continue to condition 5
- If no, then no calculation relationship is required for that line item.
Condition 5. Does the numeric fact appear in the instance document with at least one other numeric fact other than the net or total?
- If yes, then an effective calculation relationship is required from the total element to the contributing line item.
- If no, then no calculation relationship is required for that line item.
Additional questions related to Item 5.9.1:
-
If some of the contributing line items do not contain corresponding numeric facts, but other contributing line items do, is a calculation relationship still required?
-
Yes. Any line item that meets all the section 5.9.1 conditions requires a calculation relationship.
-
-
If a line item is in a context period before the Required Context, is a calculation relationship required for that line item?
-
No. A line item in a context period before the Required Context does not require a calculation relationship because the line item does not have the same end date as the Required Context (see section 3.1.2 of the EDGAR XBRL Guide).
-
-
If line items have corresponding numeric facts in different contexts, is a calculation relationship required between them?
-
No. Although permitted, line items with corresponding numeric facts in different contexts do not require a calculation relationship.
-
Question E.28
Q: Form 11-K is used for annual reports pursuant to Section 15(d) of the Securities Exchange Act of 1934 with respect to employee stock purchase, savings and similar plans (collectively, “Plans”). All financial statements and schedules required to be included on this report must be provided as an Interactive Data File in accordance with Rule 405 of Regulation S-T, beginning with filings made on or after July 11, 2025.
When filing a Form 11-K, a Plan must use the CIK of the issuer of the securities held pursuant to the Plan (the issuer is identified under Part B on the cover page of Form 11-K). Because a Plan does not have its own CIK or Commission file number, how should the Plan distinguish between the values tagged for the issuer and the values to be tagged for the Plan?
A: Legal Entity [Axis] with a Plan-specific member will serve as the unique entity identifier to distinguish the data for a Plan from data for the issuer and any related Plans. To help facilitate data consumption, a Plan-specific member should be created using a format that starts with “EBP” followed by the three-digit plan number. For example, an issuer with two related Plans should create two members with element names of EBP001Member and EBP002Member.
Legal Entity [Axis] with a Plan-specific member should be used on every fact tagged in Inline XBRL in every Plan’s Form 11-K, and applies to all levels (Level 1 through Level 4) of tagging.
Although the cover page of Form 11-K is not required to be tagged, the EDGAR XBRL Guide (EXG) (https://www.sec.gov/submit-filings/technical-specifications#xbrl) requires certain Document and Entity Information (dei) facts in the required context [EXG section 3.1] to be tagged in Inline XBRL. For each Plan disclosed in the filing, add these dei facts in each Plan-specific context: DocumentType, AmendmentFlag, and (if needed) AmendmentDescription. For example, if a Form 11-K covers three Plans because there is a collective investment of assets of the Plans in the same trust and the Form 11-K files the financial statements of that trust, the document type on the cover page will need to be tagged with four facts—one fact in the required context [EXG section 3.1] without Legal Entity [Axis]and three additional facts with Legal Entity [Axis] and the respective Plan-specific member. In addition, DocumentPeriodEndDate and DocumentFiscalYearFocus are optional facts for Form 11-K. If they are included, an issuer should apply the same tagging practice as described above.
F. Detail Tagging
Question F.1
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
Q: Does the EDGAR XBRL Guide section 5.6.3 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
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
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.”
Question F.5
Q: When tagging a single value that represents two separate facts with the same value, should two individual elements be used to tag the value separately?
A: In general, if two separate facts are conveyed as a single value (in the HTML/ASCII version), then the value should be tagged separately with two individual elements. For example, if there is a single value representing both basic and diluted earnings per share (EPS), then the individual basic EPS and diluted EPS elements (us-gaap:EarningsPerShareBasic, us-gaap:EarningsPerShareDiluted, respectively) should both be used.
Question F.6
Q: Release No. IC-33836 states that “[a] seasoned fund filing a short-form registration statement on Form N-2 also will be required to tag information appearing in Exchange Act reports— such as those on Form N-CSR, 10-K, 10-Q, or 8-K—if that information is required to be tagged in the fund’s prospectus.” If such information is included in the Form 10-K or Form 10-Q outside of the financial statements and notes (for example in item 5), is it still required to be tagged?
A: Yes. General Instruction I.3 of amended Form N-2 does not limit this requirement to only information included in financial statements and notes. Regardless of where information provided in response to the specified disclosure items appears in a A.2 Qualified fund’s Exchange Act reports, whether in Forms 10-K or 10-Q (or any other document filed pursuant to Sections 13(a), 13(c), 14, or 15(d) of the Exchange Act that is incorporated by reference into the Form N-2 registration statement that contains the specified disclosures), it is required to be tagged.
Question F.7
Q: Is tagging the Schedule of Investments for BDCs required or optional? If required, should the schedule be detail tagged for every fact reported?
A: Rule 405(e) of Regulation S-T describes the tagging requirements for financial statement schedules, which includes a fund’s Schedule of Investments, pursuant to rule 12-12 of Regulation S-X. Accordingly, a BDC must tag its Schedule of Investments consistent with these requirements, which includes detail tagging. It is the staff’s view that the Schedule of Investments generally should be tagged as a Statement and not a Disclosure Item.
Question F.8
Q: Does each risk factor have to be tagged separately? It appears this way in the examples provided in the 2021Q4 CEF taxonomy package. If so, our assumption is that every risk factor will need to be created as a custom extension domain member. Please confirm if that is correct.
A: Yes. It is the staff’s view is that registered CEFs and BDCs that are subject to the Inline XBRL tagging requirements must separately tag each risk factor, as the 2021Q4 CEF taxonomy package reflects.
Question F.9
Q: Given that A.2 Qualified funds may incorporate by reference documents that contain some, but not all, information that must be tagged in Inline XBRL, it is likely that a “full set” of the specified disclosures will not be tagged within a single filing. For example, a registered CEF that is a seasoned issuer must tag Risk Factors, Investment Objective and Policies and Senior Securities Table information in the Form N-CSR, if that information appears in the report. Even if the fund incorporates by reference its Form N-CSR into a subsequent Form N-2 filing, neither the Form N-2 nor the Form N-CSR would contain a “full set” of tagged data. Is it appropriate to have different context dates in this scenario?
A: Yes, it is appropriate to have different context dates in this scenario. Consistent with EDGAR XBRL Guide section 3.1.12, the context date should reflect the information being disclosed or context date of the report. Data users can merge the data from multiple filings together and use additional algorithms to arrange the data for the appropriate context.
G. Element Selection
Question G.1
Q: What are some considerations for selecting the most appropriate element from the U.S. GAAP Taxonomy among similar elements?
A: Selection of an appropriate element (or “tag”) from the U.S. GAAP Taxonomy for a particular disclosure facilitates the effective communication, access, and disclosures analysis by the Commission, investors, analysts, filers, data aggregators, and other market participants. Before you file, be sure to consider whether the taxonomy element you have selected is appropriate for the specific disclosure. Filers should carefully review the accounting standards disclosure requirements and the U.S. GAAP Taxonomy before mapping their disclosures to the U.S. GAAP Taxonomy elements. In particular, filers should review the element definitions in the U.S. GAAP Taxonomy and verify that they are consistent with the reported disclosure.
The tables below provide some illustrative examples where reviewing element definitions provided within the U.S. GAAP Taxonomy can help filers determine to which taxonomy element they should map their disclosure.
Property, Plant, and Equipment (PPE), Net (balance sheet)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:PropertyPlantAndEquipmentNet | us-gaap:AssetsNoncurrent |
Taxonomy Definition | Amount after accumulated depreciation, depletion and amortization of physical assets used in the normal conduct of business to produce goods and services and not intended for resale. Examples include, but are not limited to, land, buildings, machinery and equipment, office equipment, and furniture and fixtures. | Sum of the carrying amounts as of the balance sheet date of all assets that are expected to be realized in cash, sold or consumed after one year or beyond the normal operating cycle, if longer. |
Explanation | N/A | This element represents total long-term assets that may include assets other than PPE and provides no accommodation for the specific concept of accumulated depreciation, depletion and amortization. Because the disclosure consists only of PPE, Net us-gaap:AssetsNoncurrent element is not appropriate. |
Total operating expenses, consisting of general expenses. No revenue recorded. (income statement)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:OperatingExpenses | us-gaap:OperatingCostsAndExpenses |
Taxonomy Definition | Generally recurring costs associated with normal operations except for the portion of these expenses which can be clearly related to production and included in cost of sales or services. Includes selling, general and administrative expenses. | Generally recurring costs associated with normal operations except for the portion of these expenses which can be clearly related to production and included in cost of sales or services. Excludes selling, general and administrative expense. |
Explanation | N/A | This element represents a total of generally recurring costs associated with normal operations such as professional and contract services and legal fees, but excludes selling, general, and administrative expenses. Because the disclosure includes general expenses, the us-gaap:OperatingCostsAndExpenses element is not appropriate. |
Total provision for income taxes (includes both current and deferred income tax) (income tax footnote)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:IncomeTaxExpenseBenefit | us-gaap:CurrentIncomeTaxExpenseBenefit |
Taxonomy Definition | Amount of current income tax expense (benefit) and deferred income tax expense (benefit) pertaining to continuing operations. | Amount of current income tax expense (benefit) pertaining to taxable income (loss) from continuing operations. |
Explanation | N/A | This element includes only current income tax expense. Because the disclosure includes both current and deferred income tax expenses the us-gaap:CurrentIncomeTaxExpenseBenefit element is not appropriate. |
Net cash provided by investing activities-discontinued operations (cashflow statement)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:CashProvidedByUsedInInvestingActivitiesDiscontinuedOperations | us-gaap:ProceedsFromPaymentsForOtherFinancingActivities |
Taxonomy Definition | Amount of cash inflow (outflow) of investing activities of discontinued operations. Investing activity cash flows include making and collecting loans and acquiring and disposing of debt or equity instruments and property, plant, and equipment and other productive assets. | Amount of cash inflow (outflow) from financing activities classified as other. |
Explanation | N/A | This element represents proceeds and payments from other financing activities. Because this disclosure is about investing activities related to discontinued operations and not financing activities, the us-gaap:ProceedsFromPaymentsForOtherFinancingActivities element is not appropriate. |
Prepaid rent expense classified as a current asset (balance sheet)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:PrepaidRent | us-gaap:PrepaidExpenseNoncurrent |
Taxonomy Definition | Amount of asset related to consideration paid in advance for rent that provides economic benefits within a future period of one year. | Sum of the carrying amounts as of the balance sheet date of amounts paid in advance for expenses which will be charged against earnings in periods after one year or beyond the operating cycle, if longer. |
Explanation | N/A | This element represents a sum of non-current prepaid expenses. Because the disclosure only includes a prepaid rent expense, classified as a current asset, the us-gaap:PrepaidExpenseNoncurrent element is not appropriate due to its ‘non-current’ nature. |
Net cash used in operating activities (cashflow statement)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:NetCashProvidedByUsedInOperatingActivities | us-gaap:NetCashProvidedByUsedInContinuingOperations |
Taxonomy Definition | Amount of cash inflow (outflow) from operating activities. Operating activity cash flows include transactions, adjustments, and changes in value not defined as investing or financing activities. | The increase (decrease) in cash associated with the entity's continuing operating, investing, and financing activities. |
Explanation | N/A | This element represents a total of net cash provided by (used in) all three activities: operating, investing, and financing activities from continuing operations. Because the disclosure includes only operating activities, the us-gaap:NetCashProvidedByUsedInContinuingOperations is not appropriate. |
Loss from operations. No discontinued operations during the year. (income statement)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:OperatingIncomeLoss | us-gaap:IncomeLossFromContinuingOperations |
Taxonomy Definition | The net result for the period of deducting operating expenses from operating revenues. | Amount after tax of income (loss) from continuing operations attributable to the parent. |
Explanation | N/A | In this example, there were no discontinued operations. Therefore, using a tag, specifically assigned for income (loss) from continuing operations in the event of a discontinued operation is not appropriate as it incorrectly implies reporting of discontinued and continuing operations. |
Net deferred tax liabilities (income tax footnote)
Disclosure | Should Be | Should Not Be |
---|---|---|
Taxonomy Element | us-gaap:DeferredTaxLiabilities | us-gaap:DeferredTaxAssetsLiabilitiesNet |
Taxonomy Definition | Amount, after deferred tax asset, of deferred tax liability attributable to taxable differences without jurisdictional netting. | Amount, after allocation of valuation allowances and deferred tax liability, of deferred tax asset attributable to deductible differences and carryforwards, without jurisdictional netting. |
Explanation | N/A | This element represents net deferred tax assets. Because this disclosure is about liabilities and not assets, the us-gaap:DeferredTaxAssetsLiabilitiesNet is not appropriate. |
Last Reviewed or Updated: April 10, 2025