In my previous article, I demonstrated a simple technique for getting the correct sign when tagging a number in XBRL. You may have noticed that I was somewhat casual with the notion of concepts having a “name”. If you’re familiar with the details of XBRL, you’ll know that concepts have an “element name” and typically have at least one label. Which of these was I referring to?
It is common practice in XBRL to use the standard label to give a concept a human readable name. The purpose of a name is to unambiguously identify the meaning of a concept, and part of that meaning is the sign convention. Making a profit and making a loss are two very different things, and if the name of the concept doesn’t make it clear which of these things the concept represents, then it’s not a very good name.
Examples of good names would include:
- Increase in Accounts Receivable
- Increase/(Decrease) in Accounts Receivable
Examples of bad names would include:
- Profit or Loss
- Change in Accounts Receivable
(the last one is border line – you might reasonably assume that a positive “change” is an increase, but it’s not explicit, and it’s not the sign convention that you’d expect to see used when displaying the concept on a Cash Flow statement)
A more unconventional name like “(Increase)/Decrease in Accounts Receivable” would also be acceptable but note that this is a different concept to one called “Increase/(Decrease) in Accounts Receivable”.
If the idea that a concept should have a name, and that that name should make it clear what the concept means is sounding a bit obvious, then good – it is obvious!
The problem with element names
A concept also needs to have an element name. This serves a different purpose, which is to provide a unique identifier for the concept in an XML document. Human readability is not the primary concern, although most implementations have chosen to use meaningful names (e.g. ProfitBeforeTax), rather than arbitrarily generated identifiers (e.g. “c1234”).
XML imposes some constraints on what constitutes a legal element name, most importantly disallowing spaces and most punctuation. This means that we can’t simply use the standard label as an element name. Most implementations have adopted an approach of taking the standard label, stripping out punctuation and removing some connective words such as “and”. This approach is encouraged by FRTA, although an exact rule is not spelt out.
The approach has the unfortunate side effect of turning clear concept names (i.e. standard labels) into rather more ambiguous element names. For example:
|Increase/(Decrease) in Accounts Receivable
Such names undermine the notion that XBRL concepts have a clear and unalterable meaning, and that that meaning includes the sign convention. I suspect that elements such as the above have caused at least some of the confusion about how signs work in XBRL.
There is a very simple approach that would remove this confusion, but it’s not one that has made it into any published best practice that I am aware of, and that is to drop portions of the label that indicate the negated meaning when forming an element name. For example:
|Increase/(Decrease) in Accounts Receivable
If you’re uneasy about this approach, remember that the element is just a unique identifier. It is not intended to be a descriptive label, so the fact that it does not spell out the meaning of a negative value is unimportant.
Extensions and the SEC
In my view, the confusion around signs in XBRL has been fuelled by a number of details of the implementation of XBRL at the SEC. In the SEC implementation, preparers submit not only an instance document, but also an extension taxonomy allowing preparers to customise the taxonomy to better match their financial statements.
The SEC rule (33-9002) that enabled the use of XBRL for SEC Filings, requires filers to change the labels of standard concepts in the US GAAP taxonomy to match those on the company’s financial statements. You can argue about whether that’s a good idea or not, but doing so opens the door to confusion around sign conventions.
The text of the rule gives the example of a company relabeling “Gross Profit” as “Gross Margin” as they are “definitionally the same”. Seems harmless enough, but what about if the line item in your financial statements is “(Increase)/Decrease in Accounts Receivable”? Should you change the standard label of the US-GAAP concept from “Increase/(Decrease) in Accounts Receivable” to “(Increase)/Decrease in Accounts Receivable”? In my view doing so is absolutely unacceptable: an increase in accounts receivable is not the same as a decrease in accounts receivable, so changing the name of a concept in this way is very misleading.
The SEC system does provide an appropriate way to handle this situation (negating labels) but the guidance in the Edgar Filing Manual could be clearer. Rule 6.11.1 instructs filers to “Assign a label of an element used in an instance the same text as the corresponding line item in the original HTML/ASCII document” but nowhere in this rule does it suggest that assigning a standard label that implies the opposite sign convention is unacceptable. 6.11.6 explains how to use negating labels, but does not explain what you should do with the standard label.
Proposed new best practice
I believe that much of the confusion around XBRL sign conventions could be removed by clearly documenting two pieces of best practice:
- The element name must reflect the meaning of a positive value reported against the concept. If the element name is being formed from the standard label, parenthetical indications of negative meanings should be removed. In other words, a concept called “Profit/(Loss)” should result in an element name of “Profit” not “ProfitLoss”.
- When using an extension taxonomy to re-label concepts, it is never acceptable for a standard label to change the meaning of a concept, and meaning includes sign. For example, “Increase/(Decrease) in Accounts Receivable” must not be re-labelled as “(Increase)/Decrease in Accounts Receivable”. The correct place for such a label is as a negated label.