Third quarter 10-Q filings were down 9% from last year and 3% from Q2. Can't quite say things are getting worse more slowly but it looks like some deceleration. Blank Check firms made up about 9% of the companies that failed to file followed by Business Services NEC, Pharmaceutical Preparations and Services-Prepacked Software.

Just looking through some of the 8-K trends. As the chart below shows it looks like activity may still be declining a bit.

But one particular Item jumped out for increased activity. I need to check through the history books to see when Item 4.01 was implemented (if anyone knows please LMK). I have data going back to mid-2005. August 2009 was a record month for companies to announce a change in their certifying accountant. 

We're not talking a lot of filings, just 340. But you have to go back to March of '06 for the next highest total of 287.

Here's the total filings graph.

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.

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.

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