SEC Seal Home | Jobs | Fast Answers | Site Map | Search
U.S. Securities and Exchange Commission


Staff Observations from the Review of Interactive Data Financial Statements (from December 13, 2011)

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 continue to indicate that filers are devoting significant effort to understand their responsibilities under this program, comply with the new rules and provide high-quality submissions.

We performed the reviews on filings submitted for the second quarter of calendar 2011, which include the first submissions made by the third phase-in group as well as the first detailed tagged submissions of the second phase-in group. 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. It is our expectation that 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

We continue to see the same issues around the topics of formatting of the financial statements, negative values, use of unnecessary extensions, and the completeness of the tagging (i.e., parentheticals and string values). Filers should continue to pay attention to these topics when submitting information to the Commission and should carefully review our previous Staff observations (http://www.sec.gov/spotlight/xbrl/staff-review-observations.shtml).

Format of the statements:

Many new filers ask if the rendered version of the XBRL financial statements needs 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. Furthermore, filers should not create custom elements or use incorrect dates in their contexts just to achieve specific rendering results.

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.

Negative Values:

Although numbers shown in the HTML attachments of an EDGAR submission may be presented as negative, they should almost always be entered as positive numbers in the XBRL instance attachment. Checking the validity of negative values cannot be done from the rendered copy of the XBRL financial statements.

The most common error filers make is to incorrectly enter an amount with a negative value. Most XBRL tagged numbers are positive even if the value is presented with brackets on the printed financial statements. For example, we noted a number of filers who incorrectly enter expense items on the income statement such as Interest Expense with a negative value. Filers entering data this way may draw undue attention to their submissions.

A good question to ask yourself is, “Does it make sense for the element to be negative given its definition?” We have seen a number of elements being used where their definition does not support the negative value. Using the Interest Expense element example noted in the previous paragraph above, the U.S. GAAP taxonomy definition is:

“The cost of borrowed funds accounted for as interest that was charged against earnings during the period.”

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 definitions of elements that can be negative. It is extremely rare that elements without these phrases in the definition are negative on the face financials.

Statement If the definition contains this
language the element can be negative
Cash Flow Increase (decrease)
Cash flow Provided by (used in)
Cash flow Net
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

If you consider the typical balance attribute for an element (credit or debit) only atypical situations would give rise to the need for a negative value based on the structure of the taxonomy. Take for example the element Interest Expense. When this element is presented on the printed income statement it sometimes contains <brackets> around it to give the appearance that it is being subtracted from Revenue. However, since this amount has a debit balance it will be automatically subtracted from Revenue since Revenue has a credit balance and therefore it would be inappropriate to enter a negative amount for this element.

If filers wish to achieve the rendering effects of brackets around this amount to indicate that the amount is being subtracted from the revenue amount, the filer should negate the label. However, it should be noted that just negating the label will not ensure that the amount entered is correct.

Another way to look at this example is through the table below which demonstrates how the arithmetic works for debit and credit balances. In our example, Revenue is a credit balance and as such all credit balance items would be added to Revenue (as indicated by the positive 1 at the intersection of the CREDIT column and the CREDIT row in the table below) and all debit balances would be subtracted from Revenue (as indicated by the negative 1 at the intersection of the CREDIT column and the DEBIT row). Therefore, a negative value for Interest Expense would actually be adding the value to revenue rather than subtracting it as it should.

  CREDIT DEBIT
CREDIT +1 -1
DEBIT -1 +1

Extended elements:

The question of when to extend versus when to use a U.S. GAAP element from the standard taxonomy is an area that will require judgment from filers. In making that determination filers may wish to consider the following guidance:

  1. Before creating a custom element consider whether an existing U.S. GAAP taxonomy element is available. Your software may be enabled with search filters (period type, item type, definition, label and references in EDGAR Filer Manual (EFM) 6.6.23 - 6.6.29) to help narrow your searches.
     
  2. There is no need to extend solely based on minor, immaterial differences in the definitions. (EFM 6.6.24 and 6.6.25)
     
  3. Do not 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 ensure that parenthetical amounts on the financial statements and monetary amounts found in subscripted text are tagged. Examples of these are the Allowance for Doubtful Accounts and endnotes to tables that contain financial information. Section 6.6.22 of the EDGAR Filer Manual requires that these amounts be tagged.

We have also noticed some filers failing to include a calculation linkbase with their submissions. EFM Section 6.15.2 requires calculation linkbases.

Additionally, we continue to notice filers tagging numerical amounts written as text with string type elements. Some examples are “seven hundred,” “two thirds,” and “one percent.” Filers should tag these amounts with a numerical value rather than a string value.

Other observations

Filers that are subject to the interactive data requirements must include XBRL with certain registration statements filed under the Securities Act of 1933 that physically, rather than through incorporation by reference, include financial statements once the registration statement contains a price or price range. Failure to comply with this requirement will result in the loss of short form eligibility and may be remedied only by both submitting the XBRL to the Commission and posting it on the issuer’s corporate website, if any.

 

http://www.sec.gov/spotlight/xbrl/staff-review-observations-121311.shtml


Modified: 12/13/2011