How to automate inventory tracking when the count is always wrong

Inventory systems record what should be on the shelf. What is actually on the shelf differs, continuously, for reasons that are mostly mundane — damage, theft, miscounts, returns processed wrongly, items put back in the wrong place.

Every automation built on stock levels inherits that gap. A reorder that fires on a number which is wrong by six units orders the wrong amount, and an availability figure that is wrong by one sells something you cannot ship. So the first automation worth building is the one that measures the gap rather than acting on the number.

What we'll cover

• Recorded stock is not physical stock
• Reconciliation, which comes first
• Thresholds that depend on lead time
• Building it with CodeWords
• Overselling across channels
• What a low-stock alert should say
• The stock that never moves
• Suppliers, who are half the problem
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Recorded stock is not physical stock

The sources of divergence, all ordinary.

Damage and breakage, which is recorded late or not at all.

Returns, which re-enter stock at various points depending on who processes them and how.

Miscounts at receiving, where a delivery of forty-eight is recorded as fifty.

Shrinkage, which is a real number in most businesses and is rarely discussed until a count.

Items in the wrong place, which are present and unfindable, which for fulfilment purposes is the same as absent.

Timing. Stock allocated to an order that has not shipped is neither available nor gone, and different systems treat it differently.

The gap is not a failure to be eliminated. It is a property to be measured, so that automation built on the number knows how much to trust it.

Reconciliation, which comes first

Count something regularly rather than everything annually. Cycle counting — a subset each week, weighted towards fast-moving and high-value items — produces a continuous picture.

Record the variance, not just the correction. Adjusting the number and moving on loses the information; the variance history is what tells you which items and which locations drift.

Report variance by item and by location, since a concentration in one of either is a process problem with a findable cause.

Compare against the system of record, and be clear which system that is when there are several.

Watch the trend. Rising variance means a process has changed, and finding out early is much cheaper than at the annual count.

Use it to set your confidence. An item with consistently accurate counts can drive automation directly; one that drifts needs a buffer.

Thresholds that depend on lead time

The rule that makes low-stock alerts useful rather than noise.

A reorder point is lead time multiplied by the rate of sale, plus a buffer — not a round number chosen once.

Lead times differ per supplier, sometimes by weeks, so one threshold applied to every item is wrong for almost all of them.

Rate of sale changes, seasonally and with promotions, so a threshold set in January is wrong by June.

Recalculate it from recent sales rather than leaving it static, which is exactly the kind of tedious recurring calculation worth automating.

The buffer should reflect variability, not optimism — an item whose demand is erratic needs more cover than one that sells steadily.

Alert with enough time to act. An alert that fires when there is less stock than the lead time requires is a notification of a stockout that has already been decided.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so stock, sales, and supplier data can be combined without anybody exporting a spreadsheet.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which items, which thresholds, and who should be told.
3. Authorize the connections — the commerce platform, the inventory system, and wherever alerts go.
4. Describe the exceptions: an item with no recent sales, a supplier with no lead time recorded, a negative stock level.
5. Run it against last quarter's data and check the alerts it would have produced against what actually happened.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Overselling across channels

The failure customers see, and the one multichannel selling makes inevitable without care.

Each channel holds its own view of availability, updated on a delay.

Two channels selling the last unit simultaneously is not a race condition to be eliminated so much as a certainty to be planned for.

Hold a buffer per channel rather than exposing the full count everywhere, which is the practical mitigation.

Update availability promptly on sale rather than on a schedule, since the window between sale and update is exactly when overselling happens.

Decide what happens when it occurs, in advance — fulfil from elsewhere, offer an alternative, refund promptly — because it will occur and improvising is worse.

Tell the customer quickly. An oversell handled within the hour with an honest message is recoverable; one discovered by the customer a week later is not.

What a low-stock alert should say

How long until stockout at the current rate, which is the number somebody can act on, rather than the units remaining.

The lead time, so the urgency is obvious without a lookup.

Whether an order is already placed and when it arrives, since the commonest wasted response to a stock alert is duplicating an existing purchase order.

What it sells — value and velocity — so prioritisation across a long alert list is possible.

Group the alerts. One message listing eleven items is read; eleven messages are not.

Send it to whoever places orders, on a schedule that matches their ordering rhythm rather than in real time.

The stock that never moves

The other half of inventory, and the one nobody automates.

Slow-moving stock is capital sitting in a warehouse, and it accumulates invisibly because nothing prompts a review.

