Spot-checking your reorder suggestions in 30 seconds
A four-question spot-check for any reorder suggestion — coverage math, dark-day inflation, stale lead times, pending promos — each with a worked example.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
Four questions. That's the whole audit, and it takes about thirty seconds per line: Does the suggested quantity beat days of cover? Is the velocity number accurate about the days it skips? Is the lead time still current? Is a promo pending inside the coverage window? Every reorder suggestion — from an app, a spreadsheet, or a supplier's rep — is arithmetic on three inputs, and each input can be verified faster than you can argue with the output.
The weekly list itself — which SKUs surface, in what order, with what urgency — is covered in the weekly reorder decision list. This article is the verification layer: the habit of spot-checking suggestions before money moves, so the list you act on Monday is one you could defend on Tuesday.
What a reorder suggestion actually is
Strip any suggestion down and it decomposes into the same shape:
suggested qty ≈ velocity × coverage target − on hand − on order
Illustrative numbers for BIKE-LT-02, a bike light: velocity 6 units/day, coverage target 45 days, on hand 40, already on order 80. The suggestion is 6 × 45 − 40 − 80 = 150 units. Nothing exotic — but notice the three inputs doing all the work: a velocity number, a coverage target (which hides your lead time), and current stock positions. A suggestion is only as good as those, and each of the four checks below attacks one of them.
Some tools never show the decomposition. The Assisty founder reply on the App Store is candid about one reason: "The current reorder suggestions use the same min and max inventory levels for all products…" (Assisty founder reply, January 2025 — accessed November 2026). When one rule covers the whole catalog, the per-SKU inputs aren't in the math at all — which makes the spot-check the only audit you have.
The 30-second check
| # | Ask | Quick look (10s each) | Pass | Red flag |
|---|---|---|---|---|
| 1 | Does the qty beat days of cover? | on hand ÷ velocity | cover below lead time or below target → qty fills toward target | fast seller left under-covered, slow mover handed a mountain |
| 2 | Is velocity accurate about skipped days? | last 28 days sold ÷ days actually in stock | within ~20% of the app's number | sold-out days averaged in, or a promo spike treated as baseline |
| 3 | Is lead time current? | average of your last 3 POs | within ~5 days of the app's field | order-by dates computed off a number set a year ago |
| 4 | Is a promo pending inside the window? | your promo calendar | nothing pending → suggestion stands | a promo starts before the stock could arrive → adjust or accept knowingly |
Two minutes for a five-line list. Here's what each check catches, worked out.
Check 1: does the quantity beat days of cover?
Days of cover is on hand ÷ velocity: how long the shelf lasts at current demand. For BIKE-LT-02: 40 ÷ 6 = 6.7 days of cover against a 21-day lead time. The shelf cannot survive the wait, so ordering is right — and the suggested 150 brings cover to (40 + 80 + 150) ÷ 6 = 45 days at arrival, exactly the target. Coherent.
This is the fastest sanity check because it requires no trust in anyone's formula — the days-of-cover division is one you can do in your head. A suggestion that leaves a bestseller below its lead time in cover, or parks a slow mover far above its target, is wrong regardless of which app produced it. The flip side shows the same check catching an over-order: if the true velocity were 3/day rather than 6, that "150" becomes 50 days of cover — cash sitting on a shelf for most of a quarter. The direction of the error tells you which input to distrust next.
Check 2: is the velocity number accurate about the days it skips?
The common failure: a trailing average divides by every day in the window, including the days the SKU sat at zero and couldn't sell. Illustrative case, SOCK-M-03 hiking socks: 128 units sold in the last 28 days, in stock on 22 of them. The raw average is 128 ÷ 28 = 4.6/day. Corrected for the dark days: 128 ÷ 22 = 5.8/day — about 27% apart, on identical sales. Against a 45-day coverage target, that's 207 units of need versus 261: a 54-unit gap, roughly nine selling days on a 21-day lead, manufactured entirely by the denominator.
The contamination runs the other way too: a promo spike inside the window inflates the number, and the app then orders for a burst that already happened. The thirty-second version: recompute velocity yourself as last-28-days sold ÷ days in stock, and compare with what the tool shows. If the two differ by more than about 20%, find out which definition the tool used before trusting any quantity it emits.
Check 3: is the lead time still current?
Lead time is the stalest field in any inventory system. Suppliers move factories, ocean transit stretches in peak season, a new freight forwarder adds a week — and the number in the app stays frozen at whatever you typed when you onboarded. Illustrative: BIKE-LT-02's supplier was entered at 18 days fourteen months ago, but your last three POs averaged 26 days from order to sellable stock. Every order-by date the tool computes is now 8 days late — on a 6/day seller, 48 units of demand that arrives before the stock does.
The check: average your last three POs (order date → date sellable) and compare against the stored field — if you raise native POs, those order and receive dates live in the Shopify admin (Shopify Help Center, accessed November 2026). A gap over about 5 days means recalculating before the list runs. How to measure the number properly from PO history — and why supplier quotes systematically undershoot — is in the supplier lead time guide; the trigger math that consumes it lives in the reorder-point walkthrough if you want the full machinery.
Check 4: is a promo pending inside the coverage window?
Trailing velocity cannot see next week's campaign. Illustrative: PIN-EN-043 enamel pins, velocity 11/day, suggested qty 95 — arithmetic all checks out — except your newsletter goes out Monday offering 20% off pins to 9,000 subscribers, and the coverage window runs 45 days forward. The suggestion is correct about the past and wrong about the future you know is coming.
The rule: any promo touching the SKU inside lead time + coverage window means adjust the order deliberately or accept the risk knowingly. Sizing the adjustment: your last comparable promo ran 2.2× baseline for 3 days, so estimated extra demand ≈ 11 × 3 × (2.2 − 1) ≈ 40 units (estimated). Suggested 95 + 40 = 135 — or keep 95 and consciously accept running tight at the promo's tail. What you shouldn't do is let a number built on the past silently govern a future you already know is different.
The real enemy: suggestions you can't audit
A 3-star App Store review (September 2026) of a forecasting app complains less about wrongness than about opacity — the prediction method is "a black box… I actually built a more useful/customized tool just with spreadsheets and ChatGPT for effectively $0" (Prediko App Store review, accessed November 2026). The reviewer's spreadsheet doesn't beat commercial software because it's cleverer; it beats it because it's theirs — every input visible, every step checkable. A suggestion you can't decompose can't be spot-checked, so it gets either trusted blindly or ignored, and both cost money. Uniformity is the other audit-killer: the same min/max applied catalog-wide means the SKUs that needed individual attention got none.
Since we build one of these tools, a note on ours: InventoryX (in development) computes velocity from in-stock days only and takes lead times as manual entries — exactly the two inputs checks 2 and 3 audit. The weekly Buying List shows SKU → days of cover → suggested qty → order-by date with the inputs visible, precisely so a thirty-second check like the one above is possible. Nothing in V1 auto-learns lead times, so keeping that field current is on you; we'd rather hand you a checkable number than a confident one.
Calibrate yourself with an override log
Run the checks for a month and keep a note per overridden line: SKU, suggested qty, your qty, one-line reason. Then read the log as a diagnostic. Overriding more than a third of lines means an input is systematically wrong — usually check 2 or check 3, and the log will show which. Overriding almost nothing means the checks have decayed into ceremony and you're rubber-stamping. The goal was never to second-guess everything; it's that every acceptance is a decision rather than a reflex, and the log is how you tell the difference.
Common questions
How do I verify a reorder suggestion? Decompose it: suggested qty ≈ velocity × coverage target − on hand − on order, then check each input in about thirty seconds. Confirm days of cover beat the lead time, recompute velocity as sales ÷ in-stock days over the last 28, average your last three POs against the stored lead time, and scan the promo calendar for anything inside the window.
What is days of cover? On-hand units divided by daily selling rate — how many days the shelf lasts at current demand. It's the fastest sanity check on any suggestion because a quantity that leaves a fast seller below its lead time, or parks a slow mover far above its target, is wrong regardless of which formula produced it.
Why do reorder apps over-order some SKUs? Usually contaminated inputs: a promo spike inside the velocity window inflates demand, a stale short lead time makes the tool think it can react quickly, or the tool applies uniform min/max rules across the catalog. Spot-check by recomputing velocity from in-stock days only and comparing the app's coverage math for that specific SKU.
Should I trust my inventory app's reorder points? Trust them the way you'd trust a bookkeeper's draft: verify the inputs, not the arithmetic. The formula is old and sound; the inputs — velocity definition, lead time, stock positions — are where errors live. Thirty seconds per line on the four checks catches most of it before money moves.
How often should I update supplier lead times? At least quarterly per supplier, and always after a delivery that stands out as late or unusually fast. Recompute from your last three to ten POs — order date to sellable date — and update the stored field when the average moves more than about five days from what the tool currently assumes.
Next step
Take the next five lines of whatever reorder list you're running — app output or spreadsheet — and run the four checks on each, noting which check fails most often. That failing check is the input to fix first. If you don't yet have a standing list to check, the weekly decision-list guide shows how to build one from Shopify's own data.