Recurring cycle count variances in Manhattan WMS are rarely a counting problem — they're a signal that something upstream is creating discrepancies faster than counts can correct them. This guide walks the likely sources so you can fix the cause, not just re-adjust the numbers.
1. Separate real shrink from system-created variance
Before investigating configuration, establish whether stock is physically going missing (theft, damage, mis-ships) or whether the system is creating phantom discrepancies. If the physical count is right and the system is wrong, the cause is in the process or configuration — a very different investigation.
2. Check for unposted or failed transactions
Movements, adjustments, or confirmations that didn't post — or posted partially — leave the system out of step with reality. A pick confirmed on the floor but not in the system, or an adjustment that erred out, shows up later as a count variance. Look for stuck or failed transactions in the affected locations.
3. Review timing between physical work and the count
If a location is counted while work is still in flight — a pick in progress, a putaway not yet confirmed, a replenishment mid-move — the count captures an inconsistent moment. Confirm counts are scheduled against locations that are settled, or that in-flight work is accounted for.
4. Examine process gaps that create discrepancies
Certain process weaknesses generate variances repeatedly:
- Unrecorded movements: stock physically moved without a system transaction.
- Substitutions and short picks: handled on the floor but not reflected in the system.
- Receiving errors: quantity or item discrepancies at receipt that surface downstream as count variances.
The zone or process where variances concentrate is usually where the gap lives.
5. Check UOM and pack configuration
An item with an incorrect pack size or unit-of-measure conversion will count "wrong" every time even when the physical quantity is correct — the system simply expects a different number. Verify the item and pack setup for the SKUs showing persistent variance.
6. Confirm the count program itself is configured correctly
Finally, check the cycle count configuration — the counting method, tolerance thresholds, and how variances are approved and posted. A tolerance set too tight will flag noise as variance; an approval step that auto-posts can bake in errors. Make sure the program is measuring what you intend.
The faster way
Persistent variances are exactly the kind of root-cause hunt SupplyChain Assist is built for — describe where the variances cluster and it walks the likely upstream causes with the specific checks, so you fix what's creating them instead of re-counting forever.