Which required section in a form 10-k is likely to represent unstructured data

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.

For further information please also review the Division of Corporation Finance's Compliance and Disclosure Interpretations for Release 33-9002.

The staff of the Division of Economic and Risk Analysis have prepared the following responses to questions about filer 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 staff of the Division of Economic and Risk Analysis. 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.

FAQ'sA. Validation

(Reserved)

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 other than Ex. 101, EDGAR rejects HTML that does not conform to a 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 will analyze 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 Filer Manual (Volume II) sections 6.5.15 and 6.5.16 address this currently. Note that Block Text content must also be well formed eXtensible Markup Language (XML) as described under section 6.5.15. This is a stronger requirement than validating against the EDGAR HTML 3.2 or 4.0 DTD.

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: With the exception of filings containing Inline XBRL documents, an EDGAR filing can be accepted with ”Warnings” even if some of its attached exhibits have errors. Exhibits that have errors are removed 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 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 looks like “ERR:” or “WRN:” but does not mention XBRL is not an XBRL problem, and is due to some other aspect of the submission.

An Inline XBRL document combines the HTML document with XBRL elements and attributes, and is validated without treating the XBRL contents as a separate instance document. Accordingly, if a submission has an Inline XBRL attachment 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.

B. Presentation and Rendering — All Submissions

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.

(Reserved)

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 6.24 of the EDGAR Filer Manual (Volume II) contains rules oriented toward rendering, including restrictions on statement rendering. Some special treatments are allowed for the Cash Flow Statement (section 6.24.14) and the Statement of Changes in Shareholder Equity (section 6.24.15).

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.

(Reserved)

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 the Risk/Return Rendering guide.

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.

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. See EDGAR Filer Manual (Volume II) section 6.5.16 for examples of correct escaping.

(Reserved)

Q: What does it mean for the presentation to "match" the original HTML/ASCII document?

A: EDGAR Filer Manual (Volume II) section 6.13 states this requirement more precisely. The presentation relationships within a given role (e.g., for a statement) must be the same as the original ordering. Also, the indentation of financial statements in HTML/ASCII format is much "flatter" than the deep nesting of a typical standard taxonomy, and the presentation linkbase should reflect that. Also, EDGAR Filer Manual (Volume II) section 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 U.S. GAAP Taxonomy’s 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 its company presentation linkbase to change in some way with every new filing, though perhaps not as much as the instance and labels change.

Q: How do I make a text block appear by itself in a presentation link role as EDGAR Filer Manual (Volume II) section 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 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.

Q: Should filers use a certain naming convention for presentation group titles?

A: Sections 6.7.12, 6.24.14 and 6.24.15 the EDGAR Filer Manual (Volume II) define these conventions.

Q: Should filers use a certain ordering convention for presentation groups?

A: Section 6.24.1 of the EDGAR Filer Manual (Volume II) addresses presentation groups, including rules around ordering.

(Reserved)

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 Filer Manual (Volume II) section 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.

C. Presentation and Rendering — Risk/Return Summaries

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: https://xbrl.sec.gov/rr/2018/rr-preparers-guide-2018-03-12.pdf .

D. Standard Taxonomies

Q: Which files from a standard taxonomy can an Interactive Data submission refer to?

A: The schema files or embedded linkbases of a taxonomy that define elements, types or roles are listed on the SEC website https://www.sec.gov/info/edgar/edgartaxonomies.shtml as soon as the taxonomy is available for use in EDGAR.

Linkbase files or embedded linkbases 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:

  1. The linkbase defines a form, such as the Form N-1A, that mandates a particular presentation order, and the element labels need not be modified by the filer;
  2. The linkbase contains definition relationships that cannot be overridden because they define a table of data structured in a way mandated by a Commission Rule.

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.

(Reserved)

(Reserved)

Q: Do all the rules in EDGAR Filer Manual (Volume II) 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:

  • File names, namespaces, schemaLocation and xlink:href attributes of a standard taxonomy are not restricted by any of the EDGAR Filer Manual rules.
  • Element declarations: A standard taxonomy might include elements that do not follow the 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.
  • Linkbases: Although always valid with respect to XBRL International recommendations, there may be any number of EDGAR Filer Manual (Volume II) violations.

Q: Does EDGAR Filer Manual (Volume II) section 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. In practice, arcs in a standard taxonomy usually have priority=10 meaning that in EDGAR they cannot be overridden at all.

