People search "multichannel inventory sync" after the first double-sell. One unit, two buyers, one on Shopify and one on a marketplace, forty minutes apart. One of them gets a cancellation email, the marketplace logs a defect strike, and someone is told to find an app.
The app framing undersells the problem. Sync is not a feature you switch on. It is a distributed-systems problem wearing a retail apron: one source of truth, several readers, and delay on every hop. Once you see it that way, the failure modes stop being mysterious and start being designable.
The shape of the problem
Decide one thing first: which system owns the number. Shopify, the ERP, the 3PL's WMS, one of them is the ledger. Every other channel holds a cached copy that is stale by the age of its last update. Stores that cannot answer "who owns on-hand" in one sentence do not have a sync problem. They have several ledgers voting.
With an owner named, an oversell has exactly three causes.
Latency. Marketplace feeds and app webhooks update in minutes, not milliseconds. Two buyers inside one update window can both see the last unit. This risk only exists near zero stock, which is what makes it manageable.
Failed updates. A webhook drops, an API call rate-limits, a feed row errors. The channel keeps selling yesterday's number all day. This is the silent one, and it is why sync needs monitoring, not trust.
A wrong ledger. The owner itself does not match the shelf. Sync then distributes the error to every channel at high speed. Fix that in the ledger, not the pipes: that is the perpetual inventory discipline underneath this whole topic.
Buffers: the honest tool
You cannot buy zero latency. You can decide where an oversell is allowed to happen.
Set a per-channel reserve on risky rows: list on marketplaces at on-hand minus a buffer of one or two units. The buffer converts oversell risk into a small understatement of availability, and the exchange is almost always worth it, because a marketplace defect strike costs future ranking while a briefly hidden last unit costs one maybe-sale.
Size the buffer by row, not store-wide. Fast movers near reorder need one. Deep-cover rows need none; a buffer on 300 units of cover is superstition. This is the same per-row logic as safety stock, pointed at latency instead of lead time.
Watch what buffers cost, too. Reserved units on every channel add up to phantom unavailability: stock that exists but nothing can sell. If reserves hold back a meaningful share of sellable cover on rows that never spike, the buffers are eating more than the oversells did. The stockout rate read at channel level will show it as availability you cannot explain.
The reconciliation read
Sync failures hide because each channel looks plausible alone. They surface the moment you compare copies. Weekly, or nightly once it is scripted:
- Export on-hand per variant from the ledger owner.
- Export listed availability per variant from each channel.
- Diff them, allowing for deliberate buffers.
- Every unexplained gap goes on a list: variant, channel, direction, age.
- Chase the recurring rows. One channel always stale means a broken feed or dropped webhooks. One variant always wrong means a mapping issue, usually a SKU code that differs by a space or case between systems.
The diff also catches the mapping disasters that cause the worst oversells: two listings pointing at one bin, or a bundle listed as its own stock while components sell separately. No amount of latency tuning fixes a wrong mapping. Only the diff sees it.
Log the gaps over a month and you have the number that justifies or fires your sync app: unexplained divergence per channel per week, trending or not.
When to leave a channel
Multichannel is a multiplier on ops load, not just on demand. Every channel adds a copy to reconcile, a fee schedule, a returns flow, and a place your ledger's mistakes become public. A channel that adds single-digit revenue share while dominating the gap list and the cancellation count is not diversification. It is a tax with a dashboard. The diff read gives you the evidence to decide like it is a buy: contribution in, drift and defects out.
What's missing
This page can name the owner, size the buffers, and hand you the diff. It cannot run the diff nightly across your channels, age the gaps, or spot the variant that goes stale every Friday. That is your feeds and your history, compared continuously.
SkuSense is being built to run that comparison for Shopify brands: ledger versus channel copies, unexplained gaps flagged with age and direction, before the cancellation email writes the report for you.
Related: Perpetual inventory for ecommerce · Stockout rate in ecommerce · Safety stock and reorder points