SEC Data Guy

XBRL Calculation "Inconsistencies"

btw, many reports will flag calculation issues in XBRL data as inconsistencies. The reason is that not all calculation problems are actual errors. Some are unavoidable. But if you see more than a couple inconsistencies in a single filing it should raise questions in your mind. In these early days I'd question just about any inconsistency because the vast majority of them can be avoided. For the issuer, building a good calculation linkbase and watching the errors or inconsistencies can help them avoid all kinds of problems like bad signage (below), transpositions and unintentional rounding errors.

XBRL Calculation Error

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.

One XBRL Error Report

Here's a report from XBRL Cloud that shows errors, warnings and inconsistencies (expect some inconsistencies but not many per filing). Not sure what they're basing this on so it's offered more in the way of showing how transparent the data is.

http://xbrlcloud.com/edgar/edgar-index.html

To Err: Mandatory XBRL Technical Errors

Neal Hannon over at Gilbane Group has a post title that pronounces "VFP XBRL Errors Will Not Carry Over to Mandatory Program". He does temper things slightly by the end of the post saying "No, I'm not expecting the startup to be perfect."

What we know is that the startup is already not perfect. The mandate has begun. Even though most companies that have to file this year won't do so until August the corporate filings going in today must follow the mandate rules. The EDGAR Filer Manual that Neal mentions, the one with all the XBRL rules, is in effect today also. And there are plenty of technical errors in currently submitted data (I won't go into the accounting side of things). Some filings are better than others and the errors are of varying importance but the data is definitely not perfect.

The problem for XBRL advocates is that "transparency" cuts a number of ways. Is XBRL better than the current publicly available data scraped from HTML filings? Sure. But it's hard to research the current problems. XBRL is easy. I can check XBRL data for technical errors in about a minute (download the data, zip it, upload it to a publicly available validation tool, see results).

It's the UPS thing. I used to get packages in 4-6 weeks and didn't think a thing about it. But with 3 day delivery promises and the ability to see where my package is at any given time, the expectations have changed.

Because it's easy XBRL data will be scrutinized. There are sure to be other reports like the one everyone is talking about now. And companies hate to be embarrassed. I think the researcher's point that issuers should take data quality seriously, and be encouraged to do so, is valid. The quality conversation is long overdue.

I'll post some numbers in the near future.

XBRL: Reducing or Introducing Errors?

A new research paper is out from North Carolina State University about the accuracy, or not, of XBRL filings submitted as part of the SEC's voluntary program. The authors raise a number of issues of various importance and I hope to dive into a couple in the future.

The data in the study was submitted back on '07 but it's very true that a wild west atmosphere was the hallmark of the voluntary program. It was in virtually no one's interest to talk about data quality issues outside of gearhead bull sessions at the bar after a conference. Cox certainly didn't care.

One of their key points is spot on:

In the absence of solutions, financial statement users may quickly lose confidence in the XBRL data as it becomes widely available. There is a real risk that the SEC's program for mandatory XBRL filings could fail to gain acceptance, and if that happens, it will be difficult to regain preparer and user confidence in the XBRL process for many years.

If anyone doesn't think this is a real possibility just think back to another acronym, FDS (Financial Data Schedule). If you don't know what the FDS was, well, there you go.