If you sell the same parts in a shop, on Amazon, on eBay and through a wholesale customer or two, you have four places that each believe they know how many you have. They cannot all be right. The problem is not the marketplaces; it is that quantity is being edited in four systems instead of recorded once and published from there.
One ledger, many views
The fix that holds up is boring: keep one stock ledger per SKU and location, record every movement against it, and treat the marketplace quantities as outputs. A receipt from a supplier, a sale, a return, a damaged part written off, a count adjustment: each is a movement with a reason, a person and a time. Available quantity is what the ledger says minus what is reserved by open orders.
Once that exists, each channel gets a published quantity derived from the ledger. You can hold back a buffer for a channel that is slow to update, or publish only a share of the stock to a channel with high return rates. What you never do is type a number into a seller portal by hand.
Where oversells actually come from
- A sale on one channel is not pushed to the others before the next sale lands. Sync frequency matters more than most people expect; a four-hour gap on a fast-moving part is enough.
- Supplier files that say “available” but mean “orderable”. Treat supplier availability as a separate field from your own on-hand quantity.
- Returns that are refunded but never checked back in, so the ledger drifts low and you stop selling parts you actually hold.
- Bundles and kits whose components are also sold individually, with no shared reservation.
A simple reconciliation routine
Before any automation, a weekly habit prevents most damage. Export the quantity each channel currently shows, compare it with the ledger, and investigate every difference larger than your tolerance. The table below shows the shape of that check with sample values.
| SKU | Ledger | Shop | Marketplace A | Marketplace B | Action |
|---|---|---|---|---|---|
| BRK-2210 | 14 | 14 | 12 | 14 | Marketplace A missed a receipt; republish. |
| FLT-0087 | 0 | 0 | 2 | 2 | Oversell risk; set both channels to 0 now. |
| LMP-5531 | 6 | 6 | 6 | 6 | In sync. |
What to automate first
Automate the publishing step, not the decisions. Push ledger quantities to channels on a schedule, reserve stock when an order arrives, and raise an alert when a channel rejects an update or a count drifts. Keep write-offs, adjustments and buffer rules as human decisions with a recorded reason. That order keeps the ledger trustworthy while removing the retyping that causes the errors in the first place.
This is the workflow the Stock and Sell modules are built towards: today Sell publishes supplier-derived quantities to Amazon.ca and eBay.ca daily, and the central ledger with recorded movements is in development. The principles apply whatever tools you use.