Q: EDGAR Filer Manual rule 6.5.20 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

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.

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

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.

Q: When must registered closed-end funds (“registered CEFs”) and business development companies (“BDCs”) begin tagging the Form N-2 cover page, specified prospectus disclosures and (for BDCs only) financial statement information in Inline XBRL?

A: Registered CEFs and BDCs that are eligible to file a short-form shelf registration statement pursuant to General Instruction A.2 of Form N-2 (“A.2 Qualified funds”) must comply with the Inline XBRL tagging requirements on or before August 1, 2022. All other registered CEFs and BDCs must comply on or before February 1, 2023.

Once the relevant compliance date has passed, registered CEFs and BDCs must tag the Form N-2 cover page, and, as applicable, all information provided in response to the disclosure items specified in General Instruction I of Form N-2 in any registration statement or post-effective amendment filed on Form N-2 or as a rule 424 filing. In addition, A.2 Qualified funds must tag any document filed pursuant to Sections 13(a), 13(c), 14, or 15(d) to the extent that the specified disclosure information appears therein. Note that funds that are subject to Inline XBRL tagging requirements must also tag the cover page of Forms 10-K, 10-Q, and 8-K. See 17 CFR 232.406. Finally, BDCs must begin tagging their financial statements pursuant to the phased-in approach described below. See Release No. IC-33836 and 17 CFR 232.405 for additional details.

Q: Does the requirement for BDCs to start tagging their financial statements begin with the first Form 10-Q filed on or after the applicable compliance date? Or the first Form 10-Q filed for a fiscal period ending on or after the applicable compliance date?

A: A BDC’s financial statement tagging obligations begin when it files its first Form 10-Q for the fiscal period ending on or after the applicable compliance date, which mirrors the phased-in approach provided to operating companies. See Release No. 33-10514 at FN 151. A BDC that is a seasoned issuer must begin with the first Form 10-Q filed for the period ending on or after August 1, 2022. All other BDCs will begin their financial statement tagging with the first Form 10-Q filed for the period ending on or after February 1, 2023.

Q: Registered CEFs and BDCs that are A.2 Qualified funds must comply with the Inline XBRL tagging requirements on August 1, 2022. What if a fund files an annual report on Form N-CSR or Form 10-K prior to that date that contains specified disclosure or financial statement information that was not tagged, and that information is backward incorporated by reference into a Form N-2 filing submitted after August 1, 2022? In other words, are funds allowed to incorporate by reference documents that contain untagged information that would have been required to be tagged had such a report been filed after the relevant Inline XBRL compliance date?

A: Yes. General Instruction F.3 of Form N-2 requires A.2 Qualified funds that file a short-form shelf registration statement to forward and backward incorporate by reference certain documents into the registration statement. Accordingly, based on the situation described above, such funds should backward incorporate by reference documents that were filed, but not tagged, prior to the relevant compliance date.

Q: Must registered CEFs and BDCs tag every Form N-2 filing in Inline XBRL (i.e., from the initial Form N-2 filing to the rule 424 prospectus supplement)? Or may a fund only tag the last Form N-2 filed prior to effectiveness (i.e., on a pre-effective amendment) and its related rule 424 filings?

A: Funds need not tag every Form N-2 filing, as long as they tag the last Form N-2 filed on or before the date the registration statement or post-effective amendment that contains the specified disclosures becomes effective. Likewise, not every rule 424 filing must be tagged; only the final filing that contains the specified prospectus disclosures must be tagged in Inline XBRL. See General Instruction I.1-2 of Form N-2.

Q: Are newly-registered CEFs and BDCs subject to the tagging requirements?

A: Yes. After the relevant compliance dates, all registered CEFs and BDCs will be subject to the new Inline XBRL tagging requirements, including new registrants. However, the August 1, 2022, compliance date only applies to A.2 Qualified funds—which excludes new registrants that cannot satisfy the requirements of General Instruction A.2.b of Form N-2. Accordingly, new registrants will not be subject to the new Inline XBRL tagging requirements until February 1, 2023.

Q: The samples provided at https://xbrl.sec.gov/cef/2021q4/samples-cef-2021q4.zip 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 6.9 through 6.19 of the EDGAR Filer Manual (Volume II), filing with linkbases is allowed. Filers will receive adequate notice if any changes are to occur.

