If you both stock a SKU and dropship it, you have hit this. Your warehouse count says 6. The supplier's overnight CSV says 40. Amazon, eBay and your own store each want a single integer.
Most advice treats this as a routing question — which supplier ships the order. That matters, but it comes later. The number you publish is decided *before* anyone buys, and getting it wrong is what cancels orders. This is a stock-accounting problem first.
One SKU, three numbers: what your shelf, your supplier's feed and your open PO each actually tell you
You rarely have two sources. You have three, and they answer different questions. Your shelf: "how many can I put in a box today?" Your supplier's feed: "how many did they have when they generated the file?" — a past-tense statement about someone else's warehouse, shown to every reseller they supply. Nobody is holding those 40 units for you. Your open PO: "how many has someone promised to send, and when?"
| Source | What it actually tells you | How stale it can be | Counts toward what you publish? |
|---|---|---|---|
| Own on hand | What you can pick today | Minutes, if picks are recorded live | Yes — minus units reserved by open orders |
| Own stock, not booked in | Units in the building, missing from records | Hours to days | No. Why the shelf "says 6" when it's really 26 |
| Supplier CSV/FTP drop | Their count at file time, shown to all resellers | Often 24 hours — many drop one file overnight | Yes, discounted and expired (below) |
| Supplier API pull | Their count at pull time | Your pull interval | Yes, discounted less |
| Open PO | A promise, with a lead time | Until the date moves | Only if confirmed, and only where the lead time fits your handling time |
Feed cadence is what sellers assume away. Batch imports run "at defined intervals, such as hourly or daily" (Inventory Source); smaller suppliers often send one file per day. Find out which yours does, per supplier.
Why adding the numbers oversells, and why publishing the smallest one loses sales
The naive move is 6 + 40 = 46. That oversells for a reason unrelated to your systems being slow: the 40 is shown to every reseller that supplier has. If four of you publish it, the same 40 units back roughly 160 units of marketplace availability. The supplier isn't double-counting; you collectively are. Feed lag is a second problem stacked on top.
The overcorrection is MIN(6, 40) = 6. Safe, and quietly expensive — you throw away all your dropship capacity on every SKU, including slow movers where the supplier's number was perfectly reliable. Both are wrong because both treat the two numbers as the same kind of fact. Your shelf count is a measurement. The supplier's feed is a claim of unknown age. Keep the measurement whole; discount the claim by its age and its author.
published = own_available + trusted_supplier_qty
own_available = on_hand − reservedOn a good supplier with a fresh feed, trusted_supplier_qty is close to the raw number. On a daily CSV from an unreliable one, it should often be zero.
A stale feed is a confidence problem, not a quantity problem
Sellers fix staleness with a flat buffer — subtract 2 from every supplier number. That treats a confidence problem as a quantity problem, and fails at both ends. Supplier says 400 and you sell three a month: subtracting 2 protects nothing. Supplier says 2 and the file is 20 hours old: subtracting 2 reaches zero by accident, not by reasoning.
Expire the record, don't just shrink it. Give every feed a maximum trusted age. Past it, that supplier's contribution drops to zero and you publish only your shelf. A 30-hour-old file from a supplier who promised daily updates is not a small number — it is a *missing* one. Something broke, and a discounted version of a file that never arrived is worse than nothing.
The discount only bites in the low tail. Compare the feed quantity to your velocity over one feed interval — that is your exposure. Many times your exposure: publish as-is. Within a couple of multiples: subtract it. At or below it: publish zero.
One free diagnostic: if a supplier's quantity hasn't changed in weeks, it is probably a static catalogue value, not a live count. A number that never moves must never be trusted near zero.
Per-supplier reliability is the one buffer that is justified — size it from their track record
Blanket buffers are guesswork. A per-supplier buffer isn't, because you already hold the data: your order history with them.
Fill rate is the standard measure — orders fulfilled completely ÷ orders placed, with commonly quoted domestic benchmarks around 95–98% (Docshipper). You don't need the benchmark; you need *yours*, because it is the probability that a unit they claimed doesn't exist when you buy it. Track four things from your own records:
- Fill rate — orders you sent that shipped complete ÷ orders you sent.
- Short-ship and cancel rate — the inverse, and the one that becomes a marketplace defect.
- Median feed age — measured hours between drops, not what the onboarding email promised.
- Feed movement — share of their SKUs whose quantity changed in the last 7 days.
A supplier at 98% fill on a two-hour API pull earns a near-zero buffer. One at 88% on a nightly CSV earns a large buffer, a short trusted age, and possibly a rule that they never back a listing on your strictest channel.
Price it precisely, because a bad feed costs account health, not just a refund. Amazon publishes an Order Defect Rate threshold under 1%, a pre-fulfilment cancel rate under 2.5% and a late dispatch rate under 4%; breaching them can deactivate seller-fulfilled offers (Amazon). On eBay an out-of-stock cancellation is a transaction defect, against 2% for all sellers and 0.5% for Top Rated Sellers (eBay).
What an open purchase order should and should not add to available stock
Nothing, as available. A PO belongs in a separate number with a date on it — only units you control go in a box this afternoon. A confirmed PO can raise what you publish when all of these hold:
- The supplier confirmed it, with quantity and date — not just that you raised it.
- You count the confirmed quantity, not the ordered one. They differ more often than sellers expect.
- The lead time fits the handling time you promised on that channel. A three-day PO can back a ten-day handling time; it cannot back next-day.
- You count it once. Goods that arrived and were booked in are already in on hand.
The failure that actually produces "the shelf says 6 when it's really 26" is stock that arrived and was never received into your records. No buffer fixes that — check your receiving backlog before hunting for a sync bug.
Decide which source ships the order after the sale, not before it
Publish one combined number. When an order lands, *then* pick the source — your shelf if the margin is better, otherwise the dropship request. The buyer never sees the decision, and you can change routing rules without touching a listing.
Two things must be true. First, the instant a sale lands, the unit it consumed is held against the source that will fulfil it, so no other channel can sell that unit while you decide. That hold is the real anti-overselling mechanism; the published number is only a forecast. Second, if the dropship request is rejected, the fallback must already be defined — the buyer is waiting.
Your supplier says it's stocked but your own stock location disagrees — what that means
This looks like an inventory discrepancy and isn't one.
The signal: the supplier's feed says stocked, while your own record says the stock location for that SKU *is the supplier's warehouse* — even though you physically hold units. That is a mapping fault, not a counting fault. The SKU was set up as dropship-only, later became something you also stock, and the location field never changed. The damage: the same units counted twice, once as yours and once as theirs, inflating the published number by exactly the amount you hold.
- Confirm physically. Do you hold units, yes or no? Everything depends on that answer.
- Fix the location, not the quantity. Editing the number treats the symptom; the conflict returns on the next feed run.
- Re-derive and check it went down. If it didn't fall, the double-count is still there.
- Resolve them one at a time. Bulk-closing clears the alert and leaves every inflated listing live.
The tell: ordinary drift is a quantity that went wrong. This is a quantity that is *right twice*.
The weekly reconciliation you can run in a spreadsheet, without buying anything
Half an hour a week, two tabs, exports you already have.
Tab 1 — SKU reconciliation. One row per SKU with both own stock and a supplier source.
| Col | Field | Source |
|---|---|---|
| A | SKU | catalogue |
| B | Own on hand | stock export |
| C | Reserved by open orders | orders export |
| D | Own available | =B-C |
| E | Supplier feed qty | supplier file |
| F | Feed timestamp | file drop time |
| G | Feed age (hrs) | =(NOW()-F)*24 |
| H | Trusted supplier qty | =IF(G>MaxAge,0,MAX(0,E-Buffer)) |
| I | Should publish | =D+H |
| J | Channel shows | channel export |
| K | Delta | =J-I |
Sort by ABS(K) descending, read the top 20. Every non-zero delta is a sync that didn't run, a reservation that didn't release, or a double-count — and the row usually tells you which. Two flags: any row where G exceeds that supplier's promised interval is a failed feed, not an old one; any row where J > 0 while D = 0 and H = 0 is stock published against nothing.
Tab 2 — supplier scorecard. One row per supplier, monthly: orders sent, shipped complete, short-shipped, cancelled, fill rate, median feed age, share of SKUs that moved in 7 days. This sizes Buffer and MaxAge in column H. Without it you are guessing; with it you are pricing.
Run it four weeks and the pattern names itself. Usually one supplier causes most of the damage — a commercial conversation, not a software one.
Where a system takes over
The spreadsheet is the right first move because it makes the accounting visible. It stops being right when supplier count grows, or when deltas need catching within the hour rather than the week. That is the model Sugibana Flow is built on: supplier feeds and your own multi-warehouse stock kept as separate sources rather than merged into one number, reservations that stop the same unit selling twice across PrestaShop, eBay, Amazon, Allegro, Shopify, Etsy, TikTok Shop and Walmart, purchase orders that stay out of available until they shouldn't, and an audit trail showing which source moved a number and when. It is early and runs a waitlist, so run the reconciliation manually first — the thinking transfers either way.
FAQ
Should I use separate SKUs for the warehouse version and the dropship version? It does prevent double-counting, because the two numbers never meet. It costs you two listings competing on one marketplace, split reviews and sales history, and a manual decision every restock. Prefer one SKU with two sources if your system can hold a unit against a specific source at the moment of sale.
How big should my supplier buffer be? Per supplier, from your own order history — never one flat number across the catalogue. Start from that supplier's short-ship and cancel rate and how many units you'd sell during one feed interval. Many times that: no buffer. At or below it: publish zero.
My supplier's feed is 24 hours old. Is that usable? Usable for slow movers, dangerous for fast ones — the difference is your velocity, not the feed. Set a maximum trusted age per supplier, and treat a file later than the promised cadence as zero: a late file usually means a broken one.
Does an open purchase order count as available stock? Not as available. Count it only once the supplier confirms it, count the confirmed quantity rather than the ordered one, and only where the lead time fits your promised handling time. Never count it twice — booked-in goods are already in on hand.
Sources: Inventory Source · Docshipper · Amazon Seller Central · eBay seller standards