eBay Amazon Inventory Management: Fixing Sync Lag Oversells

What breaks first when eBay and Amazon share one stock pool

eBay Amazon inventory management fails at the seam between two systems that were never designed to agree with each other. Each marketplace keeps its own quantity field, its own order feed and its own idea of what “in stock” means, and neither one talks to the other directly. The moment you sell the same physical unit on both, you’re relying on a third system — a sync tool, a script, or a person checking a spreadsheet — to keep them honest.

At $3M to $30M in revenue, most brands have already outgrown the point where a person can do that reconciliation reliably. Order volume is high enough that a missed sync cycle produces a real oversell within hours, not days, and the SKU count is wide enough that nobody can eyeball a discrepancy. This article is for that operator: running Shopify Plus or a comparable paid platform as the core store, selling the same catalogue on eBay and Amazon as secondary channels, and looking for the actual mechanics of keeping stock counts honest rather than a product pitch.

The proprietary detail most guides skip is this: overselling is very rarely caused by a sync outright failing. It’s caused by the sync working exactly as configured, on a schedule that’s too slow for how fast the SKU sells, with a buffer that was never sized for that speed. Fix the buffer and the interval together, and most of what looks like a software problem disappears.

What eBay Amazon inventory management needs before you start

Before you touch a setting on either marketplace, get three things straight, because every step after this assumes they’re already true.

One source of truth. Pick the system that holds the real, physical stock count — usually your ecommerce platform, a dedicated inventory system, or your warehouse management software. Every other system, including eBay and Amazon, becomes a mirror of that number, never an independent record of it. If two systems can both be edited directly, you no longer have one stock pool; you have two ledgers that will drift apart, which is exactly the failure mode this article exists to prevent.

A SKU on every listing, on every channel, that maps to something. Not necessarily the same string as your internal SKU — eBay and Amazon both let you assign your own identifier per listing — but every one of those channel SKUs needs to resolve, unambiguously, to one row in your source system. A listing without a mapped SKU is a listing your sync tool can’t touch safely.

A connected account with the right permissions on each side. eBay’s developer platform and Amazon’s Seller Central both gate inventory and order access behind an authorised application; whichever multi-channel tool or custom integration you use needs that authorisation granted before anything else works. Check the current scopes required in each platform’s own developer documentation before you build against it, because these change and a guide written today can be wrong by the time you read it.

With those three in place, the actual setup is six steps.

Map every SKU to one canonical identifier

Start here, not with the sync settings, because every later step depends on this mapping being right. Build a table — inside your inventory tool if it has one, in a spreadsheet if it doesn’t yet — with one row per physical product and a column for your internal SKU, your eBay listing SKU, and your Amazon seller SKU (which is a separate field from Amazon’s own ASIN).

The mistake that causes the most damage here is assuming a SKU is unique just because it looks unique. Variants are where this goes wrong: a T-shirt in three sizes might share one parent listing on Amazon with child ASINs per size, while the same product sits as three entirely separate listings on eBay. If your mapping table treats the parent Amazon listing as one row, but eBay needs three, your sync tool will either double-count or silently drop two-thirds of the variant’s stock. Map at the level each channel actually sells at, which for variants means per-size, per-colour, per-bundle — not per parent product.

Rebuilding this table isn’t a one-off. Every new product launch, every retired SKU and every bundle change needs a mapping entry before it goes live on either channel, or the sync tool will either ignore the new listing or, worse, map it to the wrong row and push another product’s stock count onto it.

Set your sync interval and know its real lag

Every multi-channel inventory tool has a setting, usually named something like “sync frequency” or “update interval,” that controls how often it pulls order data and pushes quantity updates. Whatever number that setting shows, the real lag is longer than it, and you need to know by how much before you can size a buffer against it.

The stated interval is when the sync starts. It isn’t when the new quantity is live on the other channel. Between the interval firing and the updated number actually being visible to a buyer on the second marketplace, you’re also waiting on: the time to pull the order that triggered the change, the time to recalculate available quantity, the time to push that number to the second channel’s API, and that channel’s own processing time before the listing reflects it. On a fast, healthy connection this whole chain might complete in well under a minute. Under load, during a flash sale, or when either marketplace’s API is degraded, it can stretch far longer, and neither marketplace publishes a guaranteed ceiling on that stretch.

Treat the sync interval as the floor of your lag window, never the whole of it. If you don’t already know your tool’s actual end-to-end lag, the way to find out is to place a deliberate test order on the faster-selling channel during a normal trading hour and time how long the second channel’s listed quantity takes to move. Do this more than once, at different times of day, because API load varies and a single sample will understate the worst case.

