Cycle Counting in D365 Advanced WMS: Thresholds, Count Plans, and Mobile Count Work
I closed the cost to complete article with a promise to come back to the warehouse: cycle counting in D365 Advanced Warehouse Management. Inventory accuracy is one of those metrics nobody talks about until it is bad, and by then every downstream process is paying for it: master planning ordering material you already have, waves releasing picks against stock that is not in the location, and month-end variances nobody can explain. A well-built cycle counting program is the cheapest insurance the module offers, and Dynamics gives you everything you need; the catch is that the pieces are scattered across half a dozen forms and only behave well together if you set them up as one system.
WHY CYCLE COUNTING INSTEAD OF THE ANNUAL COUNT
The traditional wall-to-wall count has three problems: it stops the operation, it is staffed by tired people counting unfamiliar stock at speed, and the accuracy it buys starts decaying the morning after. Cycle counting inverts the model: count a small slice of the warehouse continuously, with the people who work in it, while it runs. Errors get caught weeks after they happen instead of months, which means the root cause is still findable. And in most jurisdictions auditors will accept a robust cycle count program in place of the full physical count, provided you can demonstrate coverage: every item and location counted at a defined frequency, with documented variance handling. That word, demonstrate, drives a lot of the setup decisions below.
THREE WAYS COUNT WORK IS BORN
Everything in this process produces the same object: warehouse work of type cycle counting, queued and routed like any other work, which is why the work template and work pool plumbing I covered earlier matters here too. The differences are in the trigger.
1. Cycle count plans. The scheduled backbone. A plan holds selection criteria for locations and items, a maximum number of counts to generate per run, and the number of days that must pass before a location or item is counted again. A batch job executes the plan on its schedule and creates the work. This is the instrument that gives you provable coverage.
2. Cycle count thresholds. The opportunistic counter. A threshold watches on-hand in a location, by quantity or by percentage, and when a pick drops the location below the limit, the system creates count work for it automatically. The logic is simple economics: the best moment to count a location is when it is nearly empty, because the count takes seconds and is hard to get wrong.
3. Spot counting. The judgement call. A supervisor who distrusts a location creates count work for it directly, or a worker initiates a spot count from the mobile device. No schedule, no trigger, just suspicion, and a healthy program leaves room for it.
BUILDING PLANS THAT COVER THE WAREHOUSE
The classic structure is frequency by velocity. Fast-moving A items are touched constantly, so they accumulate errors fastest and earn the tightest cadence; slow C items barely move and a long cycle is fine. In practice I build separate plans per class (the item selection criteria can key on an ABC classification or an item group) with days-between-counts set accordingly, and I cap each plan execution at a number of counts the crew can actually clear in a day. An unworked count queue is worse than no queue: by the time someone gets to the work, the location has changed and the count is noise. Two more habits worth copying: include empty locations deliberately (an empty location that should have stock is exactly the error you want to find), and give count work its own work pool so it never competes with picking in the same queue, which is a contest counting always loses.
EXECUTING ON THE MOBILE DEVICE
Count work is executed through a mobile device menu item configured for cycle counting, either system-directed (the device feeds the worker count work from the queue) or user-directed. The single most important configuration decision here is blind counting: the device should ask what is in the location and never show the expected quantity. The moment workers can see the system number, a percentage of them will confirm it, and your accuracy KPI becomes a measurement of agreeableness. The device walks the worker through the location: items, quantities, license plates, and batch or serial numbers where the item is tracked. Counting tracked items takes longer, which is worth remembering when you size the daily count budget.
WHAT HAPPENS TO A DISCREPANCY
On the warehouse worker record you set the tolerance that decides what happens next: a maximum difference, as a percentage or an absolute quantity, that the worker is allowed to post unsupervised. A count inside the tolerance completes silently; the system posts the adjustment, the work closes, and on-hand is corrected on the spot. A count outside it lands on the cycle count pending review list, where a supervisor can accept the count (posting the adjustment), reject it, or send the location back for a recount. My standing rule: any large variance gets a second blind count by a different worker before anyone accepts it, because the most common cause of a shocking count result is a counting error, not an inventory error. Accepted differences post as counting adjustments against the offset account configured for the adjustment type, so finance sees a clean, auditable trail of every correction with a user, a timestamp, and a location attached.
MEASURING THE PROGRAM
Measure location-level hit rate: the share of counted locations that matched within tolerance. Resist the temptation to report net value variance instead; offsetting errors hide inside it, and a warehouse that is plus 50 pieces in one aisle and minus 50 in the next is not accurate, it is lucky. Slice the hit rate by zone, by item group, and by process, and treat the counts as a sensor rather than a correction mechanism. If one zone keeps missing, the problem is usually upstream: a putaway directive dropping stock in the neighbouring location, a unit of measure confusion at receiving, a pick face where workers grab from the wrong license plate. The adjustment fixes the number; the analysis fixes the warehouse.
WHAT GOES WRONG
• Count work nobody executes. Plans generate faithfully, the queue grows stale, and every count executed against a weeks-old snapshot is misleading. Size the plans to the labor you have.
• Expected quantities visible on the device. The accuracy KPI goes to 99 percent and means nothing. Blind counting is non-negotiable.
• Tolerances at the extremes. Zero tolerance drowns the supervisor in trivial approvals until approving becomes a reflex; a huge tolerance lets real errors post silently. Start tight, then widen by item value.
• Thresholds on high-velocity pick faces. A location that crosses its threshold five times a day creates five counts a day. Thresholds belong on locations where crossing the line is an event, not a rhythm.
• Counting journals run in parallel. The classic counting journal from basic inventory does not respect warehouse work, and using it on WMS-enabled locations while count work is open for the same stock is a reliable way to manufacture discrepancies. In an Advanced WMS warehouse, count through work.
TAKEAWAYS
Cycle counting in Advanced Warehouse Management is three triggers feeding one work type, a blind count on a device, and a tolerance gate deciding what posts and what gets reviewed. Build plans that give provable coverage at a cadence matched to item velocity, let thresholds catch the cheap counts on nearly empty locations, keep the counts blind, recount before accepting big variances, and read the results as diagnostics for the processes that caused the errors. Do that steadily, every week including the busy ones, and inventory accuracy stops being a year-end confession and becomes a number you can defend any day of the month.
Next time I will look at replenishment in D365 Advanced Warehouse Management: minimum and maximum replenishment, demand-based and load demand strategies, and how to keep pick faces stocked without burying the warehouse in unnecessary moves.
In this series: previous article Fixed-Price Estimates and Revenue Recognition in D365: Cost to Complete for ETO Projects
I closed the cost to complete article with a promise to come back to the warehouse: cycle counting in D365 Advanced Warehouse Management. Inventory accuracy is one of those metrics nobody talks about until it is bad, and by then every downstream process is paying for it: master planning ordering material you already have, waves releasing picks against stock that is not in the location, and month-end variances nobody can explain. A well-built cycle counting program is the cheapest insurance the module offers, and Dynamics gives you everything you need; the catch is that the pieces are scattered across half a dozen forms and only behave well together if you set them up as one system.
WHY CYCLE COUNTING INSTEAD OF THE ANNUAL COUNT
The traditional wall-to-wall count has three problems: it stops the operation, it is staffed by tired people counting unfamiliar stock at speed, and the accuracy it buys starts decaying the morning after. Cycle counting inverts the model: count a small slice of the warehouse continuously, with the people who work in it, while it runs. Errors get caught weeks after they happen instead of months, which means the root cause is still findable. And in most jurisdictions auditors will accept a robust cycle count program in place of the full physical count, provided you can demonstrate coverage: every item and location counted at a defined frequency, with documented variance handling. That word, demonstrate, drives a lot of the setup decisions below.
THREE WAYS COUNT WORK IS BORN
Everything in this process produces the same object: warehouse work of type cycle counting, queued and routed like any other work, which is why the work template and work pool plumbing I covered earlier matters here too. The differences are in the trigger.
1. Cycle count plans. The scheduled backbone. A plan holds selection criteria for locations and items, a maximum number of counts to generate per run, and the number of days that must pass before a location or item is counted again. A batch job executes the plan on its schedule and creates the work. This is the instrument that gives you provable coverage.
2. Cycle count thresholds. The opportunistic counter. A threshold watches on-hand in a location, by quantity or by percentage, and when a pick drops the location below the limit, the system creates count work for it automatically. The logic is simple economics: the best moment to count a location is when it is nearly empty, because the count takes seconds and is hard to get wrong.
3. Spot counting. The judgement call. A supervisor who distrusts a location creates count work for it directly, or a worker initiates a spot count from the mobile device. No schedule, no trigger, just suspicion, and a healthy program leaves room for it.
BUILDING PLANS THAT COVER THE WAREHOUSE
The classic structure is frequency by velocity. Fast-moving A items are touched constantly, so they accumulate errors fastest and earn the tightest cadence; slow C items barely move and a long cycle is fine. In practice I build separate plans per class (the item selection criteria can key on an ABC classification or an item group) with days-between-counts set accordingly, and I cap each plan execution at a number of counts the crew can actually clear in a day. An unworked count queue is worse than no queue: by the time someone gets to the work, the location has changed and the count is noise. Two more habits worth copying: include empty locations deliberately (an empty location that should have stock is exactly the error you want to find), and give count work its own work pool so it never competes with picking in the same queue, which is a contest counting always loses.
EXECUTING ON THE MOBILE DEVICE
Count work is executed through a mobile device menu item configured for cycle counting, either system-directed (the device feeds the worker count work from the queue) or user-directed. The single most important configuration decision here is blind counting: the device should ask what is in the location and never show the expected quantity. The moment workers can see the system number, a percentage of them will confirm it, and your accuracy KPI becomes a measurement of agreeableness. The device walks the worker through the location: items, quantities, license plates, and batch or serial numbers where the item is tracked. Counting tracked items takes longer, which is worth remembering when you size the daily count budget.
WHAT HAPPENS TO A DISCREPANCY
On the warehouse worker record you set the tolerance that decides what happens next: a maximum difference, as a percentage or an absolute quantity, that the worker is allowed to post unsupervised. A count inside the tolerance completes silently; the system posts the adjustment, the work closes, and on-hand is corrected on the spot. A count outside it lands on the cycle count pending review list, where a supervisor can accept the count (posting the adjustment), reject it, or send the location back for a recount. My standing rule: any large variance gets a second blind count by a different worker before anyone accepts it, because the most common cause of a shocking count result is a counting error, not an inventory error. Accepted differences post as counting adjustments against the offset account configured for the adjustment type, so finance sees a clean, auditable trail of every correction with a user, a timestamp, and a location attached.
MEASURING THE PROGRAM
Measure location-level hit rate: the share of counted locations that matched within tolerance. Resist the temptation to report net value variance instead; offsetting errors hide inside it, and a warehouse that is plus 50 pieces in one aisle and minus 50 in the next is not accurate, it is lucky. Slice the hit rate by zone, by item group, and by process, and treat the counts as a sensor rather than a correction mechanism. If one zone keeps missing, the problem is usually upstream: a putaway directive dropping stock in the neighbouring location, a unit of measure confusion at receiving, a pick face where workers grab from the wrong license plate. The adjustment fixes the number; the analysis fixes the warehouse.
WHAT GOES WRONG
• Count work nobody executes. Plans generate faithfully, the queue grows stale, and every count executed against a weeks-old snapshot is misleading. Size the plans to the labor you have.
• Expected quantities visible on the device. The accuracy KPI goes to 99 percent and means nothing. Blind counting is non-negotiable.
• Tolerances at the extremes. Zero tolerance drowns the supervisor in trivial approvals until approving becomes a reflex; a huge tolerance lets real errors post silently. Start tight, then widen by item value.
• Thresholds on high-velocity pick faces. A location that crosses its threshold five times a day creates five counts a day. Thresholds belong on locations where crossing the line is an event, not a rhythm.
• Counting journals run in parallel. The classic counting journal from basic inventory does not respect warehouse work, and using it on WMS-enabled locations while count work is open for the same stock is a reliable way to manufacture discrepancies. In an Advanced WMS warehouse, count through work.
TAKEAWAYS
Cycle counting in Advanced Warehouse Management is three triggers feeding one work type, a blind count on a device, and a tolerance gate deciding what posts and what gets reviewed. Build plans that give provable coverage at a cadence matched to item velocity, let thresholds catch the cheap counts on nearly empty locations, keep the counts blind, recount before accepting big variances, and read the results as diagnostics for the processes that caused the errors. Do that steadily, every week including the busy ones, and inventory accuracy stops being a year-end confession and becomes a number you can defend any day of the month.
Next time I will look at replenishment in D365 Advanced Warehouse Management: minimum and maximum replenishment, demand-based and load demand strategies, and how to keep pick faces stocked without burying the warehouse in unnecessary moves.
In this series: previous article Fixed-Price Estimates and Revenue Recognition in D365: Cost to Complete for ETO Projects
No replies yet. Be the first to respond!
