UNITED STATES

URL: 1 https://xbrl.us/qa-sec-ixbrl/

Q&A – Inline XBRL

Responses to these questions reflect the informal views of one or more members of the staff of the U.S. Securities and Exchange Commission participating in a discussion and do not constitute an official statement of the views of the Commission or of the staff of the Commission and should not be relied upon as authoritative.

For issuers that early adopt Inline XBRL on 10-Qs and 10-Ks and are not yet part of the Inline XBRL phase-in period, if they file a registration statement before their mandated phase-in period, will their registration statements, or any other forms, require Inline XBRL format by virtue of the fact they previously have filed Inline XBRL?

Filers that early adopt Inline XBRL are allowed to go back and forth between Inline and conventional XBRL, irrespective of the form type, until they are required to use Inline XBRL.

After an issuer conducts their first required Inline XBRL filing per the phase-in, is the issuer required to file Inline XBRL on subsequent filings regardless of form type, if the filing includes financial statements that are for a fiscal period after their Inline XBRL phase-in fiscal period end date? For example, a Large Accelerated Filer using US-GAAP with a 12/31 YE submits their 10-Q with Inline XBRL for the Quarter Ended 6-30-2019 on 7-30-2019 to the EDGAR system. Are the subsequent XBRL filings regardless of form type required to be submitted with Inline XBRL as long as the financials in said filings are for a fiscal period ending on or after 6-15-2019? Additionally, in this example, if the filing includes two sets of financials, one set with fiscal period end date prior to 6-15-2019, and one set with fiscal period end date on or after 6-15-2019, is the issuer to submit a single Inline XBRL instance for the filing?