Q: For a closed-end fund, when does the requirement to tag the cover page of Form 8-K begin?

A: Pursuant to Rule 406 of Regulation S-T, a registered CEF or BDC that files on Form 8-K must, like other filers that are required to submit Interactive Data Files in Inline XBRL in accordance with Regulation S-T, tag the Form 8-K cover page. Such funds must begin tagging the Form 8-K cover page pursuant to the phased-in approach described above. See Question D.9 of the FAQs.

Q: An A.2 Qualified registered CEF filed a registration statement on Form N-2 prior to August 1, 2022, that has not been declared effective. Does the filer need to tag its next pre-effective amendment filed after August 1, 2022, in Inline XBRL? Does the answer differ depending on whether the Form N-2 filed was a short-form shelf registration statement filed pursuant to General Instruction A.2 of Form N-2 versus a long-form registration statement (whether a shelf or otherwise)?

A: Because the registered CEF is A.2 Qualified, it must tag the Form N-2 cover page, as well as any specified prospectus disclosure that appears in a Form N-2 registration statement filed as of August 1, 2022. However, a filer need not tag every Form N-2 filing, as long it tags the last Form N-2 filed on or before the effective date of the registration statement or post-effective amendment that contains the specified disclosures. See Question D.12 of the FAQ. The tagging requirement applies regardless of the type of registration statement filed (short-form or long-form).

Q: An A.2 Qualified fund filed an N-2ASR prior to August 1, 2022, that was not tagged in Inline XBRL. If, after August 1, 2022, the fund files a post-effective amendment to that N-2ASR via an N-2 POSASR, must the Form N-2 POSASR be tagged in Inline XBRL?

A: Yes. As of August 1, 2022, any post-effective amendment filed on Form N-2 by an A.2 Qualified fund that contains the specified prospectus disclosures must be tagged, along with the Form N-2 cover page.

Q: Assume a registered CEF has an effective registration statement on Form N-2 that is not tagged in Inline XBRL. After the relevant compliance date has passed (as of August 1, 2022, for A.2 Qualified funds, or February 1, 2023, for all other funds), would such a fund have to tag its prospectus supplements in Inline XBRL?

A: Yes. If the rule 424(b) prospectus supplement contains information that responds to the specified prospectus items, such information would have to be tagged in Inline XBRL. In the staff’s view, when a 424(b) filing contains responses to the specified items in the prospectus supplement, and also contains responses to the same specified items in a base prospectus that was initially filed before the relevant compliance date, only the responses in the prospectus supplement should be tagged in Inline XBRL.

Q: Assume that a registered CEF that files under rule 486 has an Inline XBRL compliance date of February 1, 2023. Would a rule 486(a) filing submitted as of February 1, 2023, have to be tagged in Inline XBRL?

A: Yes. As of February 1, 2023, any Form N-2 (whether an initial filing or post-effective amendment), rule 424(b) prospectus supplement, or annual shareholder report filed on Form N-CSR that includes information that responds to the specified prospectus items must be tagged in Inline XBRL. The Form N-2 cover page also must also be tagged. See Question D.9 of FAQ.

Q: For a BDC with a compliance date of August 1, 2022, does a Form 10-Q for a quarter ending before August 1, 2022, but filed after August 1, 2022, need to tag the Form 10-Q cover page and any prospectus information included in that filing?

A: Yes. BDCs that are A.2 Qualified must tag any information that responds to the specified prospectus items that appears in a Form 10-Q filed after August 1, 2022. Likewise, the Form 10-Q cover page must also be tagged. Financial statement information need not be tagged until the first Form 10-Q for the period ending after August 1, 2022. See Questions D. 9-D.10 of FAQ.

Q: General Instruction I.3 of Form N-2 requires A.2 Qualified funds to file Interactive Data files for annual and other Exchange Act reports listed in General Instruction F.3.(a) or General Instruction F.3.(b), that include or amend information provided in response to specified prospectus items. Do filers need to tag the data in those Exchange Act reports in Inline XBRL if the relevant information was previously provided and tagged in the Form N-2?

A: Yes. An A.2 Qualified fund filing a short-form registration statement on Form N-2 must tag information appearing in its Exchange Act reports—including, but not limited to, those on Forms N-CSR, 10-K, 10-Q, or 8-K, etc. —if that information is required to be tagged in the fund’s prospectus. Information disclosed in response to the Form N-2 specified prospectus items must be tagged in each filing, regardless of whether it was disclosed and tagged in a prior filing.

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