Build a safety buffer per channel, not one global number

This is the step most teams get wrong, and it’s worth walking through the mechanics rather than just naming it.

A safety buffer is stock you deliberately withhold from what a channel is allowed to sell. If you hold 60 physical units of a SKU, a channel might be told only 54 are available, with 6 held back as buffer. The buffer exists to cover the sync lag: if both eBay and Amazon are told the full 60 is available, and both sell during the lag window before either sync fires, you’ve sold 61st and 62nd units that don’t exist.

Here’s an illustrative, hypothetical example, not a rule to copy: say a SKU sells roughly 12 units a day across both channels combined, and your measured sync lag is around four hours. Four hours is one-sixth of a trading day, so a rough buffer to cover that lag would be one-sixth of the daily sell-through — about 2 units — held back from what’s listed as available. That’s the shape of the calculation: buffer size scales with sell-through rate and with lag, not with a fixed number you set once and forget.

The mistake most operators make is setting one buffer, as a flat unit count or flat percentage, across every SKU and both channels. A slow-moving SKU with a buffer of six units is holding back stock it’ll take weeks to need. A fast-moving SKU during a promotion, with the same six-unit buffer, will blow through it in hours and oversell anyway. Buffer per SKU, and recalculate it whenever a SKU’s sell-through rate changes meaningfully — a promotion, a seasonal spike, a competitor going out of stock — not on a fixed schedule.

The second mistake is buffering identically on both channels when their lag isn’t identical. If your tool syncs to Amazon faster than it syncs to eBay, eBay needs a wider buffer to cover its longer lag, even though it’s selling the same physical stock pool.

Configure the quantity rule on each marketplace listing

With the buffer sized, the setting that enforces it lives on each marketplace separately, and the two platforms don’t expose it identically.

On eBay, the field is the listing’s quantity available, set either manually per listing or, if you’re using a multi-channel tool, pushed automatically from that tool’s calculated available-to-sell number. On Amazon, the equivalent is the available quantity in Manage Inventory, and if any of the SKU is fulfilled by Amazon, that pool is tracked separately from merchant-fulfilled stock inside Amazon’s own systems — the two don’t automatically net against each other in your external buffer calculation unless your inventory tool is explicitly configured to treat FBA and merchant-fulfilled units as one combined pool.

That FBA distinction catches more sellers than any other setting in this list. If ten units of a SKU sit in an Amazon fulfilment centre and forty sit in your own warehouse for eBay and Shopify orders, your source-of-truth system needs to know these are two physically separate pools with two separate depletion paths, even though they’re the same product. A sale on eBay depletes only the warehouse pool. A sale through Amazon Prime depletes only the FBA pool. Treat them as one combined number and you’ll either oversell the FBA side while warehouse stock sits untouched, or block eBay sales while FBA units you can’t quickly access still show as available elsewhere.

Route every order back to one ledger before the next sync

Once an order lands on either channel, it needs to hit your source-of-truth ledger before the next sync cycle runs, or that cycle will push a stale quantity back out and undo the deduction the order should have caused.

This is where order feed timing matters as much as inventory sync timing. Most multi-channel tools pull orders on their own schedule, separate from the inventory push schedule, and if those two schedules aren’t aligned, you get a window where an order has been placed but not yet deducted, and the inventory push runs during that window using the pre-order count. Check whether your tool runs order import and inventory push as one combined job or as two independent schedules — if they’re independent, the safer default is to trigger the inventory push immediately after every order import completes, not on a separate timer.

Set alerts for a stalled sync, not just a failed one

A sync that returns an error is easy to catch — most tools surface a failure notification, and most operators already have one configured. A sync that runs, reports success, but hasn’t actually updated in hours because of an authentication token that quietly expired, an API rate limit being hit, or a webhook silently dropping is far more common and far harder to notice, because nothing looks broken from inside your dashboard.

Set an alert on sync staleness, not just sync failure: if the last successful, verified update for any channel is older than roughly two to three times your normal sync interval, that’s worth a notification even though the tool itself hasn’t logged an error. This is the alert most eBay Amazon inventory management setups skip, because it requires checking a timestamp against an expectation rather than just watching for a red status light, and it’s the one that would have caught most of the real-world oversell incidents that get blamed on “the sync going down.”

The step most teams get wrong

If there’s one sentence to take from this article, it’s this: teams size their buffer once, at setup, and never revisit it. A buffer that was correct for a SKU selling five units a day is dangerously undersized the week that SKU runs a promotion and starts selling thirty, and it stays undersized until someone notices the oversells and traces them back to a number nobody has looked at in months.

