In my previous post, I looked at how a lack of clear best practice around the naming of concepts and elements has contributed to the confusion around sign conventions in XBRL. I believe that another contributing factor is that the sign conventions used in financial statements are not trivial, and actually quite subtle.
Let’s take another look at the example from my first post:
|Cost of sales||(321)||(299)|
You might also encounter a different presentation of exactly the same data:
|Cost of sales||321||299|
Different jurisdictions seem to converge on one approach or the other, but the point is that either approach is valid. The same is not true in XBRL. When it comes to signs in XBRL, there’s a right way to do it, and a wrong way to do it.
In the above examples, we changed the sign of certain numbers on the statement, but we did not change the meaning. If you change the sign of a number reported in XBRL you will always change the meaning.
When humans read financial statements, they use domain knowledge and context to correctly understand the figures. I know that companies do not usually report a negative cost of sales (domain knowledge), and a quick check of the figures above and below (context) confirms that in neither case are the suppliers paying the company!
XBRL facts are designed to be understood independently, without the need for context or domain knowledge.
To illustrate the issue, imagine the accounts above had an additional line item:
In one year the company paid tax, and in the other it received a tax credit, but which was which? In the context of the first table, I’d expect this to represent a tax credit of 100 and a tax charge of 50, but in the context of the second table, I’d assume the opposite meaning. Without the context, it’s completely ambiguous.
By contrast, the sign to be used in XBRL is completely prescribed. Ask the question, “What was the taxation?” If you answer “100”, then tag a positive number. If you answer “actually, there was a tax credit of 100” then tag a negative number.
In the last two posts we’ve seen that tagging a value with the correct sign in XBRL is easy, provided that:
- You can correctly understand the figure that you are looking at, and you may have to use context and domain knowledge to do this (even if you don’t realise that that is what you are doing); and
- The meaning of the concept (which includes its sign convention) is accurately captured in its name.
If you’ve been following XBRL for a while, you might be surprised that I’ve got this far with no mention of balance attributes. We can’t avoid them forever, so in my next post I’ll be looking at whether they have anything to add, or if they merely contribute to the confusion.