Q: Characters that are "special" are forbidden by EDGAR Filer Manual (Volume II) 5.2.1.2.1 and 7.3.4.33 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.

Q: What does it mean for an element label to be "the same" as the original HTML/ASCII document?

A: EDGAR Filer Manual (Volume II) section 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 (Volume II). Achieving adequate correspondence is the source of many of the "semantic" rules in EDGAR Filer Manual (Volume II) 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. For example, the U.S. GAAP Taxonomy contains over 15,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.

Q: Am I required to use existing linkbase roles or make up my own? Can they change with every submission?

A: EDGAR Filer Manual (Volume II) section 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.

(Reserved)

(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 (Volume II) 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)

(Reserved)

Q: Can the content of a text block be in a language other than US English (“en-US”)?

A: Yes; however, EDGAR Filer Manual (Volume II) section 6.5.14 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.

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.

Q: Does EDGAR Filer Manual (Volume II) section 6.16.3 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 EDGAR Filer Manual (Volume II) section 6.9.3.

(Reserved)

Q: EDGAR Filer Manual (Volume II) section 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; EDGAR Filer Manual (Volume II) section 6.7.10 applies to the entire DTS.

Q: Does EDGAR Filer Manual (Volume II) section 6.8.1’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 user 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.

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 Filer Manual (Volume II) section 6.6.15. 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 Filer Manual (Volume II) section 6.24.15 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.

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

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 Filer Manual (Volume II) section 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 (Volume II) section 6.6.4). EDGAR Filer Manual (Volume II) sections 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 (Volume II) 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 Filer Manual (Volume II) sections 6.6.4, 6.6.3, and 6.5.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 Filer Manual (Volume II) sections 6.6.4, 6.6.3, and 6.5.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 Filer Manual (Volume II) section 6.6.5).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 Filer Manual (Volume II) section 6.6.5).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 Filer Manual (Volume II) section 6.6.3).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 Filer Manual (Volume II) section 6.6.3).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 Filer Manual (Volume II) section 6.6.7).There is no need to use a parent company element.

EDGAR Filer Manual (Volume II) sections 6.6.3 through 6.6.8 contain examples and detail the technical structure of the srt:ConsolidatedEntitiesAxis, dei:LegalEntityAxis, domain, and members.

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.

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 section 6.5.9 of the EDGAR Filer Manual (Volume II)) and whose end date reflects the specified date.

Q: EDGAR Filer Manual (Volume II) section 6.8.6 prohibits the use of company-specific or period-specific information in element names. Does this apply to all item types?

A: EDGAR Filer Manual (Volume II) section 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: What are the rules around using unit types in an Interactive Data filing?

A: Refer to section 6.5.35 of the EDGAR Filer Manual (Volume II) for the unit type registry restrictions.

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, as EDGAR Filer Manual (Volume II) section 6.3.10 implies, most submissions will contain at least one EX-101.SCH (schema) but may contain more, defining different namespaces compliant with sections 6.7.4 and 6.7.5. 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 (EDGAR Filer Manual (Volume II) section 6.8.2). 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.

(Reserved)

Q: Are calculations allowable for elements with amounts outside of a “required context”?

A: Yes, calculations that meet the EDGAR Filer Manual (Volume II) rules for calculation linkbases (see EDGAR Filer Manual (Volume II) 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).

Q: My Form10-K includes line items in the original HTML/ASCII that come under the EDGAR Filer Manual (Volume II) 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: 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 Filer Manual (Volume II) section 6.15 for additional detail.

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. EDGAR Filer Manual (Volume II) section 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.

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 Filer Manual (Volume II), 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

Section 6.15.2 of the EDGAR Filer Manual (Volume II) 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 section 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.)

  • If yes, continue to Condition 2.
  • If no, then no calculation relationship is required for that line item.

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?

  • 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 6.5.19 of the EDGAR Filer Manual (Volume II)?

  • 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 6.15.2:
  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 6.15.2 conditions requires a calculation relationship.

  2. 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 6.5.19 of the EDGAR Filer Manual (Volume II)).

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

F. Detail Tagging

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.

Q: Does the EDGAR Filer Manual (Volume II) section 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.

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.

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

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.

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.

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.

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.

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 EFM 6.5.21, 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

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.