It’s important to note that inFlow’s movement history is only as accurate as the data entered. For example, if one of your users missed inputting a sales order into inFlow but still removed the items, you would see a difference between the numbers in inFlow and the physical count.

Here’s an example situation:

A physical count at the Main Warehouse location for item 04275 yields 540 total. But, inFlow is showing 560. It’s easy to change the number from 560 to 540 in inFlow, but why is the number different in the first place? This requires a lot of in-depth checking for each movement.

How do I find out what’s different?

To start, go to the product’s Movement History tab. If you use more than one Location, be sure to filter that so it’s easier to focus on just the location showing the incorrect quantity.

We know that the excess stock is exactly 20. What we do not know is if that is the total of several actions that were not recorded, or one. For example, this could be the result of one large sale that went unrecorded, several smaller sales, or even a stock adjustment. Here are a few things to check:

If the physical quantity is less than the quantity in inFlow

• Stock adjustment (decrease) was not recorded in inFlow
• Purchase order return + unstock was not recorded in inFlow
• Some sales orders were not recorded in inFlow.

If the physical quantity is more than the quantity in inFlow

• Sales order return + restock was not recorded in inFlow
• Some purchase orders were not recorded in inFlow.

If you have a paper trail for every sales order and purchase order matching the orders in inFlow, then you can rule out any missing orders. This is also true for restocking and unstocking since this involves some communication between you and your customer/vendor.

The more difficult transaction to check is the stock adjustment.  Without any paper trail for this, it comes down to questioning your users to figure out what could have happened. Stock adjustments could mean:

• the item was damaged in your location and had to be discarded
• the item was allowed to be removed from the location but not sold (e.g., free gifts to users)
• theft (unfortunate, but should not be ruled out)

You’ll notice in the bullet points above that “stock adjustment (increase)” isn’t listed. When an item comes in, it’s entering your locations from somewhere. For example, if your customer returned the item to you, you bought the item, or it’s coming from another location. All these methods have a proper procedure in inFlow (sales restock, purchase order, or stock transfer). You should record these accordingly instead of as a stock adjustment increase.

Okay, now how do I fix the numbers?

That depends on whether you were able to find out the cause of the difference.

If you’ve found the cause…

Great! You could slot that change back into the movement history historically.

For example, if the difference was because of a missing sales/purchase order, create the order and backdate it. This will slot the movement into its proper place in the movement history.

If it was an unrecorded sales restock or purchase unstock, go to the order in question and input that information.

If it’s an unrecorded stock adjustment due to waste/damaged goods, unfortunately, we don’t allow backdating stock adjustments. We would recommend creating a customer to track waste/damaged goods and reducing the stock from there.

After backdating, the numbers in movement history look even weirder!

Keep in mind that backdating anything will change the numbers of the “quantity before” and “quantity after” sections.

inFlow always tracks your inventory movement by “differences” instead of “quantities before and after.”

For example, if you have 580 in stock and you enter a sales order for 20, inFlow doesn’t set your new quantity to 560. It looks at the previous quantity (580) and then removes 20 from that number (bringing it to 560).

The simple table above shows a chronological sequence of two sales orders. Notice how the qty after on the first line matches the qty before on the second line. Let’s say we backdate a sales order for 5 units, and it was actually sold before Sales Order 2. This would be your new movement history screen:

Your movement history numbers are different now! This is expected as you’re backdating stuff and so the history would be different.

While this information seems conflicting, it’s important to note that it’s still correct. If we didn’t backdate that order and just slotted it in as the latest order, the final count is still 545.

See another example below for backdating using a sales order. Assume that the 20 units were actually sold on 4/20/2016 but were not entered into the system. Below, we have backdated an order on 4/20/2016 (SO-000013).

If you didn’t find the cause…

This is understandable as you may not have the time or resources to do so. Make the adjustment now and put some notes in the remarks section. If you do find the proper cause, later on, you can backdate the actual cause following the steps above, then cancel this stock adjustment.

You could also do a count sheet. It’s important to lock down all movement while you do this. After you finish a count, check with all your users responsible for inputting data into inFlow.  Verify that they are inputting procedures correctly (adjustments, returns, etc). If they’re all on the same page, you should start to see fewer discrepancies going forward.

I don’t use the sales or purchasing module, only stock adjustment.

Some users may not want to use the sales/purchase/transfer modules in inFlow and just rely on the stock adjustment module to save time. Unfortunately, we do not allow backdating stock adjustments so this will be quite difficult to correct. Keep in mind that reading the movement history for each stock adjustment can be quite confusing if you only keep records of “quantity before” and “quantity after.”

Focus instead on the quantity in/out (i.e., differences), and you should be able to match each transaction with inFlow.