The long title of this article should be something like “Itemhistupdateengine.cpp – CHECKPOINT: Error: Verify Item History: Target - - - mismatch errors.” Obviously, I couldn’t list that as the actual title to this article, it might scare everyone off.
There are a variety of these errors showing up in QuickBooks Desktop when users run the Verify Utility and review the QBWin.log file. Here are just a couple of the specific ‘mismatches’ you might see:
Mismatch Errors
As you can see in the first example, the mismatch deals with ‘quantities on sales orders’, and in the second example the mismatch deals with the ‘average cost’ of an item. So what causes errors like this and how can we prevent or resolve them? By the way, both of these involve ‘Inventory’ items, but ‘Inventory Assembly’ items can also be the subject of such mismatches.
In order to understand how mismatch errors occur we must look at how QuickBooks tracks inventory related information. First, and most importantly, QuickBooks tracks the history of inventory items by recording the quantity, purchase cost, average cost, and sale price each time a transaction impacts that ‘history’. But QuickBooks also captures 'snapshots' of inventory information related to the items appearing on transactions at the time the transaction is saved.
If my count on hand at 8/5/2016 00:00:01 was zero for widgets, then the historical quantity at that ‘snapshot’ was 0 [zero]. If I receive 10 widgets 10 hours later, then the historical quantity at that snapshot is 10 [ten] on 8/5/2016 10:00:01, assuming nothing else has intervened between the two snapshots. By the way, the quantity value of 10 which was captured by the 10:00:01 snapshot was also recorded as the Quantity on Hand for widgets within the Item Receipt record. At that moment in time, the record associated with the ‘target’ (the Item Receipt quantity on hand) value matches the Item History snapshot.
At this point I want to interject that we have ‘no outstanding’ transactions impacting widgets in QuickBooks, everything is recorded. Now let’s assume that we create a Sales Order for 5 widgets just 20 minutes after we receive our 10 widgets. While Sales Orders are ‘non-posting’ transactions that do not directly impact inventory, they do ‘record’ inventory history in two ways, first they record the value of the quantity of an item ‘on sales orders’ at the time of the transaction, and they also record the ‘quantity available’ based upon the present snapshot of inventory at the time the sales order is posted. So on 8/5/2016 10:20:01 our Sales Order records the Quantity on Hand as 10 widgets, and the Quantity on Sales Orders as 5 widgets.
Let’s look at one example of a workflow that many QuickBooks users commonly follow. When our stock foreman takes a copy of the Sales Order to the warehouse to fulfill the order, he notices that there are not 10 widgets on the shelf, but there are actually 20 widgets on the shelf. He picks out 10 widgets and takes them back to his desk to not only prepare them for shipping, and process the invoice, but to also remind himself that he needs to research why the count is wrong on the shelf.
Thirty minutes after the Sales Order was written, our stock foreman is invoicing the sales order for the 10 widgets so that the customer can pick them up later today. The time is now 10:50:01, and the quantities have changed again with the creation of the invoice. The Quantity on Hand is now 5 because we have sold 5 from the previous history snapshot of 10 recorded on the Sales Order, that matched the Item history at the time of the Sales Order. In addition, the quantity on sales orders has returned to zero. Behind the scenes, the Invoice has recorded the same value for the quantity on hand as in the Item history, the target value and the Item history match.
But after our Invoice was created, the stock foreman started down through his stack of paperwork and he finds that he has forgotten to enter an item receipt for 10 widgets that were received on at 09:10:30 on 7/31/2016, some 6 days earlier. He goes ahead and posts the receipt of these 10 widgets with a date of 7/31/2016, as of that date, the actual Item history has been changed. In reality there were 10 widgets on hand prior to the receipt of 10 more widgets on 8/5/2016, and prior to the Sales Order of 8/5/2016, and prior to the Invoice of 8/5/2016. But now the actual Item History no longer matches the captured ‘snapshots’ of Quantity on Hand at the time of those transactions, and the target records that were supposed to match history are now ‘mismatched.’
Unfortunately, QuickBooks will not automatically go back and re-record a new snapshot for each transaction that is impacted by the historical re-statement of item quantities, nor average cost, nor sales price. In order for those transactions to be updated, either one of two things must occur. You must either (1) open the transaction, and work your way through any impacted ‘item’ lines (target records) so that the transaction is updated from the correct item history, or you (2) must run the Rebuild utility that will ‘fix’ the transactional ‘snapshots’ of item history within the target records.
While the ‘values’ are different for each type of mismatch, the causative mechanism is essentially the same. The impact of errors like this involving quantity, average cost and sale price can have substantial effect upon inventory centric businesses, and may also present themselves in other forms of corruption such as the actual item history computations producing out-of-balance list values.
Of course we not only see the same 'mismatches' if item receipts are re-dated when the Vendor Bill is entered. In those cases we may not only change the quantity on hand/available in the item history, thus creating mismatches from the captured snapshots within intervening items, but we can actually skew the inventory quantity into a negative state. Insightful Accountant has previously published several articles covering the various irregularities and problems associated with negative inventory, so we won't rehash that subject here.
My own practice continues to see more and more of these problems, and we are sent anywhere from 30 to 60 QBWin.log files each week for analylsis that contain such errors. As I mentioned a moment ago, in most cases, the Rebuild Utility will successfully ‘fix’ these errors, assuming it is safe to run the Rebuild in the absence of any errors involving sensitive data or encryption/decryption functions.