Yes to all of these questions. Under the compliance language in the adopting release (33-10514 (6/28/2018)) discussion text associated with note 151 and the text of Regulation S-T Rule 405(~(1)(i), once a large accelerated filer that reports in US GAAP on 10-Q is required to file such a 10-Q using Inline XBRL, all subsequent filings that contain any financial statement for which an Interactive Data File is required for a period that ends on or after 6/15/19 must be filed in Inline XBRL. Financial statements for which an Interactive Data File is required for all periods included in the filing would need to be in Inline XBRL in the same Inline XBRL instance.

Can issuers immediately stop posting the XBRL data files on their web site, regardless of their Inline XBRL phase-in date?

Yes. The SEC states in the adopting release that the amendments eliminating the website posting requirement are effective September 17, 2018. As a result, as of that date, companies do NOT have to post their XBRL files on their web site.

For a company that has never filed financial statements in conventional or Inline XBRL and is filing them in XBRL for the first time using Inline XBRL, is it able to take advantage of the 30-day grace period on its XBRL submission as stated in the original (2009) final rule?

Yes, under Regulation S-T Rule 405(a)(3)(i)(B), it can file the HTML-only version first, and then within the 30-day grace period amend that filing to add the Inline XBRL document which will contain the combined HTML and XBRL. Assuming the financial statements are unchanged and the sole purpose of the amendment is to add the Inline XBRL document, in the case of an amendment to a periodic report, the filer should include the cover page, an explanatory note, the combined HTML/XBRL financials, an exhibit index and exhibit 101.

URL: 2 https://xbrl.us/home/filers/sec-reporting/best-practice/qa-sec-fast-act/

Q&A – SEC Cover Page Tagging

This Q&A is intended as general guidance and should not be relied upon as authoritative. Filers are encouraged to consult with their own legal and/or with the SEC directly.

Early Adoption/Timing

Are early adopters of Inline XBRL (public companies that have already begun submitting financials using Inline XBRL, but that are not yet subject to Inline XBRL compliance because the compliance date for their category of company, e.g., non-accelerated filer, has not yet occurred), required to continue tagging their cover pages? 

No, they can start and stop up until their filing compliance date. Filers do not need to begin tagging the cover page of their 10-Ks, 8-Ks, 10-Qs, 20-Fs and 40-Fs, until they become subject to Inline XBRL per their Inline XBRL filing date (Large Accelerated Filers (US-GAAP) – Fiscal periods ending after June 15, 2019, accelerated Filers (US-GAAP) – Fiscal periods ending after June 15, 2020, all Others – Fiscal periods ending after June 15, 2021)

Can a public company elect to tag the cover page on their 8-K using Inline XBRL before they file the first 10-Q? Or is it required to file a 10-Q using Inline XBRL first, before they can publish a form 8-K using Inline XBRL?

Yes, filers can early adopt and tag a Form 8-K. 

If a calendar year-end filer, files an 8-K, after June 15, but before they file their second quarter 10-Q, is that 8-K not required to have the cover page data tagged with Inline XBRL?

Yes, that is correct. This filer would not need to tag their cover page until they have filed their first 10-Q using Inline XBRL per their compliance date.

What Should Be Tagged?

Do all Form 8-K cover pages have to be tagged, regardless of whether they contain financial data? Is it required to tag cover pages of Form 8-Ks of earnings releases?

Any Form 8-K that is submitted by a reporting entity that is subject to Inline XBRL, must have the cover page tagged, once that company’s compliance date occurs.

Does the rule require companies to tag cover pages for ALL 8-K, 10-K, and 10-Q filings from operating companies? For all 20-F and 40-F cover pages that are annual reports? Or just those with financials in them?

Cover page tagging applies to all Forms 10-K, 8-K, 10-Q, 20-F and 40-F (for the last two forms, only if they are being used for annual reports and not registration statements).  The only exception is for filers that are not subject to Inline XBRL (i.e. ABS filers). Specifically, once a filer becomes subject to submitting any of its filings in Inline XBRL, it must begin tagging the cover page of its 10-Ks, 8-Ks, 10-Qs, 20-Fs and 40-Fs.

Is tagging of the 6-K cover page required?

No, it is not required.

Clarification on Exhibits

What is Exhibit 101?

The exhibit required to be filed with your Inline XBRL submission.

What is Exhibit 104? 

Exhibit 104 is the document cover page tagged in Inline XBRL. It describes the required content in the Inline XBRL document. Exhibit 104 must be included as part of Exhibit 101.

Do I need to reference Exhibit 104 anywhere in my EDGAR submission?

Yes, if the filing document contains an exhibit index. Forms that do not include an exhibit index do not need to reference Exhibit 104.

For example, Form 10-Q requires the inclusion of “Item 6. Exhibits”. Some Form 8-Ks require the inclusion of an exhibit index and some Form 8-Ks do not require the inclusion of an exhibit index.

How do I reference Exhibit 104 in my submission?

Exhibit 104 should be included in the exhibit index, if the filing document includes an exhibit index. An example of this is shown below.

IMAGE FORM DOES NOT SUPPORTED HERE.

What if I’ve already submitted my Inline XBRL document and it does not include the Exhibit 104 reference in the exhibit index?

Just add the Exhibit 104 reference in your next Inline XBRL filing.

Please provide an example of a Form 8-K with cover page tagged using Inline XBRL.

IMAGE FORM DOES NOT SUPPORTED HERE.

Example Inline XBRL documents:

Example 1

Example 2

DEI Taxonomy

Can you provide a link to the DEI 2019 Taxonomy?

Link to all SEC US GAAP Taxonomies: https://www.sec.gov/info/edgar/edgartaxonomies.shtml#USGAAP2019

Link to the DEI 2019 Taxonomy: https://xbrl.sec.gov/dei/2019/dei-2019-01-31.xsd

Can new elements in the DEI Taxonomy be viewed in the FASB “yeti” viewer?

Yes.

Can you comply by creating custom tags rather than using the new elements in the 2019 DEI Taxonomy?

No, you are required to use the new tags. 

Can we use the 2019 DEI Taxonomy with the 2018 US GAAP Taxonomy?

Yes, you can use these two taxonomies together.

Other Topics

For “required visible facts” that are listed as “dei” (not as “cover”), are they also required to be visible?

Most, but not all DEI facts defined in EFM 5.2.5.14, are required to be visible (note that CIK and Amendment Flag, for example, should be hidden).

In the SEC’s Inline XBRL viewer, there is a drop down menu “More Filters” which includes an option for “Source documents”. Under what situation would a filing have more than one source document? 

If there is more than one document in a single filing that contains XBRL, there will be multiple sources. 

If a company has multiple debts, do we use one standard tag and then dimensionalize?

If multiple securities are included in the securities table, they should be dimensionalized. 

What is recommended if the registrant name on the cover of a 10-Q or 10-K is different from the registrant name associated with the CIK?  Do you use the registrant name associated with the CIK?

You can either use the registrant name associated with the CIK, or you could use a hidden fact and include a reference to the hidden fact in the document. 

URL-3:https://xbrl.us/qa-sec-inline-xbrl-funds/

Q&A: Funds and Inline XBRL

Responses to these questions were developed through an informal discussion with staff from the U.S. Securities and Exchange Commission.

Question: What is the Commission’s position on data points in bar charts? We assume that would require hidden facts such as DEI information. Today the risk/return summary charts must be tagged in table format in the detail view – how would the individual facts in the bar chart be represented using inline XBRL?

Answer: Tags in charts should be put in the hidden section. Validation has or will be modified so it will not give you a warning. The data does not have to be tied to an image, but it certainly can be.

Question: Could the Commission create one or more sample Inline XBRL documents for funds as they did with operating companies? It would be helpful to see a sample registration statement amendment (485BPOS) and a sample (or samples) of a supplement (497).

Answer: In the most recently published test suite(https://www.sec.gov/structureddata/osdinteractivedatatestsuite), i23007gd (test case), there is a specimen filing, an anonymized N1A filing summary. This shows what must and what doesn’t have to be tagged. 

Question: Are there plans for the SEC to release an update of the technical specification document for Risk Return based on inline XBRL?

Answer: It is not clear that this is needed. Much that is in the current EDGAR Filer Manual (https://www.sec.gov/info/edgar/edmanuals.htm) and Preparer’s Guide is still applicable, under EDGAR Filer manual section 6.13, Inline XBRL only relieves the filer of the need to approximate the original filing layout; nothing else changes. 

Question: For the 485BPOS, funds sometimes pull content from multiple sources and in multiple formats, e.g., Quark, Excel, etc. which takes time to aggregate into a single format. Are there any suggestions on how best to handle this?

Answer: The goal is to move to HTML format that allows you to aggregate to a common file. How you aggregate HTML for EDGAR today will be essentially the same. 

Question: Will there be any rendering options like the SEC previewer? How will a filer be able to view the XBRL prior to filing? If there is a rendering option, will the rendering agent create bar charts?

Answer: Every product has its own previewer, or vendors can also use the SEC EDGAR Renderer through the Arelle GUI. Bar charts are viewable in Arelle also. 

Question: Will a new Risk/Return Taxonomy be released for the transition to Inline XBRL?

Answer: There’s no need to create a new taxonomy for the move to Inline XBRL. If items 2, 3, or 4 in N-1A change, the taxonomy will be modified.

Question: Does the Commission envision any changes in the applicability of the calculation linkbase for Risk/Return or will it continue to be a “null” linkbase for the majority of mutual fund filings?

Answer: The Commission sees no reason to change the way the calculation linkbase is used. But XBRL International now has a proposal out for Calc Linkbase 2 which is meant to address issues that arise in financial statements. The Calc linkbase associated with the risk/return has no such issues. You can import the standard one into your filing.

Question: Does the SEC anticipate that a test filing system for inline risk/return will be made available?

Answer: The EDGAR test filing system is the test filing system. This is already available. When EDGAR was updated on March 11, 2019, it allowed for Risk/Return Summary Inline filings in the test system.

Question: Will the Table TextBlock elements and associated Embedded Text used to render the summary section tables be eliminated? Will they be maintained for a period of time to accommodate XBRL rendering which may not be inline XBRL enabled?

Answer: This is up to the filer. If the filer wants to include these as hidden items, they can. However, with inline XBRL, the need for this goes away, but they are not necessary once you’re using inline XBRL.

Question: Are there any developments on the merge functionality process documented at the end of the preparers guide?

Answer: There are no developments on the merge functionality process. The merge process is based on only looking at the data, not the presentation. 

Question: With respect to linkbases, will these be the same going forward?

Answer: The default presentation linkbase can be used. 

Question: How does the SEC intend to support redlining (track changes) in the inline tagged html?  There is a conflict between the inline code and the redline coding that would potentially cause an error or issue in the filing. Does the SEC have thoughts on how this could be resolved?

Answer: The Commission is aware of this issue and there will be a method available in EDGAR prior to the compliance date for Mutual Funds.

URL-4:https://www.sec.gov/structureddata/osd-inline-xbrl.html

Inline XBRL

On June 28, 2018, the Commission adopted amendments requiring the use, on a phased in basis, of Inline XBRL for operating company financial statement information and fund risk/return summary information. See Release No. 33-10514 for details.

What is Inline XBRL?

Inline XBRL is a format that allows filers to embed XBRL data directly into a HyperText Markup Language (HTML) document so that filers need only prepare one Inline XBRL document rather than generate an HTML document of their financial statement information or risk/return summary information and then tag a copy of the data to create a separate XBRL exhibit.

For data users, Inline XBRL provides an easier way to view, access, and explore the contextual information of the underlying data. For example, users can hover over values in the filing to find more information about the data, such as citations and hyperlinks to the relevant accounting guidance, narrative definitions for the values, and reporting period information associated with each value.

How are Inline XBRL filings viewed?

Viewing Inline XBRL filings is simple and does not require any specialized software because the Commission has incorporated an Inline XBRL Viewer into the Commission’s Electronic Data Gathering, Analysis, and Retrieval (EDGAR) system. Anyone using a recent standard internet browser can view an Inline XBRL filing on EDGAR. (Recent standard internet browsers are ones that fully support HTML 5 and JavaScript, such as Chrome 68 and later, Firefox 60 and later, Safari IOS 11 and later, Microsoft Edge Windows 10, and Internet Explorer 11.)

The short video below describes some of the features and capabilities of the open source Inline XBRL Viewer.

VIDEO FORMAT DOESN’T SUPPORTED HERE.

You can access a transcript of the video here.

When must filers begin filing using Inline XBRL?

Operating Company Financial Statement Information

U.S. GAAP filers have a three-year phase-in to comply with the Inline XBRL requirements as follows, beginning with fiscal periods ending on or after:

• June 15, 2019 for large accelerated filers
• June 15, 2020 for accelerated filers
• June 15, 2021 for all other filers

IFRS filers will be required to comply with Inline XBRL beginning with fiscal periods ending on or after June 15, 2021.

Domestic form filers, however, will not become subject to the requirement until their first Form 10-Q filed for a fiscal period ending on or after the applicable compliance date, as opposed to the first filing for a fiscal period ending on or after that date.

Fund Risk/Return Summary Information

Funds have a two-year phase-in to comply with the Inline XBRL requirements as follows, beginning with any initial registration statement (or post-effective amendment that is an annual update to an effective registration statement) that becomes effective on or after:

• September 17, 2020 for large fund groups (with assets of $1 billion or more as of the end of the most recent fiscal year)
• September 17, 2021 for small fund groups (with assets of less than $1 billion as of the end of the most recent fiscal year)

Can all forms subject to the Inline XBRL requirements be voluntarily filed using Inline XBRL in the EDGAR system now?

The EDGAR system was modified on March 11, 2019 to accept in Inline XBRL all forms subject to the Inline XBRL requirements.

Operating companies that are not currently subject to the Inline XBRL requirements may voluntarily file in Inline XBRL the forms that will be subject to the Inline XBRL requirements.

Where can I find filings submitted using Inline XBRL?

The most recent 200 Inline XBRL filings are displayed here for ease of reference.

Alternatively, when searching the documents of a particular company, any filing submitted using Inline XBRL will display an “iXBRL” indicator as below:

Is the Inline Viewer software source code available for download?

The Inline Viewer software is freely available to the public in an effort to facilitate the creation of cost effective Inline XBRL viewers and analytical products.

Where can I find the technical requirements related to filing using Inline XBRL?

The EDGAR Filer Manual provides the technical requirements needed for filers to use Inline XBRL.

Who should I contact for questions on Inline XBRL?

For questions on Inline XBRL rule requirements and compliance related to operating company financial statement information, please contact the Office of Chief Counsel in the Division of Corporation Finance at 202-551-3500 or using the form at https://www.sec.gov/forms/corp_fin_interpretive. Please select “Office of Chief Counsel” in the form.

For questions on Inline XBRL rule requirements and compliance related to fund risk/return summary information, please contact the Office of Chief Counsel in Division of Investment Management at 202-551-6825 or IMOCC@sec.gov.

For questions on structured data or other technical questions such as XBRL validation, taxonomies, and data quality, please contact the Office of Structured Disclosure in the Division of Economic and Risk Analysis at 202-551-5494 or StructuredData@sec.gov.

For questions on submitting forms through EDGAR and other submission questions, please contact EDGAR Filer Support at 202-551-8900

Small entities may also be interested in reviewing the following compliance guides:

• Operating Company Inline XBRL Filing of Tagged Data: A Small Entity Compliance Guide for Issuers
• Open-End Management Investment Company Inline XBRL Filing of Tagged Data: A Small Entity Compliance Guide for Issuers

URL-5:https://www.sec.gov/structureddata/FAQs

Staff Interpretations and FAQs Related to Interactive Data Disclosure

From time to time, the staff of the Division of Economic and Risk Analysis will publish interpretations and FAQs to help filers understand how to comply with the Commission’s interactive data disclosure rules.

The answers to these frequently asked questions represent the views of the Staff of the Division of Economic and Risk Analysis. They are not rules, regulations or statements of the Securities and Exchange Commission. Further, the Commission has neither approved nor disapproved them.

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

1. Validation
2. Presentation and Rendering — All Submissions
3. Presentation and Rendering — Risk/Return Summaries
4. Standard Taxonomies
5. Company Extensions and Instances
6. Detail Tagging
7. Element Selection

FAQ’s

1. Validation

Question A.1 (formerly Question 1)

Q: Are submissions under the Voluntary Filing Program (VFP) validated the same way as those under the mandatory program adopted in Release 33-9002?

A: No. Interactive Data submissions are EX-101 attachments validated according to EDGAR Filer Manual Chapter 6. VFP Data submissions are EX-100 attachments validated as in EDGAR Filer Manual Chapter 5.

Question A.2 (formerly Question 2)

Q: How does the EDGAR validator validate HTML embedded into Block Text?

A: In all SEC submissions and attachments (other than Ex. 100 and Ex. 101), EDGAR rejects HTML that does not conform to a restriction of HTML 3.2 DTD, in particular rejecting anything that could pose a security threat to a recipient. On that general principle, the EDGAR Validator will analyze Interactive Data content that, when un-escaped, may be interpreted as HTML, and will reject it if it contains content that the existing DTD would reject. EDGAR Filer Manual Rules 6.5.15 and 6.5.16 address this currently. Note that Block Text content must also be well formed XML. This is a stronger requirement than validating against the EDGAR HTML 3.2 DTD.

Question A.3

Q: How can I tell whether a warning or an error from my test filing validation is related to XBRL and what would have happened if the filing had been live?

A: An EDGAR filing can be accepted with ‘Warnings’ even if some of its attached exhibits have errors. Exhibits that have errors are stripped from the filing before it is accepted into EDGAR. XBRL files are exhibits. Therefore, an error message that looks like this “WRN: XBRL Error…” means that the XBRL files will be stripped from a live filing, but the rest of the filing will be accepted into EDGAR. If this happens the filer must submit an Amendment with the corrected XBRL.

A message that looks like this “WRN: XBRL Warning…” means that there is a minor error in the XBRL exhibit, but the XBRL file will not be stripped. We encourage filers to fix these errors in their subsequent filings. A message that looks like “ERR:” or “WRN:” but does not mention XBRL is not an XBRLproblem, and is due to some other aspect of the submission.

1. Presentation and Rendering — All Submissions

Question B.1 (formerly Question 4)

Q: Can I still view submissions made under the Voluntary Filing Program?

A: No. The older Voluntary Filing Program Data Viewers are separate from the Interactive Data Viewer and are currently not supported by the SEC.

Question B.2 (formerly Question 5)

Q: If a filer uses the Interactive Data Previewer, is there any guarantee that end users will see the same rendering?

A: Yes. If Interactive Data pursuant to the rules in Release No. 33-9002 is previewed using the Interactive Data Previewer, then the rendering will be the same.

Question B.3 (formerly Question 6)

Q: How do I ensure that a statement renders with periods as rows rather than as columns, with a specific axis as columns, ignoring some axis, or other arrangements?

A:There are some rules in the EDGAR Filer Manual oriented toward rendering. For example, EDGAR Filer Manual rule 6.7.12 explains how to order the pages to be rendered from a submission by manipulating the link:description element of link:roleType declarations, rule 6.13.4 describes how parentheticals should be arranged in the presentation linkbase, etc.

The general approach of the rendering engine is to infer layout from the contents of the instance first, then use the presentation linkbase to adjust it, then use key words in the role definition to further adjust it. Here are the basic rendering strategies:

1. Facts are arranged into columns with descending periods from left to right without regard to anything in the taxonomy.
2. Facts are shown in the same column if their end date and instant are the same, again without regard to anything in the taxonomy.
3. Facts are then shifted one column to the left if there is a “period start” preferred label, but only if the role definition contains the phrase “cash” followed by “flow”. If the role definition contains the word “cash” or “flow” then adjacent columns containing duration facts and instant facts at the beginning and end of that duration may be merged together.
4. Rows are grouped together according to the axes and domain members that appear in the facts. Groups of facts that all share the same set of axes and domain members appeartogether, and are ordered according to the order in which the domain members appear in the presentation linkbase as direct children of the axes. The axes are then ordered according to their order in the presentation.
5. If the role definition contains these word combinations, then the periods become rows and the Equity Components Class axis are the columns, ordered as they appear in the presentation linkbase: (a) “stockholder” and “equity” or “deficit” but not “parenthetical” (b) “shareholder” and “equity” or “deficit” but not “parenthetical” (c) “partners” and “capital” but not “parenthetical” (d) “changes” and “equity” but not “parenthetical”.

The personal renderer, which can be downloaded from https://www.sec.gov/structureddata/edgarvalandrender, contains a document with more detailed information about the personal renderer and how it works.

Question B.4 (formerly Question 7)

Q: Will Inline XBRL submissions be accepted in the future?

A: The conditions under which Inline XBRL may be accepted, and how the processing may be integrated into the EDGAR validation and the Interactive Data Viewer processes have not yet been determined.

Question B.5 (formerly Question 8)

Q: What does the Interactive Data Previewer do with filings that do not pass validation?

A: The previewer does not test the validity of the filing; you must do this separately either by submitting it as an EDGAR test filing or using a commercial validation software product that tests filings against the Commission’s rules. The previewer renders invalid filings as best it can, but may fail in a way that does not identify the root cause. Additionally, the previewer may produce results that “look” right, even if the filing has errors that could cause the XBRL to be removed from a live filing if submitted For these reasons, we encourage the use of a test filing prior to final submission.(See A.3).

Question B.6 (formerly Question 9)

Q: How do I arrange for facts with different types to appear on the same row?

A:For the most part, the viewer cannot render facts of different types on the same row.

The rendering engine does have the ability to render complex dimensional data layouts, including rows with a mix of data types, by “embedding” table layout commands into text blocks; this is described in the Risk/Return Rendering guide (see C.1).

Question B.7 (formerly Question 11)

Q: I got some of the label linkbases for my submission from a site that used xml:lang=”en” instead of xml:lang=”en-US”, will they render correctly?

A: It does not matter whether they render correctly in the previewer or not, the submission should be rejected by the Validator if facts use a mix of “en” and “en-US” labels. (See B.5).

Question B.8 (formerly Question 12)

Q: Why is some of my escaped HTML rendering as raw HTML?

A: Make sure that the embedded HTML appears inside of elements whose type is nonnum:textBlockItemType. It is not enough for the element name to end with “TextBlock”. Different versions of the XBRL US GAAP Taxonomy may have more or less consistent element naming conventions, but it is the element type that is important, not the element name. See EFM 6.5.16 for examples of correct escaping.

Question B.9 (Reserved)

Question B.10 (formerly Question 21)

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

A: EDGAR Filer Manual rule 6.13.1 states this requirement more precisely. The presentation relationships within a given role (for a statement, say) must be the same as the original ordering. Also, the indentation of real financial statements is much “flatter” than the deep nesting of a typical standard taxonomy, and the presentation linkbase should reflect that. Also, EDGAR Filer Manual rule 6.13.4 forces parentheticals out of the main statement roles, and into separate roles specifically for parentheticals.

This is why standard presentation linkbases are usually not in the list of taxonomies on the SEC website. Consider: the element order must match the order of the Original HTML/ASCII file. If a standard presentation linkbase (for a statement or a disclosure) were included in the DTS of an instance, then any change of order (due to a difference in materiality, for example) would require both a prohibiting relationship as well as the new label. In the case of the XBRL US GAAP Taxonomies 1.0 standard presentation linkbases, only a small percentage of those presentation relationships even in the smaller statements and disclosures are likely to be a match to the ordering of a filer’s financial statements. The EDGAR Validator lets the filer construct the presentation order appropriate for the instance, and requires no other presentation relationships. A filer should expect their company presentation linkbase to change in some way with every new filing, though perhaps not as much as the instance and labels change.

Question B.11 (formerly Question 32)

Q: How do I make a text block appear by itself in a presentation link role as 6.12.3 seems to require? Do I have to provide a heading?

A: The way to satisfy these rules is to use an abstract to be the parent of the text block, in each of the separate roles. For example,

– 06100 – Disclosure – Business Segments (Level i) Segment Disclosure [Abstract] + Segment Disclosure [Text Block]

– 06101 – Disclosure – Oil Reserves (Level i) Oil Reserves Disclosure [Abstract] + Oil Reserves Disclosure [Text Block]

And so on.

Question B.12 (formerly Question 41)

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

A: As noted in B.3 above, EFM section 6.7.12 describes the technical format of the presentation group “description” field, of which the “Title” is one part. While there is no requirement to follow a standard naming convention for the Title, we encourage filers to use the presentation group titles described below:

• Title Document and Entity Information “Document and Entity Information.”
• Title Level I presentation groups in a manner consistent with the title of the financial statements and footnotes appearing in the original HTML/ASCII version. For example, a title for the balance sheet presentation group might be “Condensed Consolidated Balance Sheets,” and a text-blocked footnote title might be “Commitments and Contingencies.” Also, parenthetical disclosures should follow the naming convention of the financial statement to which they relate, such as, for example, “Condensed Consolidated Balance Sheets (Parenthetical).”
• Title Level II significant accounting policies as one presentation group titled “Official HTML/ASCII Documents’ Note Label (Policies),” such as, for example, “Significant Accounting Policies Note (Policies).”
• Title Level III text-blocked tables “Official HTML/ASCII Documents’ Note Label (Table).” We suggest that all Level III text-blocked tables relating to tables appearing within a single footnote in the original HTML/ASCII version be included in a single presentation group. For example, all tables appearing in the “Cash and Cash Equivalents” footnote would be in the presentation group titled, “Cash and Cash Equivalents (Tables).”
• Title Level IV detail tagged groups “Official HTML/ASCII Documents’ Note Label 1st Table Name (Details),” “Official HTML/ASCII Documents’ Note Label 2nd Table Name (Details),” and so forth.

Also, EFM section 6.7.9 defines the technical format of the presentation group’s ‘roleURI’ attribute which ends with a “mnemonic name in LC3 format”. It is not necessary for that mnemonic name to match the group title word-for-word.

Question B.13

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

A: The rendering engine has been updated to allow users to more easily navigate through the rendered interactive data. Hyperlinks to sections of the filing are now grouped under expandable standard headings. This navigation structure is based on the presentation group ordering currently in use by virtually all filers, so filers should not need to change their existing presentation group ordering to use this structure. Information is provided here to show the standard headings and give examples of presentation groups found under each heading, and for troubleshooting purposes if filers experience an unexpected result with this structure.

• To take advantage of this navigation structure, presentation groups should appear in the following order:
• Document and entity information
• Financial statements and parenthetical disclosures
• Notes to the financial statements
• Significant accounting policies
• Table text blocks
• Detail tagged information

The following table shows the standard headings in the navigation structure and the presentation groups that appear under each of the standard headings. If the presentation groups are in a different order, groups may inadvertently appear under the Uncategorized heading. For example, if “Policy” appears after “Table”, all groups after “Policy” will appear under the Uncategorized heading. Note that using the plural form in a presentation group name, for example “Statements” or “Policies”, will not affect whether the group appears under its designated standard heading.

Question B.14

Q: How should EFM 6.6.7, 6.6.8, 6.6.9, 6.6.10, and 6.13.3 be considered when modeling dimensions on the face financial statements?

A: When applying dimensional modeling to the face financial statements, the XBRL viewer is programmed to render line items with an Axis (dimensions) after those without an Axis (dimension). Due to this rendering programming, it will not be possible to satisfy the requirements of EFM 6.6.7 through 6.6.10 and 6.13.3. Therefore, when using dimensions on the face financial statements, one should apply EFM 6.6.7 through 6.6.10 rather than EFM 6.13.3

Question B.15 (02/05/2013)

Q: When tagging a line item with multiple text descriptions in the original HTML presented in a roll forward for 3 years, the line item element requires three different negating labels which limit the available label roles, does rule 6.11.1 still apply?

A: Yes, to accommodate this scenario, merge the text from the three periods in a way that is readable and does not lose any information.

1. Presentation and Rendering — Risk/Return Summaries

Question C.1

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.

Also please click on the following link to access the Mutual Fund Risk Return Summary rendering guide, http://xbrl.sec.gov/rr/2010/rr-rendering-2010-02-28.pdf.

1. Standard Taxonomies

Question D.1 (formerly Question 15)

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

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

Linkbase files of a taxonomy cannot generally be used except in specific circumstances, in which case the linkbase will appear in the list. Specific circumstances may include:

1. The linkbase defines a form, such as the Form N-1A, that mandates a particularpresentation 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.

Question D.2 (formerly Question 16)

Q: What does it mean to “use the US GAAP Taxonomy” if EFM 6.3.6 prohibits a filing from referring to the US GAAP Taxonomy schema files?

A: US GAAP Taxonomy linkbases are to be used as templates to copy from during the preparation process, but their inclusion in an EDGAR filing tends to load unused linkbases and therefore introduces unwarranted complications such as unused extended links and a need for many prohibiting relationships. Reducing the amount of content in the DTS of the instance to its essentials frees users to more easily link the submitted documents to the linkbases of their particular interest for analysis.

Question D.3 (formerly Question 17)

Q: What does it mean to “use the C&I Industry Taxonomy” if the filing cannot refer to C&I Taxonomy linkbases?

A: As EDGAR Filer Manual rule 6.6.29 says:

The calculation, definition, and presentation linkbases published along with standard taxonomies schemas are extremely useful ways to communicate how elements are related to each other, but these linkbases are to be used as templates by preparers to build their own linkbases to communicate their own intended relationships. Also, any element in a standard taxonomy schema may be used in an instance that has the schema in its DTS independently of which “industry” linkbases it might have appeared in. Therefore it is the elements standing by themselves with their definitions, references and attributes that are definitive.

Question D.4 (formerly Question 18)

Q: Do all the rules in EDGAR Filer Manual chapter 6 apply to the standard taxonomies?

A: No. The rules in EDGAR Filer Manual chapter 6 apply to company extensions and instances. Although the standard taxonomies are consistent with many of the EDGAR Filer Manual rules, here are some exceptions:

• File names, namespaces, schemaLocation and xlink:href attributes of a standardtaxonomy are not restricted by any of the EDGAR Filer Manual rules.
• Element declarations: A standard taxonomy might include elements that do not follow the LC3 convention.
• Role declarations: A linkbase xlink:role might be defined as being used on only one type of linkbase instead of all three.
• Linkbases: Since these linkbases will not be in the submission’s DTS anyway, there may be any number of EDGAR Filer Manual violations.

Question D.5 (formerly Question 19)

Q: Does 6.9.3 forbid the use of ‘prohibited’ arcs because such an arc would then cause some arc to be ‘ineffectual’?

A: The rule applies only to arcs in the company extension taxonomy. If the company extension taxonomy has a ‘prohibiting’ arc that prohibits an arc in a standard taxonomy, then it’s the standard taxonomy that has the ‘ineffectual’ arc, not the company extension.

Question D.6

Q: EDGAR Filer Manual rule 6.5.21 requires some forms to contain a “Document Fiscal Period Focus” entity information element in the Required Context. What values should filers use for this element?

A: Filers should use the following values:

• FY – Fiscal Year, used for annual filing
• Q1 – First Quarter of the fiscal year, used for Form 10-Q filings
• Q2 – Second Quarter of the fiscal year, used for Form 10-Q filings
• Q3 – Third Quarter of the fiscal year, used for Form 10-Q filings

Question D.6.1 (02/05/2013)

Q: I am preparing a FORM 10-KT for a period other than 12 months (e.g., 1/1/2012 thru 8/31/2012), should I use “FY” for the DocumentFiscalPeriodFocus?

A: Yes.

Question D.7 (02/05/2013)

Q: I am preparing a company’s FORM S-4 that also includes XBRL for the acquiring company. Should I include the EntityCentralIndexKey element with our CIK number for the acquiring company?

A: You must provide one EntityCentralIndexKey element in the required context and it should be for the parent (consolidated) company. Note that required contexts are distinguished by having no xbrli:segment elements (e.g., dimension members).

Question D.8 (02/05/2013)

Q: Once a new taxonomy (e.g., US GAAP taxonomy) is approved and available for use, when should a filer make the transition to the new version?

A: The U.S. GAAP taxonomy is subject to accounting standards and changes. In general, we only support two versions of the U.S. GAAP taxonomy at one time. Indication that the updated taxonomy is available for use will be made via the standard taxonomies page at https://www.sec.gov/info/edgar/edgartaxonomies.shtml. The SEC staff strongly encourages filers to use the most recent version of the US GAAP taxonomy release for their Interactive Data submissions to take advantage of the most up to date tags related to new accounting standards and other improvements.

1. Company Extensions and Instances

Question E.1 (formerly Question 3)

Q: Characters that are “special” are forbidden by EDGAR Filer Manual 6.10.6 but they appear in the Original HTML/ASCII, so how do I get them into labels?

A: Use the XML numeric character codes from the column titled Character Reference (Dec) of the table in section 5.2.2.6.

Question E.2 (formerly Question 20)

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

A: EDGAR Filer Manual rule 6.11.1 states this more precisely. Roughly speaking, all the contents of the Original HTML/ASCII Document must appear somewhere in the EX-101 attachments, and all contents of the EX-101 attachments must appear somewhere in the Original. The rules adopted in Release 33-9002 do not require identical appearance, and neither does the EDGAR Filer Manual. Achieving adequate correspondence is the source of many of the “semantic” rules in EDGAR Filer Manual Chapter 6.

This is why standard label linkbases are usually not in the list of taxonomies on the SEC website. Consider: all element labels must match the exact wording in the Original HTML/ASCII file. If a standard label link base were included in the DTS of an instance, then any label that would be different would require both a prohibiting relationship as well as the new label. In the case of the XBRL US GAAP Taxonomies 1.0 us-gaap standard label linkbase, the file is 9MB, containing some 12,000 element labels, yet a very small percentage of those are ever likely to be an exact match to the line item of a filer’s financial statement. The EDGAR Validator lets the filer assign a label to each element that is used in the instance, and requires no other labels. A filer should expect their company label linkbase to change in some way with every new filing, just as the instance will change.

Question E.3 (formerly Question 22)

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

A: EDGAR Filer Manual rule 6.7.12 explains that filers should develop an ordering and naming scheme that is appropriate to the organization of their Original HTML/ASCII Document while supporting a sensible (though obviously not identical) rendering. That implies filer-specific roles. Changing the roles frequently is akin to frequently changing the elements used in the instance: there is no rule against it, but given such freedom to define the roles at the outset, a reasonable amount of forethought should lead to a stable arrangement.

Question E.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 the EDGAR Filer Manual section 6.5.21 for examples of the required context.

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 (EFM 6.5.20)

Question E.8

(Reserved)

Question E.9 (formerly Question 28)

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

A: Yes. Starting with the 2009 US-GAAP taxonomy, a filer may use a language other than US English; Please see EFM 6.5.14 for conditions.

Question E.10 (formerly Question 29)

Q: Since the target of the dimension-default and dimension-domain relationships must be a domain or member, why not also the domain-member relationship?

A: That restriction would not work because the domain-member relationship also represents the hierarchy of primary items.

Question E.11 (formerly Question 30)

Q: Does 6.16.2 allow for multiple dimension-default effective arcs as long as they all have the same source and target?

A: Note that XBRL Dimensions 1.0 specification would require a validation error to be signaled if the targets were different, no matter in which link role they appeared. Furthermore, if the duplicated arcs had the same link role and priority one of them would be ineffectual and thus forbidden by rule 6.9.3.

Question E.12

(Reserved)

Question E.13 (formerly Question 33)

Q: EDGAR Filer Manual 6.7.10 seems redundant with XBRL 2.1’s prohibition on duplicate role declarations.

A: XBRL 2.1 forbids duplicate role declarations in a schema file; 6.7.10 applies to the entire DTS.

Question E.14 (formerly Question 34)

Q: EDGAR Filer Manual 6.8.1 seems to contradict Section 405(c)(1) of Regulation S-T (17 CFR §232.405(c)(1)), which requires each data element and label contained in the Interactive Data File to reflect the same information in the corresponding data in the Related Official Filing.

A: Section 405(c)(1) of Regulation S-T (17 CFR §232.405(c)(1)) takes precedence.

Question E.15 (formerly Question 36)

Q: Should elements for line items appearing with a dash (“-“) in the original HTML/ASCII version be tagged with a “0”?

A: A filer may simply not tag the element for line items appearing as an empty field or a dash. For example, if “Notes Receivable” appears on the balance sheet with a $1,000 balance this year-end and a dash last year-end, the filer can simply not tag the “Notes Receivable” element for last year’s balance. Taking this action will render an empty field by our rendering engine for last year’s balance. Our rendering engine will not currently render dashes. If the filer wants to tag one or more line items that appear with an empty field or a dash with a zero value because that’s what management believes the item represents, and they think the distinction is useful, they can choose to do so. This guidance applies to all the financial statements, including the statement of shareholder’s equity, the financial statement schedules, as well as to footnote data tagged at Level IV.

For the Commitments and Contingencies line item on the balance sheet where all columns are either blank or have dashes, the filer should set the NIL attribute to true without tagging the element with any information. This guidance is described under Edgar Filer Manual Section 6.6.15. Taking this action will render an empty field under all columns by our rendering engine.

Also, a filer may have a line item such as Preferred Stock on the balance sheet where all columns are either blank or have dashes. This could be the case when there are authorized shares, but none are issued. To tag monetary items such as this, the filer can set the NIL attribute to true without tagging any information, similar to the Commitments and Contingencies line item as described above. Taking this action will render an empty field under all columns by our rendering engine. Alternatively, the filer can tag the element with zeros if they believe the distinction is useful.

Question E.16 (Updated 02/05/2013) (formerly Question 38)

Q: Should filers use the pre-defined table structures and axes in the US GAAP Taxonomies?

A: We strongly recommend that filers utilize the pre-defined table structures and axes as they exist in the US GAAP Taxonomies. Creating new hypercubes (tables) and dimensions (axes) should generally be avoided. Custom tables and axes have a negative impact on analysis of the financial information affecting comparability and should be avoided wherever possible. In addition, filers should also avoid creating new domains or changing default member elements for pre-defined dimensions.

For example, when filers are tagging a Property, Plant and Equipment note at Level 4, they should use the pre-defined dimensional Schedule of Property Plant and Equipment [Table], and axes; extending members or line items only when necessary. Similarly, filers tagging components of inventory presented with columns for each balance sheet period should use the pre-defined non-dimensional elements for that disclosure.

Question E.17 (formerly Question 43)

Q: What are some of the nuances associated with preparing an interactive data file in situations involving separate entities filing a single set of financial statements, where multiple CIKs are concerned—such as by a filer who is a consolidated parent company with wholly-owned subsidiaries (which have their own CIKs), or by dual listed companies with their own CIKs?

A: The Division of Corporation Finance’s Compliance and Disclosure Interpretation for Exchange Act Forms 104.16 explains that, in cases of dual listed companies the filer may choose which CIK to use but should continue to use that CIK in every filing as long as the companies continue to be dual listed and file joint reports. Though not addressed in a CDI, in the consolidated parent company case, the CIK of the consolidated parent company must be used. In either of the aforementioned cases, that CIK must then be used uniformly throughout all the XBRL “identifier” elements in each filing, and the same CIK must be used in the identifier element consistently in every filing thereafter. This entity is referred to as the Consolidated Entity and is the “default legal entity,” as described in EDGAR Filer Manual rule 6.6.3. When the facts about more than one entity are contained in a single instance document, it is known as a “consolidating instance” (see EDGAR Filer Manual rule 6.6.4). EDGAR Filer Manual rules 6.6.3 through 6.6.8 detail how to model a consolidating instance, and while they have been summarized in the table below, filers should consult the EDGAR Filer Manual for complete details.

EDGAR Filer Manual rules 6.6.3 through 6.6.8 contain examples and detail the technical structure of the dei:LegalEntityAxis, domain, and members. Additional information can also be found on the Public Seminar on Interactive Data Reporting Requirements Webcast, held Wednesday, June 10, 2009. Part 2 of the archived webcast, at approximately the 20-minute mark, provides additional detail about the multiple-registrant reporting scenario. Slide numbers 38-41 from the Panel 2 Slides (the slide deck which accompanies the webcast) specifically pertain to this portion of the webcast.

Question E.18 (formerly Question 44)

Q: Can I report the CIKs associated with the various subsidiaries as referred to in Question E.17?

A: Currently, the CIKs of subsidiaries are not required to be reported within the single set of financial statements that satisfy the reporting obligations of reports such as Form 10-K. Because of that, the CIKs associated with the various subsidiaries are not required in the respective dei:EntityCentralIndexKey. The EDGAR system allows their inclusion but does not require them. For example, suppose the consolidated entity has a (hypothetical) CIK 9876543210. Then all of the “identifier” elements in the instance must contain 9876543210, and the value of dei:EntityCentralIndexKey in the Required Context must be 9876543210, and the value of dei:RegistrantName in the required context must be the name of the entity with CIK 9876543210. But suppose another (hypothetical) CIK, 8765432109, is reported in the same instance for subsidiary Abcd. In that case the filer may, but is not required to, include facts for dei:EntityCentralIndexKey and dei:RegistrantName that are in a context for which the dei:LegalEntityAxis has the member AbcdMember.

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 (02/05/2013)

Q: What context period should be used for a duration element when the actual date is specified (e.g., “on Sep 14, 2012”)?

A: A duration period may use any period that EDGAR validation will allow and whose end date reflects the specified date.

Question E.20

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

A: EFM 6.8.6 applies to elements with item types other than ‘domainItemType’. Elements with other item types, including (but not limited to) monetary, percent, integer, shares, per share, string, or text block item types, should not include company-specific or period-specific information in the element name. Domain members may include company-specific or period-specific information in the element name.

For example, filers should not create a monetary element with the name “AcquisitionOfDefCo” or FourthQuarterAdjustment”. However, they may create a domain member with the name “AbcSegmentMember”.

Question E.21

Q: How are units (units of measure) used in an interactive data filing?

A: Every amount in an XBRL submission is associated with an XBRL item type, an underlying data type, and a unit (short for “unit of measure”), determined by the element selected and the nature of the amount being reported. Common XBRL item types include Monetary, Shares, Decimal, Integer and Pure. These may be further distinguished as to data type, which could be the same as the item type or a specialization of it; for example, the Monetary data type allows any number to appear; the Non-Negative Monetary data type excludes negative amounts. The US GAAP taxonomy and SEC taxonomies mainly use data types defined in XBRL 2.1 itself or in the standard Data Type Registry (DTR).

The XBRL item type and data type are still not enough in most cases to completely define an amount, and so XBRL 2.1 requires every amount to have a unit. In this way, XBRL item types, particularly Decimal or Integer item types, use units to further distinguish the nature of the amount. For example, the unit used for earnings per share amounts reported in US dollars is “USD per Share”. Specialized units also are used to report nonmonetary measurements. For example, amounts may be reported in units of measure such as megawatts, millions of barrels, millions of bushels, or employees.

The Pure XBRL item type is used with elements that describe percentages, rates, and ratios, and typically use the Pure unit. However, the staff has observed some filings to date in which the Pure unit has been used for other item types. The staff recommends as a best practice and to promote consistency and comparability that the Pure unit only be used with the Pure XBRL item type, and not with other item types. Additionally, the staff recommends that the Pure unit be used only for amounts which are percentages, rates or ratios.

Under EFM 6.5.35, if a standard numeric data type registry namespace is in the DTS of an instance, then the unit used for an item type must be the unit listed in the registry for that item type. Currently, the standard units registry is not yet available. The Staff expects that it eventually will be included in a future version of the DEI (Document and Entity Information) Taxonomy and notice will be provided of its inclusion. Until it becomes available, the staff recommends as a best practice that filers select the unit type that most closely fits with the item and data type. The following table gives examples of commonly used XBRL item types, data types and corresponding units:

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 required and allowed. However, as EFM 6.3.10 implies, the submission must contain at least one EX-101.SCH (schema) but may contain more. In general there can be any number of EX-101.PRE (presentation linkbase), EX-101.LAB (label linkbase), or EX-101.DEF (definition linkbase) attachments (EFM 6.8.2). The total number of attachments is subject to any overall limit on attachments imposed by EDGARLink Online.

Additionally, EFM 6.7.4 and 6.7.5 together allow the target name space attribute of each schema to have formats such as “http://example.com/20111231”, “http://x.example.com/20111231”, “http://y.example.com/20111231” and so forth.

Question E.23 (02/05/2013)

Q: Can a company extension schema contain unused elements and their linkbase relationships (e.g., presentation, calculation)?

A: Yes. Unused elements (i.e., those elements which do not appear in the current instance document exhibit) and their linkbase relationships may be contained in the extension schema to simplify maintenance and reuse (e.g., between quarterly and annual reports) of the extension schema. However, it is recommended that unused elements and relationships that serve no further purpose be removed from the extension schema.

Question E.24 (02/05/2013)

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

A: Yes, calculations that meet the EDGAR Filer Manual rules for calculation linkbases (see EDGAR Filer Manual rules in sections 6.14 and 6.15) outside of a required context are optional. Note that required contexts are distinguished by having no xbrli:segment elements (axes and dimension members).

Question E.25 (02/05/2013)

Q: My FORM 10-K includes line items in the original HTML/ASCII that come under the EDGAR Filer Manual calculation rules in sections 6.14 and 6.15. However, those same line items are presented in both a primary statement and a footnote. Furthermore, the footnote contains additional line items which are not found in the primary statement. Will a single set of calculation linkbase relationships which include all required line items in the footnote satisfy the EDGAR calculations requirements for both sets of items?

A: Every required calculation relationship applies to the entire filing. An element should be the source (e.g., current liabilities) of only one calculation relationship for any one target (e.g., current portion of long-term debt), without regard for base set (e.g., balance sheet, debt footnote). See EDGAR Filer Manual section 6.15 for additional detail.

Question E.26 (02/05/2013)

Q: If a company changes its name or ticker symbol, should the XBRL file names and recommended namespace prefix be changed to conform to the new name?

A: EDGAR Filer Manual rule 6.3.3 indicates that document names should begin with the registrant’s ticker symbol or some other mnemonic abbreviation and should be the same as that used for the instance in the same submission. Although not a requirement, if a company subsequently changes names or ticker symbols, we suggest the file names and recommended namespace prefix mnemonic abbreviation be updated to reflect the change.

Question E.27 (New 01/26/2016)

Q: What are the conditions for determining when a calculation relationship is required?

A: The Commission’s rules require filers to include calculation relationships for certain contributing line item elements for financial statements and related footnotes. Required calculation relationships in XBRL company taxonomies provide key information that shows the relationships among elements and their corresponding numeric facts, and how they add and subtract to each other. In addition, required calculation relationships enhance data quality by:

• 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 2), Chapter 6, Sections 6.14 and 6.15 set out specific calculation relationship requirements, including certain examples and exceptions. Section 6.14 addresses the syntax restrictions of calculation relationships. Section 6.15 addresses the content of calculation relationships.

Item 6.15.2: Determining when calculation relationships are required

Item 6.15.2 of the EDGAR Filer Manual states:

“If the original HTML/ASCII document shows two or more line items along with their net or total during or at the end of the Required Context period, and the instance contains corresponding numeric facts, then the DTS of the instance must have an effective calculation relationship from the total element to each of the contributing line items.”

If a line item satisfies all of the following five conditions, as set out by Item 6.15.2, the line item requires a calculation relationship:

Condition 1. In the HTML/ASCII filing, does the line item appear in either the financial statements or the footnotes? (Note: If the line item appears in both the financial statements and the footnotes, you should answer “yes” to this question.)

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

• 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?

• Any line item that meets all the 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?

• 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 Item 6.5.19 of the EDGAR Filer Manual).

3. If line items have corresponding numeric facts in different contexts, is a calculation relationship required between them?

• Although permitted, line items with corresponding numeric facts in different contexts do not require a calculation relationship.

1. Detail Tagging

Question F.1 (formerly Question 37)

Q: Should the formatting of footnote tables that result from tagging at Level 4 match exactly the format presented in the original HTML/ASCII version?

A: No. There is no requirement that facts tagged at Level 4 render in such a way to ma tch the formatting in the original HTML/ASCII version. For example, the axes may be reversed in the XBRL table structure from that presented in the original HTML/ASCII version and there may be blank cells in the XBRL table structure where “-” appear in the HTML/ASCII version. In addition, facts appearing within the same footnote in the original HTML/ASCII version may be incorporated into the table structure for tagging purposes.

Question F.2 (formerly Question 40)

Q: Does the EDGAR Filer Manual rule 6.8.6 limiting the use of company-specific elements apply to tagging at Levels 2, 3, and 4?

A: Yes, but see the clarification in Question E.20.

Question F.3 (02/05/2013)

Q: Outside of the primary financial statements, is superscripted text at the bottom of a footnote table allowed to be included in an XBRL footnote link element?

A: Yes, including the superscripted text at the bottom of a footnote table in an XBRL footnote link is optional. Note that any required amounts in superscripted text must be separately tagged as part of Level 4 tagging requirements.

Question F.4 (02/05/2013)

Q: When tagging a narrative disclosure using “no” or “none” such as “There were no impairment losses for the years ended December 31, 2012, 2011, and 2010, respectively should a value of zero be tagged for each of the disclosed periods”?

A: In general, if you can replace the word “no” or “none” with a zero and it does not change the meaning of the sentence, then you are disclosing an amount. From Compliance and Disclosure Interpretations – Regulation S-T Question 130.04 – “Each amount, whether expressed numerically or textually, must be tagged separately under Rule 405(d)(4)(i). This guidance also applies to tagging each amount within the financial statement schedules under Rule 405(e)(2)(i) of Regulation S-T. Each tagged amount must be mapped to the applicable monetary, decimal, percent, integer or shares data type element”.

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

URL-6:https://www.sec.gov/info/edgar/specifications/edgarfm-vol2-v53.pdf

APPENDIX B. FREQUENTLY ASKED QUESTIONS

The Filer Support Branch in your subject matter division helps filers with general filing andtechnical information or assistance. You can reach Filer Support Staff during the hours of 9:00A.M. to 5:30 P.M. on business days. The phone number is (202) 551-8900. Many of thequestions that Filer Support staff answer daily involve similar issues. We have summarized themost frequently asked questions and their answers in this section. Please review this sectionbefore calling Filer Support. Filer Support voicemail will be available during off hours.