Staff Observations From Review of Interactive Data Financial Statements (from June 15, 2011)
March 22, 2016
The staff in the Commission's Division of Risk, Strategy, and Financial Innovation has completed a review of the Interactive Data Financial Statement submissions for compliance with the Commission's rules relating to interactive data for financial reporting. Overall, the filings indicate that filers continue to devote significant effort to consider their responsibilities under this program, comply with the new rules and provide high-quality submissions.
We performed the reviews on filings submitted during the first 2 months of 2011, which include Form 10-K’s from Large Accelerated Filers the largest of which provided detailed tagged data. The staff's reviews were conducted using data analysis tools to survey the entire population of filings and data points and, where appropriate, to review details of specific filings and tags on a targeted basis.
We have identified certain areas where there were common issues with the filings. As companies continue through the phase-in of the interactive data requirements, with the ongoing introduction of detailed tagging of notes to the financial statements and the phase-out of the limited liability provisions, we encourage them to prepare future filings that are consistent with the themes of our observations.
The observations included below represent the most common and significant issues from the filings analyzed and do not reflect all issues identified during our review. Over time, the staff intends to evaluate the interactive data filed with the Commission and publish findings. It is our expectation that the where the issues identified are related to the rules of the Commission they can be addressed by filers in their next series of interactive data filings. We believe this will help increase the overall quality of the interactive data submissions and the usability of the data. The observations represent the views of the staff in the Division of Risk, Strategy, and Financial Innovation. They are not rules, regulations, or statements of the Securities and Exchange Commission. Further, the Commission has neither approved nor disapproved them.
Observations for filers tagging the face of the financial statements
Format of the statements:
Many new filers ask if the rendered version of the XBRL financial statements need to look exactly the same as the HTML financial statements.
The answer is no. Filers should concentrate on the quality of the tagging rather than trying to match the rendering of the XBRL exactly to the HTML filing. The rendered version of the XBRL financial statements need not exactly match the HTML statements. In this regard, the Division of Corporation Finance issued the following guidance in 2009 in its Regulation S-T C&DI 130.08. The C&DI reads as follows:
Question: Must an Interactive Data File that complies with the requirements of Rule 405 of Regulation S-T appear identical to the traditional format financial statements when displayed by a viewer on the Commission's website?
Answer: No. There is no such requirement.
Further, the rendered version of the Interactive Data File may be a useful tool to help determine the completeness of your data, but is not the best mechanism to check the accuracy of the tags selected or other underlying details. Your software vendor or service provider may be able to provide information to allow a complete review of the elements selected and whether the data has been entered correctly.
While many times in the HTML filing numbers are presented as negative, they should almost always be tagged as positive numbers in the XBRL submission. Checking the validity of negative values cannot be done from the rendered copy of the XBRL financial statements.
One of the most common errors filers make is to incorrectly enter an amount with a negative value. Most XBRL tagged numbers are positive even if the original value is a credit or negative on the printed financial statements. For example, we noted a number of filers who incorrectly entered the standard Revenue element with a negative value and slightly more filers who incorrectly entered Shares Issued with a negative value. Filers entering data this way may have their data misinterpreted by users or will require an extra step to clean the data before it can be used for analysis, and their substandard data quality will be highlighted for regulators and analysts.
A good question to ask yourself is, “Does it make sense for the element to be negative?” We have seen a number of elements being used where their definition does not support the negative value. Using the Revenue element example noted in the previous paragraph above, the USGAAP taxonomy definition is:
“Aggregate revenue recognized during the period (derived from goods sold, services rendered, insurance premiums, or other activities that constitute an entity's earning process). For financial services companies, also includes investment and interest income, and sales and trading gains.”
Based on the definition, the amount attached to this element would not be negative.
The table below gives examples of the language that is in element definitions that can be negative. It is extremely rare that elements without these phrases in the definition are negative for Level 1 filers.
|Statement||If the definition contains this
language it can be negative
|Cash Flow||Increase decrease|
|Cash flow||Provided by used in|
|Cash flow||Change in|
|Cash flow||Proceeds from payments for|
|Cash flow||Proceeds from payments to|
|Income statement||Gain Loss|
|Income statement||Profit Loss|
|Income statement||Income expense|
|Income statement||Per share|
|Statement of Stockholders Equity||Equity|
|Statement of Stockholders Equity||Retained Earnings|
The question of when to extend versus when to use a USGAAP element from the standard taxonomy is an area that will require judgment from filers. In making that determination you may wish to consider the following guidance:
- Don’t extend when an existing US GAAP taxonomy element is available. Use software to search for appropriate elements in the taxonomy and examples from existing submissions. Make sure your search software can make use of the hierarchy (period type, item type, definition, label and references) in EFM 6.6.23 - 6.6.29 to help narrow your searches.
- Extend only when there is a material difference between the standard US GAAP element and the filer’s financial statement line item. (EFM 6.6.24 and 6.6.25)
- Don’t extend solely to achieve a desired formatting of the XBRL data. Attempts to achieve a particular formatting result can be time consuming, and as Regulation S-T C&DI 130.08 states, are not required. Creating extensions solely for formatting purposes will likely lead to lower data quality in the submission. As stated above, filers should concentrate on the quality of the tagging rather than trying to match the rendering of the XBRL exactly to the HTML filing.
Completeness of tagging:
Filers should also ensure that parenthetical amounts on the financial statements, monetary amounts found in subscripted text, for example where a component of a financial statement disclosure is disclosed, and Regulation S-X Article 12 schedules are tagged. Examples of these are the Allowance for Doubtful Accounts and the Valuation and Qualifying Accounts schedule.
Additional Observations for Detail Tagged Filings:
Modeling of Level 4 tagging:
We noted in our review process that there was significant diversity in the modeling of line items, axes and members in the 10-Ks submitted by filers. We have noted cases where the US GAAP taxonomy has standard tables modeled and filers have unnecessarily extended axes and members and not used existing elements in the US GAAP taxonomy. To the extent that filers are doing this to achieve particular formatting results and not just tag the data, as we’ve noted above, there is no requirement to adjust the formatting of the XBRL submission so that it looks like the HTML filing, just a requirement to tag the data accurately.
We note that extended axes and members are subject to rules similar to those governing line items. Extension should only be made when the line item, axis or member is not currently available in the US GAAP taxonomy. We remind filers that they should adhere to our guidance to use the standard US GAAP tables wherever possible. Not only will this improve the quality of the submission, but it should be less time consuming for the filer.
Modeling of extensions in 2011 taxonomy:
We have noted numbers of extensions where filers have used different balance attributes on the extended element compared to similar US GAAP elements. We encourage filers to be as consistent as possible when creating extensions and “borrow” as much as possible from the US GAAP taxonomy when determining balance attributes for extensions. For example, extending for the element “Payment for XXXXX” filers would look to the US GAAP taxonomy and see that similar elements have a “Credit” balance attribute. Therefore, the extension should have a Credit balance attribute.
We noted that filers had tagged data incorrectly as negative values in the detail tagged notes to the financial statements. There are a number of ways to check for errors in negative values. First, look at the element and ask whether the negative value is appropriate considering the definition of the element. The example of Revenue above illustrates where negative values are not supported by the definition of the element. We recommend that filers critically review each negative value against the definition to ensure that the negative value makes sense and does not represent negative revenue as in our example above.
Second, examine other filings. Comparing the use of negative values to other XBRL financial statements may reveal issues with the negative values.
The third method will require use of software and an examination of the filer’s calculation linkbase. Elements in the USGAAP taxonomy are given a standard weighting of either 1 or -1. The weighting will rarely need changing. We recommend that filers review all elements where the weighting has been changed from the standard weighting, ensuring that the sign of the number is correct.
Every element in the US GAAP taxonomy has an XBRL item type attribute, and filers must use a unit in their interactive submissions which is consistent with that XBRL item type (EFM 6.5.35). For example, elements with a Monetary XBRL item type must use a unit, such as USD, which defines the currency in which the monetary amount is reported. We noted that filers incorrectly used Pure units with elements which do not have Pure XBRL item types. The Pure unit should not be used with other XBRL item types, such as Decimal or Integer, and should not be used with amounts such as useful lives, expected contractual terms, notional amounts, volume of gas or oil, or counts such as number of employees or number of properties held.
Other observations from certain filings include:
- Monetary values, percentages or numbers required to be tagged were tagged only with string type elements. For example, numbers expressed alphanumerically such as one, two, or one third, numbers expressed as a ratio such as 1 to 5 or 4 to 1, numbers expressed as decimals such as .2 or .4, and numbers with descriptions such as 1 million, 25 cents or 2,000 barrels a day were tagged only with string type elements. These amounts may be tagged with a string type element, but must also be tagged separately as amounts.
- Regulation S-X Article 12 schedules, particularly Valuation and Qualifying Accounts, were not detail and block text tagged in accordance with Regulation S-T, Rule 405. We remind filers that these schedules should be tagged at Level 4 when the filer is detail tagging.
- Monetary amounts found in subscripted text to tables within the footnote disclosures had not been tagged in accordance with EFM 6.6.22. The EFM requires these amounts to be tagged.
- We have received certain submissions that contain either no calculation links, or many fewer calculation links than required by Section 6.15.2 of the EDGAR Filer Manual. Although this will not currently generate a validation error or warning these submissions are not in compliance with the EDGAR Filer Manual. The required calculation links are useful for consumers of the data.