XBRL Data, Quality XBRL Data, SEC Reporting, Calculation Errors, Data Issues, Quality XBRL FilingOf late, there have been a number of 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 balance type of the element is inconsistent with the reported concept. It is important to understand the implications, if this rule is not followed.

An example that I came across while analyzing XBRL documents was the manner in which Cost of Services was captured in the Income Statement displayed below. 

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 in negative (please refer the below given screenshot). Evidently, 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 has the ability to 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 definitely be captured in positive. 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 inverted sign (positive value will be displayed as negative and vice versa). But this will be only for the display or presentation purposes. For calculation purposes the value will be taken as positive. 

Implication of not capturing 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 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 actually 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 clearly 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.