What Happens When Values In XBRL Are Captured With Wrong Signage

Of late, there have been several articles on the quality of XBRL documents. One issue that the reviewers have consistently pointed out is the fact that the values need to be captured with correct signage. One of the main drivers for this requirement is EFM rule 6.6.30, which states that the sign of a numeric fact should be inverted only when the balance type of the element is inconsistent with the reported concept. It is important to understand the implications of this rule is not followed.

If you study the above HTML report, the values associated with ‘Cost of Service Revenue’ are given in parenthesis, which is the general presentation that I have found in most HTML reports. However, when I checked the XBRL documents, I found that the company has captured these values negative (please refer to the below-given screenshot). The company has captured the values as it was given in the HTML. Herein lies the problem. Simply because the value in HTML is given within parenthesis does not mean that the value in XBRL should be captured in negative. XBRL can separate the presentation layer from the calculation layer i.e. the way the information is captured for calculation purposes, versus the way it is captured for presentation purposes. In the light of this example, let us see how to leverage this power of XBRL to capture the values correctly.

Analyzing the income statement, us-gaap_CostOfServices seems to be the most appropriate tag to capture the values highlighted in the HTML extract. (As an aside, I also noticed that the company had tagged this value to us-gaap_CostOfGoodsSold, which does not seem to be appropriate).

The US GAAP documentation label (in XBRL, the documentation label is what defines the concept for each tag) for this tag us-gaap_CostOfServices reads as follows ‘Total costs related to services rendered by an entity during the reporting period.’ As the values that we want to capture are costs, these values should be captured positively. To give an absurd example – had we wanted to capture ‘revenues’ using the tag us-gaap_CostOfServices, only then it would have made sense to flip the signs of these values. However, this is a very unrealistic scenario, as revenue numbers will never be captured using a cost tag. Or so I hope!

Now if this cost number is captured as a positive value, if, for purposes of presenting the XBRL document, the company wants to match the presentation as given in the HTML report (i.e. it wants viewers of the XBRL document to see the costs with a negative sign), it can use the negated label as a preferred label for the above element in the presentation linkbase. If this is done, the value will be displayed with an inverted sign (positive value will be displayed as negative and vice versa). But this will be only for display or presentation purposes. For calculation purposes, the value will be taken as positive.

The implication of not capturing the Cost of Services with correct signage
The problem with incorrect signage is seen when someone uses the XBRL data to draw inferences. If, in the above example, a user of the XBRL data wants to compute Gross Profit from the reported data, here is what the results will be:

Here are Revenues (Services Revenues) and Cost (Cost of Services) numbers (as given in the above screenshot)

	3 months ended		9 months ended
	2013	2012	2013	2012
Service Revenues	$357,196	$486,833	$1,402,957	$781,591
Cost of Service Revenues	$80,067	$217,186	$529,524	$369,339

Gross Profit will be the difference between Services Revenues and Cost of Services and the following will be the correct gross profit numbers:

	3 months ended		9 months ended
	2013	2012	2013	2012
Gross Profit	$277,129	$269,647	$873,433	$412,252

But because ‘Cost of Services’ is reported as a negative number, the gross profit that will be computed from XBRL data will be the following:

	3 months ended		9 months ended
	2013	2012	2013	2012
Gross Profit (computed from XBRL data)	$437,263	$704,019	$1,932,481	$1,150,930

Here, one can see the impact of capturing values with wrong signage. As part of its initiative to leverage the XBRL data in its analytics application, IRIS ran an automated check that it had built based on several enhanced business rules on about 7000+ XBRL documents. About 36% of the XBRL documents fail this signage check! While an analysis of a sample set of these XBRL documents reveals some genuine cases where the preparers needed to enter negative values in XBRL, a bulk of cases of such negative values are caused due to incorrect signage being assigned to the values in the XBRL document.