A recent hot topic in XBRL is the issue of reporting the appropriate sign for associated values in an SEC submission. The SEC has focused on this issue in their November 1, 2010 staff observations (http://www.sec.gov/spotlight/xbrl/staff-review-observations-110110.shtml) as have many analysts in the marketplace. The most common of these errors cited by the SEC relates to incorrectly entering an amount as negative when it should be positive. Many XBRL teams and their providers suggest clients carefully review all negative amounts in the submission to diminish the risk of filing with errors, particularly given the SEC’s recent focus.
While less prevalent, there is also a risk of incorrectly submitting a fact with a positive sign when it should be negative. This risk is usually more prevalent with “two-way” reporting concepts (explained later) that could be entered as a positive or negative.
Regardless of the type or cause of errors, these issues should be avoided because they negatively impact the data quality of the XBRL filing.
This 3 part blog will cover the following areas:
- Significance of Incorrect Signs in XBRL and Examples of Common Errors and How to Correct Them
- How to Apply the Sign Concepts to an Indirect Cash Flow Statement
- Features and Tools to Assist in the Review Process
Sign Values in XBRL – Part 1: Significance of Incorrect Signs in XBRL and Examples of Common Errors and How to Correct Them
The XBRL community is increasing its focus on companies’ appropriate reporting of XBRL data related to sign. This is important for many companies that submit XBRL data for reason alone that it is an SEC requirement1. Beyond the SEC’s rules relating to XBRL submissions, it is important for the signs to be correct so analysts interpret the data appropriately. When an incorrect sign is entered in XBRL, this usually means that a debit is reported as a credit or vice versa. Misreporting the nature of an amount like this can often go undetected, particularly because analysts can use the power of XBRL to focus a query of data around one or more XBRL elements which might be in isolation of other associated amounts or text that might expose the error. As can be seen below in Figure 1 from XBRL US as of 4/18/11, thousands of these potential errors have been detected in SEC filings to date:
In an oversimplified example, perhaps an analyst wants to know which SEC filers have the highest dollar gains on their investments. The analyst might create an XBRL report that queries all SEC filers and presents the data for the XBRL element us-gaap:GainLossOnInvestments. Since this element has an XBRL balance attribute of credit, the analyst would interpret positive values to be credits (gains) and negative values to be debits (losses).
If any of the company’s filings include errors with respect to the sign, it could greatly skew the results and interpretations made by the analyst. In this example, if a filer entered a loss with a positive number in XBRL (not an uncommon error – see examples in next section), it would be interpreted as a gain. This type of error might be the most dramatic as reporting a company’s loss as a gain could have a very material and misleading impact on analyst decisions.
In the example above, the analyst may not easily detect an error because the gain (loss) data is reported without any additional narrative or other context.
Being a part of an XBRL community that reports accurate XBRL data is critical to reap the benefits of this widely growing and international reporting format. The analysis will only be as good as the quality of data provided. To comply with SEC guidance, it is crucial to understand these important XBRL concepts and develop review measures designed to minimize the risk of errors.
Examples of Common Errors and How to Correct Them
From the above section, we can appreciate the significance of reporting incorrect data. This section provides some simple and common examples that demonstrate how the errors manifest themselves, and then how to correct them.
The first piece of understanding the nature of this accounting concept is to determine if it is “one-way” or “two-way.” These are important terms because they are frequently used by the SEC and also by XBRL technologists.
One-way: The term one-way is used to describe taxonomy elements that represent an accounting value that is typically always a debit or always a credit. Since the net balance of the account is unlikely to ever change, it is considered a one-way element. A good example is us-gaap: TreasuryStockValue which should always hold a debit balance. Since it would never take a credit balance, it is considered one-way.
Two-way: The term two-way is used to describe taxonomy elements that represent an accounting disclosure that can be either in a debit or credit position at any given time. Since the element can be either debit or credit, it is considered two-way. A good example of a two-way element is us-gaap:GainLossOnInvestments since during one period it could be a loss (debit) and during another reporting period it could be a gain (credit).
Let’s follow through with an example of a common error related to a one-way reporting element, and how to fix it.
In the image above, note the line item “Less: Accumulated depreciation” and its associated amounts that are reported with parentheses. This type of presentation is quite common in an HTML filing of public companies. When choosing an appropriate XBRL element for this line item, one might select the element us-gaap_AccumulatedDepreciationDepletionAndAmortizationPropertyPlantAndEquipment.
If the preparer stopped here and associated the element with the negative value presented above, the value would be reported incorrectly for XBRL and violate the SEC’s guidance at EFM 6.6.30.
Why is it wrong? The us-gaap element noted above has a balance attribute of credit (see image below) so reporting this fact with a negative amount would actually mean to an XBRL user that the amount is a debit (negative credit = debit). It is always very important to know the balance attribute of the element being used as the instance document value is directly affected by the balance attribute of the element being used. The options for the balance attribute are debit, credit, or in rare cases, unspecified. In this example, the balance attribute for the element described is credit.
Before discussing how to fix it, let’s discuss two common ways XBRL data can be used or viewed. Perhaps the most important way XBRL data is viewed is the consumption or aggregation of reporting facts by a computer. This type of use demonstrates the true power of XBRL and can be queried from the instance document (included as Exhibit [EX-101.INS] in the SEC filing). Another way XBRL is viewed is through a rendering, such as the rendering that can be found from the link to the filing on the SEC Website: 
A rendering is also based on the reporting facts found in the instance document, but it also takes commands from data contained in the presentation linkbase (included as Exhibit [EX-101.PRE]). The presentation linkbase is in charge of the organization and presentation of information for rendering.
If we stopped here in this incorrect state, we would have incorrectly reported the Accumulated Depreciation as a debit in the instance document, the place where many computers go to analyze the data. From a rendering standpoint, the amount is negative and might appear correct because it matches the HTML. But because we looked at the instance document value for this as a negative, we know the behind-the-scenes value is wrong and is reporting this as a debit. This is exactly why XBRL can be confusing to newcomers. An amount can appear to be correct in the rendering but actually be wrong for data analysis.
Later I will discuss some software tools and review reports that can make the process easier, but before that, let’s look at how to correct the issue.
How to fix an issue with sign in XBRL:
There are usually two steps required to fix an issue related to sign in XBRL. In the example above, we noticed that the Accumulated Depreciation was incorrectly recorded as a debit; however, it was rendering the way we would expect, and it matched the HTML. In this way, it seems that there is only one issue, and that might lead someone to think there is only one correction step necessary. But in XBRL, we actually need two correction steps to address this disclosure appropriately.
The first correction step is to change the sign of the value that is recorded in XBRL. This is important because it correctly reports the Accumulated Depreciation as a credit. But if we left things like that, the rendering would show this is a positive which would no longer match the HTML. This is why the next correction step is important.
The second correction step is to report the amount with a negated label. This label will be stored as the preferred label in the presentation linkbase for this report. Using the negated label as the preferred label in the presentation linkbase tells the SEC’s Rendering Engine to flip the sign of the amount for rendering that is included in the instance document.
As one more example, let’s look at text in a narrative portion of a disclosure that might look like:
In the image above, the $51 million loss is shown as a positive number in the filer’s disclosure. If the element us-gaap:GainLossOnInvestments is selected, it is very important the filer recognizes that the balance attribute of the element is a credit and reports the value in XBRL as a negative (first correction step above) and uses the negated label (second correction step above.) Failing to record this amount correctly would result in reporting this $51 million loss as a $51 million gain.
[1] The SEC’s EDGAR Filer Manual at Section 6.6.30 requires filers to invert the sign of numeric facts whose Balance Type is inconsistent with the reporting concept of the amount being disclosed.