Report items with no sales in a period, with the value tied up, monthly.

Include the storage cost where you can, since that reframes the conversation from "we might sell it" to "it is costing this much to wait".

Flag stock approaching expiry or obsolescence early enough to discount rather than write off.

Report overstock relative to sales rate — an item with two years of cover is a decision somebody made and nobody revisited.

This is where the money usually is. Most businesses watch for stockouts and never look at the opposite, which is quietly more expensive.

Suppliers, who are half the problem

Stock automation usually stops at your own walls, and the supplier side is where the delays originate.

Track actual lead times, not promised ones. The gap between the two is frequently large and is never in the supplier's favour.

Record it per supplier and per item, since a supplier reliable on one line can be consistently late on another.

Chase automatically. A purchase order past its expected date with no update is a message that nobody sends until somebody notices a stockout.

Report delivery accuracy — on time, in full — which is the number that makes a supplier conversation concrete rather than anecdotal.

Watch for creeping lead times, since a supplier drifting from two weeks to four invalidates every reorder point built on the old figure.

Feed the measured lead time back into the thresholds, automatically, so the reorder points stay correct as suppliers change rather than being adjusted after a stockout.

Making it survive

Handle negative stock rather than treating it as a number. It is a data quality signal and it happens.

Reconcile before acting. An automation that reorders on an unreconciled number orders the wrong amount confidently.

Match items by a stable identifier across systems, since names and descriptions differ and variants multiply.

Handle the item with no sales history, which cannot have a rate-based threshold and needs a different rule.

Report the outcome. Items checked, alerts raised, variance found, and anything skipped for missing data.

Limits worth knowing about

Stock levels lag reality by however long it takes a physical event to be recorded, which is never zero.

Multi-location stock complicates everything, since total and available-here are different numbers and most automations conflate them.

Variants multiply, and an item available in one size and not another is a common source of customer frustration invisible at the product level.

Bundles and kits consume components in ways simple stock tracking misses entirely.

API rate limits apply during peak trading, which is exactly when accuracy matters most.

What to build first

The variance report from cycle counting: count a weighted subset each week, record the variance rather than only the correction, and report by item and location monthly. Everything else on this page is built on the stock number, and this is the only thing that tells you how much that number can be trusted.

Two habits make the difference. Record the variance rather than silently correcting it, since the history is what identifies the items and locations that drift. And express low-stock alerts as days of cover rather than units remaining, because units mean nothing without the sales rate and the lead time beside them.

Frequently asked questions

Why is the recorded stock level always wrong?

Damage, returns, miscounts at receiving, shrinkage, items in the wrong place, and stock allocated to unshipped orders. None is unusual, and the gap is a property to measure rather than a failure to eliminate.

What should a reorder point be?

Lead time multiplied by the current rate of sale, plus a buffer reflecting demand variability — recalculated from recent sales rather than set once. A single round number applied to every item is wrong for nearly all of them.

How do I stop overselling across channels?

Hold a buffer per channel rather than exposing the full count, update availability on sale rather than on a schedule, and decide in advance what happens when it occurs — because it will.

What should a low-stock alert contain?

Days of cover at the current rate, the lead time, whether an order is already placed, and what the item sells. Units remaining alone is not actionable, and duplicating an existing purchase order is the commonest wasted response.

What is the most overlooked inventory problem?

Stock that never moves. Businesses watch for stockouts constantly and almost never report items with no sales and the capital tied up in them, which is quietly the more expensive problem.

Should automation place purchase orders?

Only for well-understood items with reconciled counts and reliable suppliers, and even then with a review. An order placed on a number that is wrong by six units is wrong by six units, confidently.

How often should stock be counted?

Continuously, in subsets — cycle counting weighted towards fast-moving and high-value items — rather than everything once a year. The variance history matters as much as the corrections.

Should reorder points use the promised lead time?

Use the measured one. The gap between promised and actual is usually large and never in your favour, and feeding measured lead times back into thresholds automatically keeps them correct as suppliers drift.

What supplier data is worth collecting?

Actual lead time per supplier and per item, and delivery accuracy — on time and in full. Both make a supplier conversation concrete, and a supplier drifting from two weeks to four silently invalidates every threshold built on the old figure.

Related reading

• BigCommerce and CodeWords
• Connecting Shopify to Slack
• Connecting WooCommerce to Google Sheets