Two warehouses run cycle counts. One posts every adjustment automatically and wonders why its inventory accuracy score keeps drifting. The other holds the right counts for review and catches the errors before they hit the books. Same feature, wildly different outcomes. The difference is not effort. It is a handful of tolerance settings and understanding how they cascade, and it is exactly what an auditor zeroes in on when they review your counting process.

Cycle counting in Fusion is deceptively deep. The counting is the easy part. The setup that decides which counts get scrutinized is where the real design lives.

What a cycle count actually is

A cycle count checks a subset of inventory during the normal working day, rather than freezing the whole warehouse for a wall to wall count. You define it once, then it runs on a schedule, comparing what was physically counted against what the system thinks is on hand. When those two numbers disagree, the system has a decision to make. Post the adjustment quietly, or hold it for a human to approve. That decision is the heart of the whole thing, and tolerances drive it.

Everything is built through the Create Cycle Count and Manage Cycle Counts tasks in the Inventory work area. You can base a count on ABC classes or on item categories from Product Information Management. But the mechanics that matter for accuracy sit in the approvals and tolerances.

The two kinds of tolerance

Fusion supports two separate tolerance types, and mixing them up leads to weak controls.

Quantity variance tolerance is a percentage. It limits the gap between the counted quantity and the system on hand quantity. Count eighty when the system says a hundred, that is a twenty percent negative variance, and whether that needs approval depends on the limit you set. You define a positive and a negative limit separately, because being over and being under often carry different risk.

Adjustment value tolerance is about money, not units. It limits the total value of an adjustment. A ten unit swing on a cheap fastener is noise. The same swing on a costly component is a real financial event. The value tolerance catches the expensive mistakes even when the quantity looks small, which is precisely the kind of control an auditor wants to see.

Two lenses on the same count. One watches the count, the other watches the dollars. Good setups use both.

The cascade, and why auditors ask about it

Here is the part most people set up loosely and later regret. Tolerances do not live in one place. They cascade, and the system checks them from most specific to least specific.

For quantity variance, Fusion looks first at the tolerance defined at the item level. If none exists there, it falls to the item's cycle count class. If none exists at the class, it falls to the cycle count header, which covers the entire count. And if no tolerance is defined at any of those levels, the system assumes there is no limit at all, which means every count posts without review.

Read that last line again, because it is where accuracy quietly dies. A cycle count with no tolerances defined anywhere is not a tight count. It is a count with the brakes disconnected. Everything posts, nothing gets reviewed, and the accuracy metric slowly rots while the reports look busy.

This cascade is exactly what a sharp auditor probes. Not just whether tolerances exist, but at what level, and whether the high value or high risk items have tighter limits than the general population. A single loose header tolerance applied to everything is a red flag. Item and class level tolerances that tighten around the items that matter is the sign of a process someone actually thought about.

The approval decision

Alongside the tolerances sits the approval option, which decides when the system requires sign off. The meaningful choice is to require approval only when a count falls out of tolerance, so routine accurate counts post automatically and only the exceptions reach a human. That is the efficient middle ground. The alternative, requiring approval on every count regardless of tolerance, drowns the team in rubber stamping and usually leads to approvals being clicked through without thought, which is worse than no review at all.

The design goal is to spend human attention only where it earns its keep. Tolerances plus the out of tolerance approval option do exactly that. They let the accurate counts flow and stop the suspicious ones for eyes.

Recounts before adjustments

One more control worth building in. The system can automatically request a recount for counts that fall outside tolerance, rather than jumping straight to an adjustment. You set a maximum number of automatic recounts, and once that limit is hit, the count is held for approval.

This matters because the most common cause of a wild variance is a miscount, not a real discrepancy. A recount catches the human error at the source, before it ever becomes an adjustment on the books. Auditors like this too, because it shows the process tries to verify reality before it changes the record.

The through line

A cycle count is only as strong as the tolerances behind it. Quantity variance watches the units. Adjustment value watches the money. The cascade from item to class to header decides how precisely the control fits, and leaving it empty means no control at all. The out of tolerance approval option spends human attention wisely, and automatic recounts catch miscounts before they become adjustments.

None of this is visible in the counting itself. It all lives in the setup, which is exactly why it separates a warehouse that trusts its numbers from one that just hopes they are right. Build the cascade deliberately, and the audit takes care of itself.

More practical Oracle Fusion walkthroughs land here every day. Video versions live on the SCM Simplified YouTube channel.