Cycle Counting the Smart Way: ABC, Count Books, and Mobile
🎯 Who this is for: Storeroom supervisors and inventory controllers responsible for inventory accuracy, plus the storekeepers who do the counting and the admins who configure the ABC classes, frequencies, and tolerances behind it.
Series: Part 4 of 10 — MAS 9 Supply-Chain Playbook | Read time: 26 minutes
🗓️ Why Wall-to-Wall Counting Is the Wrong Model
Once a year, the storeroom shuts down. For two or three days nobody issues, nobody receives, and a team walks every shelf counting every part while maintenance waits and downtime costs pile up. At the end you get a single accuracy number, a pile of adjustments, and eleven months of drift before you find out anything is wrong again.
That is the wall-to-wall model, and it is the wrong model. It optimizes for a once-a-year audit signature at the cost of continuous accuracy and continuous availability.
Cycle counting inverts it. Instead of counting everything once a year, you count your most important items often and your least important items rarely — A-class monthly, B-class quarterly, C-class annually — on a rolling schedule that never shuts the storeroom down. Variance is found in weeks, not a year. There is no storeroom outage. And your accuracy KPI is a live, month-over-month trend instead of an annual verdict.
<aside>
💡 Key insight: Cycle counting is not "counting less." It is counting proportionally — spending your counting effort where the money and the risk are. A handful of A-class items usually represent the majority of your inventory value, so counting them twelve times a year and the C-class junk once buys more accuracy per hour of counting than any wall-to-wall exercise ever did.
</aside>
MAS 9 automates the scheduling, so once the classification and frequencies are set, the system tells you what to count each week and you simply do it — increasingly, from a phone.
🔤 ABC Classification
Cycle counting rests on classifying every stocked item as A, B, or C by importance. The standard criterion is annual issue value — quantity issued over a year times unit cost.
The split
A typical Pareto distribution looks like this:
| Class | Share of value | Share of items | Count frequency |
|---|---|---|---|
| A | Top ~80% of issue value | ~10–20% of items | Every 30 days |
| B | Next ~15% | ~30% of items | Every 90 days |
| C | Bottom ~5% | ~50–60% of items | Every 365 days |
A small set of A-class items carries most of your value; a large tail of C-class items carries very little. Counting the A-class twelve times a year and the C-class once concentrates effort exactly where an error is most expensive.
The first classification pass
On a fresh migration, nothing is classified. The first pass is a one-time exercise you run per storeroom:
- Pull twelve months of issue history per stock line — quantity issued times unit cost gives annual issue value. This is a BIRT/Cognos report or a saved query over
MATUSETRANSjoined toINVENTORY. - Sort descending by annual issue value and compute the running cumulative percentage.
- Tag the lines that make up the top ~80% of cumulative value as A, the next ~15% as B, and the remainder as C, writing the result to each stock line's ABC Type field in the Inventory application.
- Seed any brand-new stock line with no history manually — usually A or B if it is a planned critical spare.
After this one pass, turn on quarterly auto-recalculation (below) and you never hand-classify the bulk again. The Tier 0 query set from Part 1 even includes Stock Lines Missing ABC Class so you can see, at a glance, which lines still need a class assigned.
Classify per storeroom, not per company
This is the mistake that quietly ruins a cycle-count program: applying one company-wide ABC list to every storeroom. Different storerooms have different A-items. The bearing that is A-class in your main plant storeroom may be a rarely-touched C-item in a satellite storeroom. Classify per site or per storeroom, because the count date and the value profile are storeroom-specific. If the same item lives in three storerooms, each has its own classification and its own count schedule.
<aside>
⚠️ Watch out: ABC classification and cycle-count date are per stock line — that is, per item per storeroom. There is no single company-wide "count date" for an item. Storekeepers and reports that assume one will chase a number that does not exist.
</aside>
⚙️ Setting Count Frequency by Class
Once items are classified, the count frequency per class is configured centrally on Organizations → Inventory Options → ABC Type:
| Class | Frequency |
|---|---|
| A | Every 30 days |
| B | Every 90 days |
| C | Every 365 days |
MAS 9 uses this to advance each stock line's next count date after every reconciliation. You classify the item once; the system schedules the counts forever after. The frequencies above are the conventional defaults — tune them to your risk appetite and your counting capacity, but keep the proportion: A counted many times more often than C.
📋 Generating and Assigning Count Books
With classification and frequency in place, the weekly rhythm is short. The Physical Count application (working over INVBALANCES) drives it.
- Generate count lists. In Physical Count, run the Generate Count Lists action against
physcntdate <= SYSDATE— that pulls every stock line whose count is due. - Assign the count lists to storekeepers, typically by area or aisle.
- Execute the counts on Maximo Mobile Inventory or on the desktop.
- Reconcile variances — within tolerance auto-adjusts, outside tolerance routes to a supervisor (next section).
- The count date auto-advances per class, and the item drops off this week's list and reappears when it is next due.
The Tier 0 starter pack from Part 1 already gave storekeepers the two saved queries that make this visible without opening the app cold: Cycle Counts Due This Week (physcntdate <= SYSDATE + 7) and Cycle Counts Overdue (physcntdate < SYSDATE). The due list is a Start Center portlet; the storekeeper sees it every morning.
A worked weekly pass
Monday morning, a supervisor runs Generate Count Lists. It returns forty A-class and B-class lines due this week. They split them across three storekeepers by aisle. Each storekeeper opens Maximo Mobile, walks their aisle scanning bins, and enters counts. By Wednesday the counts are in; the supervisor reconciles; thirty-six lines were dead-on or within tolerance and auto-adjusted, four exceeded tolerance and are now in the supervisor's queue for a recount and a root-cause note. No storeroom shutdown. No paper.
📏 Variance Tolerance: Auto-Adjust vs. Route
Not every count discrepancy deserves a supervisor's attention. Tolerance decides which do. It is configured on Organizations → Inventory Options as two thresholds:
- Count Variance % — for example, 2% for A items, 5% for B, 10% for C.
- Count Variance $ — an absolute floor, for example $100.
Anything inside tolerance auto-adjusts on reconciliation — the balance corrects and the count date advances, no human required. Anything outside tolerance routes to a supervisor for review, a recount, and a reason before the adjustment posts.
Why two thresholds
The percentage catches proportional errors on high-quantity items; the dollar floor catches material errors on low-quantity, high-value items where a small percentage is still real money. A count off by one unit on a $5,000 rotating spare might be under 2% but well over the $100 floor — you want that one reviewed. Configure both, and the tighter of the two wins.
A worked reconciliation
A storekeeper counts an A-class fastener line: the system balance says 480, the physical count is 472 — a variance of 8 units. Unit cost is $0.90, so the dollar variance is $7.20. The percentage variance is 8/480 ≈ 1.7%. Against an A-class tolerance of 2% and a $100 floor, both thresholds are satisfied, so the line auto-adjusts to 472 and the count date advances 30 days. Now the same storekeeper counts an A-class rotating seal: balance says 6, count says 5 — one unit, but at $1,400 each that is a $1,400 variance. The percentage (16.7%) and the dollar amount both blow past tolerance, so the line routes to the supervisor for a recount and a reason code before any adjustment posts. Same day, two counts, two entirely different treatments — which is exactly what a tuned tolerance is for.
<aside>
💡 Key insight: Tolerance is where a cycle-count program earns its keep or drowns. Set it too tight and every count routes to a supervisor who stops reviewing them; set it too loose and real shrinkage auto-adjusts away invisibly. Start at 2/5/10% by class with a modest dollar floor, then tune from the actual variance distribution after the first month.
</aside>
📱 Paperless Counts on Maximo Mobile
The point of the whole program is realized on the phone. Maximo Mobile Inventory lets a storekeeper count in-bin, scanning as they go, without a clipboard and without walking back to a PC. The Adjust Inventory tile handles physical count and adjustments; scanning a bin label auto-populates the bin, and scanning the item confirms the line.
The productivity gain is real: a barcode-driven mobile count is dramatically faster than a paper count later keyed into a terminal, and it removes the transcription errors that a two-step paper process introduces.
The offline caveat
Mobile counts can be created offline in a low-signal warehouse, but they need a sync before reconciliation. A count entered on a phone that has not synced is not yet visible to the supervisor doing reconciliation. Warn storekeepers to sync (a pull-to-refresh) before they report a count area complete, and configure conflict handling so two people counting the same bin offline don't silently overwrite each other — last sync wins unless you scope offline data by storeroom or bin.
🔁 Keeping Classifications Fresh: ABC Auto-Recalculation
Classifications go stale. An item that was A-class three years ago may barely move today; a new critical spare may still be sitting in C because nobody reclassified it. Left alone for two years, your C-class list balloons with items that should be A or B, and your counting effort points at the wrong shelves.
MAS 9 can recompute ABC every quarter from issue history. Turn it on. It re-runs the annual-issue-value calculation and re-tags each stock line, so the classification tracks reality instead of freezing at whatever it was on migration day. Pair the auto-recalculation with a quarterly supervisor spot-check — the algorithm handles the bulk, the human catches the critical-spare-in-the-wrong-class exceptions.
🧮 The Accuracy KPI
Cycle counting produces the one number an inventory controller lives by:
Inventory Accuracy % = lines counted correctly / total lines countedReported monthly, by class, it turns accuracy from an annual verdict into a managed trend. You watch it move; you drill into the class or storeroom that dips; you tie a dip back to a root cause — a bin that isn't labeled, a storekeeper who isn't scanning, a receiving process that isn't putting away to the right bin.
Because the count books, variances, and reconciliations all live in Maximo, the KPI is a byproduct of doing the counts, not a separate reporting project. A monthly dashboard by ABC class is the natural artifact.
⚠️ Edge Cases That Bite
A few realities to design around before they surprise you:
- Per-storeroom count dates. As noted, the count date is per stock line. The same item in three storerooms has three independent schedules. Reports and queries must filter by storeroom.
- Offline sync before reconciliation. Counts done offline are invisible until synced. Build "sync before you report complete" into the mobile SOP.
- Bin-level counting is faster. If your storeroom uses bins, count one aisle or one bin range at a time. Bin-level counts are dramatically quicker than counting an item across every bin it lives in, and they map cleanly to how a storekeeper physically walks the floor.
- New items with no issue history. A brand-new stock line has no annual issue value, so ABC can't classify it from history. Seed it manually — usually as A or B if it is a planned critical spare — until it accumulates enough history for auto-recalculation.
🔧 Troubleshooting Cycle Counts
The recurring problems and their fixes:
| Symptom | Cause | Fix |
|---|---|---|
| Count list is empty | No lines due, or wrong storeroom filter | Confirm physcntdate and storeroom scope |
| C-class list keeps growing | ABC auto-recalculation is off | Enable quarterly recompute + spot-check |
| Every count routes to supervisor | Tolerance set too tight | Loosen % / $ thresholds per class |
| Real shrinkage disappears silently | Tolerance set too loose | Tighten thresholds; review the $ floor |
| Supervisor can't see a mobile count | Count created offline, not yet synced | Sync the device before reconciling |
| Same item, different count dates | Count date is per storeroom by design | Filter reports by storeroom |
🎓 The Commandments of Smart Counting
- Thou shalt cycle count, not shut down — proportional counting beats wall-to-wall.
- Thou shalt classify per storeroom, never one list for the whole company.
- Thou shalt let frequency and count dates auto-advance by class.
- Thou shalt set both a percent and a dollar tolerance, and tune from real data.
- Thou shalt count on mobile — and sync before reconciling.
- Thou shalt recompute ABC quarterly, so classifications track reality.
Key Takeaways
- Wall-to-wall counting is the wrong model — cycle counting finds variance in weeks, with no storeroom shutdown, on a rolling A/B/C schedule.
- ABC classification is by annual issue value, done per storeroom — A monthly, B quarterly, C annually — because count dates are per stock line, not per company.
- Generate Count Lists from Physical Count drives the weekly rhythm, and count dates auto-advance after each reconciliation.
- Tolerance decides auto-adjust vs. route to supervisor — set both a percentage and a dollar threshold and tune from the first month's variance distribution.
- Count paperless on Maximo Mobile, sync before reconciling, and recompute ABC quarterly so classifications never go stale.
References
- IBM Maximo Application Suite Documentation
- Maximo Manage — Physical Count and cycle counting (IBM Documentation)
- Maximo Manage — Inventory and ABC analysis (IBM Documentation)
- Maximo Mobile — Inventory Count app (IBM Documentation)
Series Navigation
| Previous: | Part 3 — Fast Receiving & Barcode |
|---|---|
| Next: | Part 5 — Reservations & Replenishment |
About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.
Published by TheMaximoGuys | July 2026
Posam Lakshminarayana
Venkat Achanta