Why your available stock can show more than what's physically on the shelf — and how to close that gap yourself.
If you've ever seen a channel accept an order for something you were actually out of, this article explains why that happens when you're running on auto-depletion, and what you can do to prevent it going forward.
The trade-off you're making
Luminous can only be as accurate as the last time your warehouse told it something true. Every inventory system holds a model of your stock, and that model only gets updated with physical reality when a person or a scanner confirms something — a counted receipt, a scanned pick, a cycle count.
Auto-depletion is designed to remove that manual work. Instead of waiting for a confirmation, it makes a fast, reasonable inference about what probably happened — a label was printed, so the return is probably coming back; an order came in, so the pick probably went out. That's what makes auto-depletion so much easier to run day to day. But each of those inferences is a small guess, and if several are running at once with nothing double-checking them against reality, the guesses add up.
Importantly, that drift isn't random — it leans in one direction: overstating what you have available to sell. Automations that add stock back (like return restocks) tend to fire early, on intent. Automations that remove stock tend to fire late, on confirmation. And losses that never get logged — damage, mis-picks, shrink — never correct themselves without a count. Left alone, the gap only grows.
None of this means something is broken. It means the convenience of automation has a cost, and that cost is paid with buffers and cycle counts.
Five common sources of drift
If you're using any of these, here's what typically happens and how to protect against it.
1. Returns that restock the moment the label is printed
What happens: The instant a return label is generated, the unit shows as back in stock — even though it's still in the customer's home, in transit, or about to be inspected and written off.
Some returns never ship back at all, and some arrive damaged or unsellable. Industry-typical rates run 10–20% never arriving and 5–15% arriving unsellable. On 40 open returns, that's roughly six to fourteen units showing as sellable that will never actually be available — and that gap doesn't fix itself, because nothing in the system automatically reverses it.
What to do: If possible, restock on physical receipt and inspection instead of on label print. If you'd rather keep the faster restock-on-label setting, carry a buffer roughly equal to your in-flight returns × your typical unsellable/never-arrives rate, and periodically write off returns that never came back.
2. Receiving inventory without scanning it in
What happens: Clicking "receive all" against a purchase order records what the PO said should have arrived — not what actually showed up. If a vendor shorted a case, substituted product, or a carton got crushed in transit, none of that shows up until a count catches it. It can also scatter units across pick locations that Luminous doesn't know about, so the total is right but pickers can't find the stock.
What to do: Scan-verify your highest-velocity items even if you receive lower-volume items without scanning — most of the risk is concentrated in a small number of SKUs. Size a buffer for the rest based on how often your vendors tend to under-ship.
3. Not running cycle counts
What happens: This is the one that compounds everything else. Every other source of drift on this list creates a small error, and a cycle count is the only thing that removes it. Skip counts for a while and the errors just keep stacking — and because your ledger stays internally consistent the whole time (every movement still sums up correctly), there's no warning sign. The mismatch is between the system and the building, not inside the numbers themselves.
What to do: Count your best-sellers most often (weekly), mid-movers monthly, slow movers quarterly. A handful of quick counts on your top items each day is far cheaper than a single oversell on a hero product — and every count you run lets you safely shrink your buffers.
4. Auto-assembly and auto-disassembly of bundles
What happens: When an order comes in for a bundle, the system can automatically consume the components and create the finished good — instantly, on paper. In reality, that build takes time, may run short on packaging or inserts, and may lose a few units to normal yield loss. In the meantime, the finished good looks available before it's actually built, while the components look consumed even though they're still sitting on the shelf.
What to do: Buffer the finished good by about one build cycle's worth of demand, so you're never promising more than your team can actually produce before the next ship cutoff. Buffer the components too, and if your build process has a known yield loss, account for that rather than assuming a perfect 1:1 conversion.
5. Using kits instead of true multi-pack units for 2-packs and 3-packs
What happens: This is the single biggest source of "why is my stock wrong" tickets we see. When a 2-pack or 3-pack is set up as a kit rather than its own unit of measure, its "available" number is a live calculation drawn from the same pool as the single item and every other kit built from it. That number is only ever as fresh as its last recalculation — so if singles keep selling in between recalculations, or if multiple kit sizes are drawing from the same pool, channels can end up collectively advertising more units than you actually have.
What to do: Where a pack isn't a physically distinct, pre-built item, convert it to a true unit-of-measure listing instead of a kit — that way every channel is drawing from and directly reducing the same real number, with nothing to recalculate. If you need to keep kits, put your buffer on the underlying component rather than on each kit size, and set any kit-level buffer to at least one full pack quantity.
Seeing how this adds up: a worked example
Say you have a single-unit SKU selling 40 units a day, last counted 60 days ago, with returns restocking on label print, receiving entered from the PO without scanning, and also used as the component behind a 2-pack kit — with no buffer set.
| Source of drift | Over 60 days | Phantom units |
|---|---|---|
| Returns in flight | ~12% never arrive, ~8% arrive unsellable | +4 |
| Unscanned receiving | Vendor net-short rate ~0.5% | +11 |
| No cycle count in 60 days | Damage/mis-pick/sample loss ~0.3% | +7 |
| Kit calculation lag | Singles sold between kit recalculations | +6 |
That's a system on-hand of 58 against a real shelf count of about 30 — a 28-unit overstatement. At 40 units a day, that means the system would keep accepting orders for roughly 17 hours after you were actually sold out. A buffer of around 30 on this SKU would have closed the entire gap, and counting weekly instead of every 60 days would shrink it enough that a buffer of just 8–10 would do the job.
Sizing your own buffer
A buffer isn't a workaround — it's how you pay, on your own terms, for the convenience of not scanning or logging every transaction. As a rough formula:
buffer ≈ (daily velocity × days between counts × your drift rate)
+ (returns in flight × unsellable-or-never-arrives rate)
+ (one build cycle of finished-good demand)
+ (largest pack quantity, for kit components)
If that's more than you want to calculate for every SKU right away, a simple starting point is one week of sales velocity as the buffer on every auto-depleting SKU, tuned down over time as you tighten your count cadence.
| Your setup | Start your buffer here | You can tighten it once |
|---|---|---|
| Blind receiving, no counts, fast-moving item | 7 days of velocity | You're counting weekly or better |
| Returns restock on label print | 25% of returns in flight | Restock moves to physical receipt |
| Auto-assembled bundle or finished good | 1 build cycle of demand | Builds run on a schedule, not on demand |
| Component behind a 2-pack or 3-pack kit | 1 × largest pack quantity | Multi-packs move to true unit-of-measure |
| Multiple kits sharing one component pool | Buffer the component, not each kit | — |
| Scanned receiving, weekly counts, no auto-restock | 1–2 units | — |
The most effective fix is always the one closest to where the guess enters the system — buffering the shared component instead of every kit built from it, gating return restocks on inspection instead of cleaning up phantoms later, or scanning just your top 20 SKUs instead of trying to buffer two thousand.
What's expected versus what's worth reaching out about
These are normal and usually resolve themselves once a buffer or count catches up — no need to contact support:
- Being off by a few units on a SKU that hasn't been cycle counted recently.
- Available stock rising temporarily after a wave of returns restocked at label print.
- A bundle showing available slightly before it's actually been built.
- Components showing as consumed while still physically on the shelf, right after an auto-assembly.
- A kit's availability lagging a recent singles sale by a few minutes until the next recalculation runs.
- Two channels together advertising slightly more than you own, when a kit and its single share the same pool.
- A received quantity matching your purchase order rather than what physically arrived, if receiving wasn't scanned.
These are worth reaching out to us about, since they point to something actually wrong rather than expected variance:
- The quantity pushed to a channel doesn't match what Luminous was showing you at that same moment.
- Your movement history doesn't add up to your current on-hand.
- A cancelled or reversed order doesn't actually restore the inventory it depleted.
- Negative on-hand with no corresponding negative transaction you can find.
- An adjustment or count that updated one location but not another.
- Inventory depleting at the wrong warehouse or bin from where it was actually picked.
- The same order appears to deplete inventory twice.
Before you reach out, a quick five-minute check
Most "why is my inventory wrong" cases resolve with these questions — the last one is what turns it into something our team can act on right away:
- When was this SKU last cycle counted? If it's been more than 30 days, count it now — that alone resolves most cases.
- What buffer do you have set on this SKU and channel? If it's zero on something you're auto-depleting, that's very likely your answer — see the table above.
- Are you auto-restocking returns, and how many are currently in flight? In-flight returns times your typical unsellable rate is often the whole discrepancy.
- Was your most recent receipt scanned in, or entered straight from the PO? If it came from the PO, the number reflects the vendor's paperwork, not what actually arrived.
- Is this SKU a kit component or part of an auto-assembled bundle? If so, add up what every kit and the single are advertising together and compare that to your physical count.
- Does your movement history explain your current on-hand? If the transactions add up correctly, the system is behaving consistently and the gap is physical — not a bug.
- Still doesn't add up? That's when to contact support. Send us the SKU, warehouse and bin, the timestamp, what was displayed versus what was pushed, and the movement history for that window — that's what lets us diagnose it in minutes instead of hours.
The bottom line
Running lean — auto-depleting everything, skipping scans, skipping counts — is a completely reasonable way to operate. It's just not free. Buffers and cycle counts are how you pay for that convenience on your own terms, instead of discovering the cost the moment you oversell.