Where do stock discrepancies actually come from?

A stock discrepancy is almost never one dramatic event — it’s the sum of small moments that never got recorded, each individually forgettable.

  • A return accepted at the counter and put back on the shelf without a note
  • A damaged or expired item quietly pulled and binned, never written off
  • A “just this once” discount or comp that skipped the till entirely
  • A unit mismatch — stock received by the case, sold and counted by the piece
  • The same SKU (stock keeping unit) selling on two channels that don’t share a live number, so both channels think the last unit is still available

Why doesn’t counting more carefully fix it?

Because a count only tells you the discrepancy exists, not when it started or why. By the time someone counts, the return that started it happened three weeks and forty transactions ago, and there’s no trail back to it.

This is why the same handful of SKUs tend to drift every single count. It’s not that staff count those items badly; it’s that those items go through more manual handling — returns, substitutions, bundling — each one a place the record can quietly stop matching reality.

How do you run a stock count that actually finds the cause?

Two changes turn a stock count from a single number into something diagnostic: counting more often, and counting blind.

  • Cycle count high-movement SKUs weekly instead of counting everything once a quarter — smaller gaps are far easier to trace back to a specific day
  • Count blind: don’t show the counter what the system expects. A number that “confirms” the system gets rubber-stamped instead of actually checked
  • Log every write-off, return and comp at the moment it happens, not at count time from memory
  • Reconcile per-channel before combining totals — a channel-level mismatch points straight at where stock is double-counted or double-sold

What actually fixes recurring stock discrepancies?

One shared stock ledger, not tighter counting. Discrepancies compound when stock is recorded in more than one place — a register, a spreadsheet, a storefront plugin — because each one only sees the moves that happened to pass through it. Storely keeps a single stock ledger per SKU that every channel writes to directly, so a return, a transfer or a sale updates the same number the moment it happens, instead of waiting to be reconciled into it later.