TonyP has posted a great comment you can read below the post on the XBRL error report from XBRLCloud.com. After doing a pretty complete analysis on one error in a filing he has a couple questions which I'll try to address here. Hang with me because it's a good issue and helps to flesh out why data quality has a brand new meaning now. The big thing to keep in mind is that XBRL is data meant for machine consumption and the rules are different.
Here's the basic issue. The company reported Property, Plant & Equipment (PP&E) less Accumulated Depreciation (AD) = Property, Plant & Equipment, Net (PP&E Net). Pretty basic. The viewable XBRL (check the balance sheet section) looks fine, just like the HTML version. But XBRLCloud is reporting a calculation error. These numbers don't add up and TonyP notices the "weight" attribute is causing AD to be added to PP&E rather than subtracted and he wonders how it got there.
The easy answer is the issuer put it there. But there is a problem here and there's more to it.
The XBRL data being submitted to the SEC comes with a calculation linkbase. This file is the issuer's own description of how items in their financials should be added together. In this case it says
PP&E Net = PP&E - AD
[wonk alert, like this wasn't wonky enough to begin with: What the computer is actually instructed to do is take the value of AD, multiply it by the weight and add it.]
Because AD is reported in the data as a negative number any calculation check will throw an error since subtracting a negative will add the AD to PP&E. So the error is correct. What should the issuer have done?
They can't change the weight. The weight attribute value is pretty much locked down and is determined by the balance type of the parent and child in a calculation relationship. Assuming the parent and child elements are either debit or credit items, if the child's balance type is the same as the parent's then then weight is "1". If the child's balance type is different from the parent's then the weight is "-1". This is written into the spec and is just the way it is. So it is written, so will it be done. [You can find the weight value in the calculation linkbase.]
PP&E Net, the parent, is a debit. PP&E, a child, is a debit. AD, the other child, is a credit. The weight on PP&E should be and is "1" and the weight on AD should be and is "-1".
So the problem here is that the accumulated depreciation number is incorrect. Specifically the sign is wrong. If you look in the instance document you'll see it is -1959882000. That should be a positive 1959882000. The issuer misreported AD by -3,919,764,000. I'd say that's material. If you tried to graph this issuer's AD against other companies, say in their industry, it would look really, really weird. What would a bot do with it? Anyone's guess.
What is the issuer to do? Switch the sign on AD. Then if they would like the human-readable version to be similar to the HTML there is a way to instruct XBRL viewers to do that (which I think ends up in the presentation linkbase). But the main thing is get the data right.
Recent Comments