In my previous posts, I’ve shown how easy it is to get signs right in XBRL, and looked at some of the reasons why the issue has ended up so confused. Until now, I’ve studiously avoided the topic of balance attributes.
The XBRL v2.1 specification has this to say on the topic of balance attributes:
“The balance attribute is important to applications that consume numbers related to accounting concepts such as asset, liability, equity, revenue and expense. The balance attribute (debit/credit) provides a definitive declaration of how values in XBRL instances are to be authored and interpreted when the debit/credit designation is provided.
Table 5. Correct signage in an XBRL instance
|Taxonomy element||Account balance||Sign of XBRL instance element value|
|balance=”credit”||Credit||Positive or zero|
|balance=”credit”||Debit||Negative or zero|
|balance=”debit”||Debit||Positive or zero|
|balance=”debit”||Credit||Negative or zero|
The numeric representation of a debit or credit item will normally (that is, more often than not) be positive in an XBRL instance.”
This excerpt probably raises more questions than it answers. Top of the list in my mind, is if the balance attribute is so important, how is it that I can tell you exactly how to tag a value without ever mentioning it? For quite some time after I first encountered XBRL I wondered if there was some subtlety to the accounting domain that makes the tried-and-tested approach of simply “giving things clear and meaningful names” inapplicable.
After working with XBRL for the best part of 10 years, I have reached the conclusion that there is not; the balance attribute is redundant.
Of course, redundancy isn’t always a bad thing. On the contrary, it can be useful: credit card numbers all have redundancy built into them in the form of checksum digits that allow the easy detection of errors in the number. Similarly, balance attributes can be a useful cross-check to make sure that numbers are tagged correctly, but I’d argue that they should not be the primary mechanism, and I’ve certainly seen significant confusion result from people trying to assign signs based only on balance attributes.
In my first post, I showed that in order to tag a value correctly, you needed to understand the meaning of the figure you’re looking at (is it a profit or a loss?) and the meaning of the concept that you’re going to use (does it represent profit or loss?) If the two match, tag a positive value, otherwise tag a negative value.
The table in the spec excerpt above shows the same logic being applied using balance attributes, but the inputs that you need to know are the “balance” of the figure you’re looking at, and the balance attribute of the concept that you’re planning to use.
It’s the exact same logic, but as a non-accountant determining the balance of a figure that I’m looking in a financial report is not something that comes naturally to me, and judging by the number of sign errors in filed SEC reports, I don’t think I’m alone. The game becomes more complicated once you start dealing with extensions, and the individual filer has to decide on the balance attribute of the extension concept.
The final problem with the balance attribute approach is that it falls down completely when you encounter a concept with no balance attribute. Louis Matherne at FASB recently stated [of the US-GAAP taxonomy] that “the FASB XBRL Team is making a concerted effort to eliminate elements without balance attributes”. This is a reasonable goal, but there’s a snag: it’s impossible, unless you’re prepared to sacrifice use of the calculation linkbase.
The XBRL v2.1 specification imposes constraints on the valid weights of calculation relationships based on the balance attributes of the concepts involved. The gist of it is, you can add debits to each other and subtract credits, or add credits to each other and subtract debits, but you can’t add debits to credits or subtract debits from debits. It’s much easier to understand with some examples:
|Dr + Dr = Dr||Dr – Dr = Dr|
|Cr + Cr = Cr||Cr – Cr = Cr|
|Dr – Cr = Dr||Dr + Cr = Dr|
|Cr – Dr = Cr||Cr + Dr = Cr|
Now this rule holds surprisingly well in real world financial statements, but if you can remember anything of what they taught you in algebra classes you should have a nagging concern. What happens if you subtract a Dr from both sides of the first valid example? Yep, you end up with the first invalid example. Likewise, subtract a Cr from the second example, or add a Cr to the third, or a Dr to the fourth.
The calculations that the spec tells us are “invalid” are simply rearrangements of calculations that are considered valid!
For the most part financial statements don’t “rearrange” calculations, so we get away with it, but there is a problem: the Cash Flow Statement.
The Cash Flow Statement is essentially a rearrangement of the Income Statement that arrives at a figure for the change in cash for the period (actually there’s a bit more to it than that as it involves some different line items, but the point stands).
In the Cash Flow Statement we take Net Income (a credit), we add back stuff like Depreciation (a debit), subtract stuff like Increases in Accounts Receivable (a credit) and arrive at the Increase in Cash for the period (a debit). In other words:
Cr + Dr – Cr = Dr
It breaks every rule in the book!
Taxonomies such as US-GAAP have a little workaround. Firstly, I over simplified the above slightly. The calculation above typically arrives at a figure for Net Cash Provided by Operating Activities, which in turn contributes to Increase in Cash for the Period. The trick is to not assign a balance attribute to the intermediate concept for Net Cash from Operating Activities, so you end up with two calculations:
Cr + Dr – Cr = [ no balance attribte ]
[ no balance attribute ] + … = Dr
There are no constraints on the calculation weights when one of the concepts involved has no balance attribute, and so the constraint imposed by the specification is bypased. Obviously this is unfortunate if you were relying on the balance attribute was going to help you get the sign of this value correct.
Of course, the sign convention for the concept with no balance attribute is made completely unambiguous by its name, “Net Cash Provided By Operating Activities”. If operating activities provided cash, tag a positive number. If operating activities actually used cash, you should tag a negative number.
Hopefully I’ve demonstrated that balance attributes are at best redundant, and thanks to the fall out from a rather odd constraint in the spec, they can actually contribute to the mystery and the confusion.