December 9, 2020by Team IRIS CARBON

In the last article, we set the context for quality in your ESEF filing process starting with what the mandate requires you to file with your regulator – the instance document and company taxonomy. We then elaborated upon one aspect of the instance document creation, which ties up to its quality – tagging.

This article will be about a pitfall that filers should avoid in their instance document creation.

The pitfall of reversing signs

In XBRL filings in the US, it has often been noticed that calculation errors form the highest number of errors in filings. And most calculation errors stem from companies reporting a negative value for a concept that is expected to have a positive value in XBRL, and vice versa.

Many of these calculation issues can be avoided by considering one key attribute of any monetary element — its Balance Type, which denotes whether a monetary concept is a debit or a credit — and not go only by its representation in the annual report.

These balance types play an important role when an element is used as part of any XBRL calculation. Take for instance three simple monetary concepts – revenues, cost of goods sold, and gross profit. And take a simple calculation: Revenue – Cost of Goods Sold = Profit.

Now the balance type of revenues and profit is defined in the taxonomy as credit and the cost of goods sold as debit. By establishing a calculation relationship between revenues, cost of goods sold, and profit, the value for the cost of goods sold would automatically be reduced from revenues to calculate the value of gross profit.

If a company tags the cost of goods sold as a negative number in XBRL (since it may have shown its value as negative on the face of its document), the negative value that the calculation relationship already places on the element combines with the negative value tagged to render it positive in any calculation relationship. Cost of goods sold ends up becoming a positive fact and getting added to revenues, rather than getting deducted from revenues.

Therefore, in XBRL, it is important to tag the cost of goods sold as a positive value, even if it is shown as a negative value on the human-readable face of the annual report. Its balance type and placement in calculations will take care to let viewers know it is a debit item that will be reduced from revenues.

While this is a simple example, many people fall into the trap of tagging an item as negative simply because the face of the annual report shows it in brackets, or as negative, for ease of representation to users. In XBRL, it would help you to watch for the balance type of the item and decide whether you need to reverse the sign in your XBRL tagging or not. This will help you steer clear of one of the most common mistakes that companies make while applying the XBRL layer to their report.

You would do well to study the balance types of tags that you select from the ESEF taxonomy, and to understand how elements participate in calculation relationships. XBRL validations should catch errors in signs (if wrongly applied in the XBRL layer), so apart from reviewing the tags and calculations, make sure any software you use has an XII certified validator included as well.

In our next article, we will talk about creating extension elements judiciously and anchoring them in line with ESEF requirements.

For a Free Demo of the IRIS CARBON® Solution.