Buffer review needs to be a recurring task, not a launch-day setting. Tie it to whatever already triggers sell-through changes in your business: a promotion calendar, a seasonal planning cycle, a new marketing channel going live. The buffer isn’t a security setting you configure once; it’s closer to a pricing rule that needs revisiting whenever the conditions it was built for change.

How to verify the setup is actually holding

Don’t wait for an oversell to find out whether this is working. Verify it directly, on a recurring cadence, with three checks.

First, pick a handful of SKUs — a mix of fast and slow sellers — and compare the quantity shown on eBay, the quantity shown on Amazon, and the true count in your source system, all at the same moment. They should differ only by the buffer amount you’ve deliberately set, never by more.

Second, place a real order on your faster channel and time how long the second channel’s listing takes to reflect the deduction. This is the same test used to measure lag in the sync-interval step, but running it periodically catches lag that’s crept up as order volume has grown, rather than staying at whatever it measured on day one.

Third, review your sync tool’s error and staleness logs weekly, not just when a customer complains about an oversold order. A pattern of near-miss staleness alerts that resolve on their own is an early warning that your sync infrastructure is under more load than it was sized for, well before it produces an actual customer-facing failure.

What does inventory management software for eBay and Amazon need to do that a spreadsheet can’t

A spreadsheet can hold a SKU mapping table and a manually updated stock count, and for a genuinely small catalogue with low order volume and a disciplined manual process, that’s sometimes enough. What it structurally cannot do is enforce a buffer automatically at the moment an order lands, detect a stalled sync on its own, or push a quantity change to two marketplace APIs within a lag window measured in minutes.

Purpose-built multi-channel inventory software — tools such as Linnworks, ChannelAdvisor or Extensiv, among others — exists specifically to run the sync loop automatically: pull orders, deduct against the source-of-truth ledger, recalculate available-to-sell per channel including the buffer, and push the result back out, all without a person triggering each step. What it can’t do for you is decide the buffer size, get the SKU mapping right the first time, or notice a business reason a buffer needs to change — a competitor stock-out, a viral moment, a planned promotion. The software runs the mechanism; the buffer strategy and SKU discipline are still your call.

Who should not build this themselves

If you’re running fewer than a few hundred live SKUs across both channels, with order volume low enough that a person can reconcile stock counts by hand within a day, a fully automated multi-channel sync tool is probably more infrastructure than the problem justifies. A disciplined manual process — one person, one spreadsheet, one fixed reconciliation time each day — can genuinely outperform a poorly configured automated tool at that scale, because the failure modes above only bite once volume and SKU count get high enough that nobody can hold the whole picture in their head.

This article also isn’t written for a brand below the roughly $3M revenue mark, or one running on a platform without the API access a real sync integration needs. Below that floor, the fix is almost always process discipline, not another tool. Above it, and especially once you’re managing more SKUs than one person can mentally track, the mechanics in this article stop being optional and start being the difference between a channel that scales and one that generates a support ticket every time a promotion runs.

What happens when eBay and Amazon disagree on your stock count

Eventually, despite correct buffers and a working sync, the two channels will show different available quantities for the same SKU at the same moment. This isn’t necessarily a bug. It usually means the sync interval on one channel is genuinely different from the other, one channel’s most recent order hasn’t been imported yet, or a manual edit was made directly on a marketplace listing rather than in the source system.

Diagnose in that order: check the last successful sync timestamp on each channel first, because a stale sync on one side explains almost every apparent disagreement. If both timestamps are current, check for a manual override — someone editing a listing’s quantity field directly on eBay or Amazon, bypassing the sync tool entirely, which is the second most common cause and the hardest one to spot because the sync tool has no way of knowing the edit happened outside its own process. If neither explains it, go back to the SKU mapping table from step one; a listing that’s drifted to point at the wrong internal row will show a persistent, unexplained disagreement that no amount of resyncing fixes, because the sync is faithfully reporting the wrong product’s count.

Keeping eBay and Amazon inventory synced against one real stock pool is, underneath the marketplace-specific settings, an ops automation problem: it’s about the reliability of a data pipeline crossing two systems that don’t share a source of truth by default, and about catching the failure mode — a stalled sync, a stale buffer, a broken mapping — before a customer does. That’s the scope Pointerflow’s ops automation work covers: building and monitoring the pipeline itself, not just picking a tool off a shelf and hoping the defaults hold at your order volume.