Selling on several channels multiplies reach and also multiplies the ways stock counts can lie. A customer buys the last blue jacket on your Shopify store at the same minute that someone buys it on a marketplace. Both orders are real, one has to be cancelled, and the cancelled customer leaves a one-star review and a chargeback risk. Stores usually meet the problem as a trickle of cancellations, then conclude that overselling is just part of multichannel selling. It is not; it is a symptom of a design that lets several systems each believe they own the number.
This guide explains how to design inventory sync so that stock stays honest. It covers the source-of-truth decision, how updates should flow, the traps in timing and rate limits, buffers and reservations, bundles and locations, and the reconciliation routine that finds the drift that always happens. It builds on the stock layer described in how to automate a Shopify store and is the technical companion to our inventory sync service. Platform details change, so confirm the specifics in each platform’s current documentation.
Why counts drift
| Cause | What happens | Example |
|---|---|---|
| Latency | An update takes time to reach other channels | Sale on channel A at 10:00:00; channel B still shows stock at 10:00:20 |
| Race conditions | Two updates overwrite each other | Both channels set the total after their own sale, and one sale is lost |
| Failed calls | A platform rejects an update and nobody retries | Rate limit hit during a sale; the update is dropped |
| Manual edits | Someone changes stock in one place only | A warehouse correction typed into the store admin and nowhere else |
| Returns and cancellations | Stock comes back in one system and not the others | A cancelled order restocks on the store but not on the marketplace |
| Mapping errors | The same product has different identifiers per channel | A variant matched to the wrong SKU |
Almost every oversell traces to one of these six causes. The first two are inherent to any system with more than one place to buy, so the design has to expect them rather than hope to avoid them.
Decision 1: pick one source of truth
Choose a single system that holds the authoritative count for each product, and treat every other system as a follower. The source of truth is usually one of three things: your store platform, a warehouse or inventory system, or a dedicated multichannel tool. The right choice depends on where stock physically changes. If a warehouse system scans every receipt and pick, it should own the count. If the store admin is where you adjust stock by hand, the store owns it.
| Source of truth | Choose when | Watch out for |
|---|---|---|
| Store platform | One store plus a few channels, small warehouse | Marketplaces must read from it; manual edits happen here |
| Warehouse or inventory system | Barcode scanning, several locations, purchase orders | Needs reliable connections to every channel |
| Multichannel tool | Many channels, standard connectors | Another subscription and another thing that can fail |
| A spreadsheet | Very small catalogues, temporarily | No audit trail and easy to overwrite |
Write the decision down. A one-line statement for each product group, such as stock for all clothing is owned by the warehouse system, settles arguments when a number looks wrong.
Decision 2: send changes, not totals
The most common design mistake is to have each channel send the new total to the others. When two sales happen close together, each channel sets the total after its own sale, and whichever message lands last wins, erasing the other sale. The safer pattern is to send deltas: this channel sold one unit, this return added one unit. The source of truth applies each delta in order and publishes the resulting total back to the followers. Many platforms offer an adjust operation that changes a quantity by an amount rather than setting it, which is the right tool for this.
- Use adjust, not set, for routine sales, returns and receipts.
- Use set only for counts from a stocktake, where you deliberately replace the number.
- Give each change an identifier so that a retried message is not applied twice.
- Apply changes in order or make them commutative, so that late messages do not corrupt the total.
Decision 3: how updates travel
Updates can be pushed when something changes or pulled on a schedule. Pushing through events, such as webhooks from the store, is fast. Pulling on a timer is simple and tolerant of missed events. A robust design uses both: events for speed and a scheduled reconciliation as a safety net. Events can arrive more than once or out of order, so processing must be idempotent: applying the same event twice has the same effect as applying it once.
| Method | Strength | Weakness | Use for |
|---|---|---|---|
| Event push (webhooks) | Near real time | Can be duplicated or missed | Sales, returns, adjustments |
| Scheduled pull | Simple, catches missed events | Delay between runs | Reconciliation, small stores |
| Queue between systems | Retries and smoothing of bursts | More to build and monitor | Anything with several channels |
Rate limits, bursts and queues
A sale on a busy day can create hundreds of updates in minutes. Each platform limits how many calls you may make, and exceeding the limit causes errors. A queue sits between the source and each channel, takes updates as they arrive and sends them at a pace the target accepts, retrying failures with growing delays. Without a queue, the first burst drops updates and the counts drift on exactly the days when accuracy matters most. This is part of why jobs spanning several channels are often better built than stitched; see Zapier vs Make vs n8n for Shopify for how workflow tools differ in handling it.
Buffers and reservations
Even a good sync has a delay, so promising the very last unit on every channel invites an oversell. A buffer, also called safety stock, is a number of units you hold back from selling on slower or higher-risk channels. If the source shows three units, a marketplace with a slow sync might be shown one. You can set buffers by channel, by product velocity or by the cost of a cancellation.
| Channel type | Suggested buffer approach | Reason |
|---|---|---|
| Your own store | None or very small | Fastest and most controllable |
| Marketplaces with strict cancellation penalties | Larger buffer on fast sellers | A cancellation costs a rating or fees |
| Slow or batch-synced channels | Buffer equal to expected sales in the sync gap | The gap is where oversells happen |
| Wholesale or B2B portals | Reserve units for committed orders | Large orders can empty stock suddenly |
Reservations deal with items in a cart or on an unpaid order. Decide whether reserved stock counts as available, and for how long. A reservation that never expires will quietly hide stock, so give it a timeout.
Bundles, variants and locations
Complexity enters with products that are not one-to-one. A bundle of three items consumes one unit of each component, so selling a bundle must adjust three counts, and the number of bundles available is limited by the scarcest component. Variants need an unambiguous mapping between the SKU in each channel; a single wrong mapping sends an adjustment to the wrong colour. Several stock locations add another dimension: decide whether channels see the total across locations or only certain ones, and how fulfilment chooses the location.
- Bundles: compute availability from components and adjust every component on sale.
- Variants: keep one master mapping table of SKU to channel identifiers and check it on every new product.
- Locations: define which locations are sellable to which channels, and keep returns restocking to the right place.
- Pre-orders and backorders: mark them explicitly so that negative stock is intentional, not an error.
The daily reconciliation
Whatever you build, counts will occasionally drift, because platforms fail and people make manual edits. The control that makes this tolerable is a reconciliation job that runs daily, reads the count in the source of truth and each channel and compares them, allowing for buffers. It should fix small differences automatically where the rule is clear, and alert a person for large or repeated differences, naming the product, the channel and both numbers.
| Check | Action |
|---|---|
| Count differs by one or two units on one product | Correct from the source and log it |
| Count differs a lot, or on many products | Alert immediately; likely a failed sync or a bad mapping |
| A product exists in a channel but not in the source | Flag for review; possible mapping gap |
| Negative stock where it is not intended | Alert and pause sales of that product on slow channels |
| No updates received from a channel for a set time | Alert that the connection may be down |
A worked example
Imagine a store selling 200 orders a day across its own site and two marketplaces. Before a proper sync, it overwrote totals from each channel, and about one percent of orders, two a day, had to be cancelled for lack of stock. Each cancellation costs the order’s margin, around eight dollars of lost profit on average, plus ten minutes of staff time and a risk to the marketplace rating. After moving to deltas, a queue and a small buffer, cancellations fall to a handful a month. The saving is roughly sixty cancellations a month, about $480 in margin and ten hours of time, and the more valuable gain is the marketplace rating. These are illustrative figures; the point is that oversell costs are small each time and large in total, and that the fix is mostly design.
Mistakes to avoid
- No single source of truth. Two systems editing the same count will fight.
- Overwriting totals. Races lose sales.
- No retry or queue. Burst days drop updates.
- Ignoring returns. Stock that returns but is never restocked disappears from every channel.
- No reconciliation. Without it you learn about drift from angry customers.
- Mapping by title. Use stable identifiers such as SKU or barcode.
If you want this built and monitored, our inventory sync service starts from a stock ledger and one channel and grows to a full multichannel programme, with alerts on every mismatch. Marketplace-specific versions exist, for example inventory sync for Amazon sellers and for BigCommerce stores. Related reading: Shopify order automation rules for tagging orders that touch stock.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Shopify developer docs: inventory, how inventory is managed through the API
- Shopify developer docs: rate limits, how API limits affect bursts
- Shopify developer docs: webhooks, event delivery and retries