Blog, External Reporting, Featured

Guide to New Interactive Data (XBRL) Rules in the EDGAR Filer Manual (for Corporate Filers)

As you may or may not know, the SEC recently released an updated EDGAR Filer Manual, Volume II (“EFM”) Version 48, that became effective on October 1, 2018. The changes in the Interactive Data, or XBRL, section aim to improve data quality through additional XBRL validation including document and entity information, negative values, custom axes, and deprecated elements. There was also a rule change related to duplicate values in preparation for upcoming inline XBRL requirements. Filers should familiarize themselves with these changes in anticipation of upcoming filings.

The first change in the Interactive Data section is to rule 6.5.12. In the previous version of the EFM, Version 47, this rule prevented XBRL documents from containing more than one fact with equal tagging attributes unless their values were identical. In other words, if net income for the three months ended Sept. 30, 2018 is $5.2 million in the income statement and the same concept (tagged the same way) is $5 million in the segment note, both values cannot be included in the XBRL data because 5,200,000 is a different value than 5,000,000. With the release of Version 48 of the EFM, this rule allows consistent values to be duplicated in the instance document. Values are generally consistent if they are rounded properly.

Note: Due to rule 6.5.12 as it previously existed, some software does not yet support the inclusion of consistent, duplicate values in the instance document, so until they are supported, continue to include only the more precise value in the instance file.

Rule 6.5.40 contains a set of 13 cases in which information about the entity and its submission is checked for consistency. For example, if a filing requires the element CurrentFiscalYearEndDate, the EDGAR system will check for this element, then compare its value with the known fiscal year end date of the entity. Another consistency check related to this rule is whether the EntityEmergingGrowthCompany element is present and if its value is consistent with the emerging growth company flag in the submission header. Inconsistencies, missing elements, and even extra elements related to this rule will result in EDGAR warnings during test filing. Because the requirements vary by filing and entity type, it’s important for filers to familiarize themselves with the rule and test file early.

Three new rules follow 6.5.40 with a further emphasis on data quality. Note: rule 6.5.41 is new, but it is not discussed here because it is related to investment management company forms.

  1. EFM 6.5.42 – This item relates to deprecated elements. It states “Facts, Axes, or Members should not use an element name that has been declared “deprecated” in any version of its standard namespace.” Currently, the SEC is accepting four taxonomy versions, the 2018 and 2017 US GAAP and IFRS taxonomies. If an element is deprecated in any of these taxonomies, a warning will result during test filing regardless of the taxonomy version being used for the filing. If you get this warning use element references, FASB implementation guides, Data Quality Committee Rules, etc. to determine the proper replacement, if appropriate. When elements are deprecated, the reference section includes the reason for deprecation and the suggested replacement, if any.
  2. EFM 6.5.43 – This item relates to negative values. The EDGAR system checks a list of certain elements (IFRS and US GAAP) for negative values, excluding those tagged with dimensions that allow negative values (such as ConsolidationEliminationsMember or RestatementAdjustmentMember.) See below for a detailed list of elements. If you receive a warning related to this rule, you should carefully consider whether the indicated value should be negative. These warnings can often be resolved by using a different element for the negative value. Let’s look at an example from the list of “non-negative” elements defined by the EFM, DeferredTaxAssetsLiabilitiesNet.
    The example below presents a ‘Components of Deferred Tax Assets (Liabilities)’ table in which the net result at the end of one period is an asset, and in the other period, the result is a liability. In this case, each value in the last row should be tagged individually. This is because the DeferredTaxAssetsLiabilitiesNet element is specific to assets (net of liabilities} and should only have a positive, debit value in the instance document. A deferred tax liability, or credit, element should be used for the value representing a liability.

    Note: Don’t forget to negate this value to ensure that the instance document value represents a a positive credit.
  3. EFM 6.5.44 – This rule checks for custom axes that duplicate the purpose of certain existing standard axes. During instance document validation EDGAR checks for variations of the names of standard axes and issues a warning if any similarities are found. While only a list of nine axes are included in the validation, filers should be cautious about extending custom axes in general as the Securities and Exchange Commission has released staff observations specifically to reduce the rate of custom axes in XBRL filings. https://www.sec.gov/structureddata/reportspubs/osd_assessment_custom-axis-tags.html. If you encounter this warning during test filing

The key takeaway here is that there is a variety of new warnings that you may encounter while submitting filings that include XBRL data this quarter. It’s a good idea to get ahead of any warnings that you can by reviewing negative values and checking for custom axes and deprecated elements in your company’s taxonomy. Although the EntityEmergingGrowthCompany and EntitySmallBusiness elements are not required to be included with DEI information, they are included in the conditions of EFM rule 6.5.40, so adding them before test filing will prevent warnings. Once you’ve reviewed for items related to EFM changes, test file. Test file as early as possible; give yourself enough time to address any warnings.

Interested in learning more about how Certent can support your XBRL reporting process? Click here for more information.

 
 

Leave a Reply

Your email address will not be published. Required fields are marked *

 

More from Categories

 
 
 

Back