Operations · 2026

Operations

How to prevent overselling across Amazon and eBay (UK, 2026)

Overselling on Amazon can trigger A-to-Z claims and account health issues. On eBay it can affect seller metrics. Here's how to reduce the risk with a shared stock pool and sensible buffers.

10 min readIntermediateUpdated 11 July 2026

TL;DR

Use one shared stock pool across connected channels where possible, not static split allocation per marketplace.
Set any safety buffer from observed SKU velocity, replenishment and API behaviour.
Test connector timing, retries and reconciliation for each marketplace.
Document the safeguards available when demand exceeds update capacity.
Set an internal incident target from your own baseline and marketplace requirements.

Why this matters

Overselling can occur when reservations and channel updates are delayed or fail. Marketplace consequences depend on current policy and account context. A shared operational stock position, tested updates and visible recovery controls can reduce avoidable risk.

Goal of this playbook

By the end of this guide you will have documented stock ownership, buffers, connector tests and an incident-recovery process.

Before you start

You’ll need:

At least two active sales channels
An inventory platform whose shared-stock behaviour is documented
Access to connector logs, retry states or equivalent evidence
A reconciled starting stock count

The playbook

Move to a single stock pool for all channels

Scope-dependent

Avoid allocating stock manually per channel where possible. In MaxInvent this is the default — the product has one stock number and every channel sees it. If you're on another platform, look for a shared-stock or total-stock mode rather than static channel allocations. Static split allocation can leave stock stranded.

Static channel allocation can leave stock unavailable on one channel while it remains elsewhere.
Document reservation order and conflict handling rather than assuming first-arrival behaviour.

Set your safety buffer per SKU

SKU-dependent

A buffer is stock intentionally withheld from a channel. Set it per SKU using observed velocity, replenishment time, channel behaviour and acceptable oversell exposure, then account for stock withheld from sale.

Compare buffer scenarios using your own SKU-level order history.
Review both oversell incidents and lost availability when changing a buffer.
MaxInvent does not claim nightly generated buffer recommendations.

Pitfall

Don't set a global buffer. A 10% buffer on a £2 SKU with 1,000 stock wastes 100 units; a 10% buffer on a £200 SKU with 5 stock wastes £100.

Tighten your sync cadence

Connector-dependent

Record current connector timing, retry and reconciliation behaviour for representative SKUs. Marketplace APIs vary, so do not assume a universal interval or delivery time.

Poll-only (periodic push regardless of change) is often more resilient than event-only (push only on change) because it can recover from missed events.
A strong pattern is hybrid: event-driven push plus a scheduled poll as a backstop.

Test burst-demand scenarios

Scenario-dependent

A 'burst sale' is when a SKU sells faster than connected channels can process stock updates. Use observed velocity, API behaviour and available safeguards to set a risk threshold appropriate to your operation.

Identify the controls actually available for each connected channel.
Document the operational response when updates cannot keep pace with orders.

Build a same-day oversell recovery playbook

Documented process

Even with buffers and fast sync, the occasional oversell can still happen. Document a clear recovery flow: detect the issue, contact the buyer quickly, offer a suitable resolution, and follow each marketplace's seller guidance for cancellation or refund handling.

A quick, honest response can reduce the risk of poor feedback or marketplace escalation.
Use each marketplace's official cancellation and buyer-communication guidance.
Track oversells as a KPI. If the rate rises above your target, review buffers, sync cadence and affected SKUs.

Watch the metrics weekly

Agreed review cadence

Review actual mismatches, failed updates, cancellations and affected SKUs at an agreed cadence. Change buffers or connector controls only after reviewing the evidence and the effect on available stock.

How to know it worked

After following every step, you should be able to verify these outcomes:

Amazon Account Health dashboard shows no recent cancellation warnings related to stock-outs
eBay seller dashboard shows seller metrics within your target range
Your inventory platform's oversell count in the last 30 days is within your agreed target
Unexpected channel availability differences are investigated and documented

Frequently asked questions

How often should I sync stock across marketplaces?+

There is no universal interval. Test representative changes, API processing, retries and recovery for every required connector.

Is a 10% safety buffer enough?+

There is no universal buffer. Use your own SKU velocity, replenishment, channel behaviour and acceptable risk, and measure stock withheld from sale.

What's the difference between stranded stock and safety buffer?+

A safety buffer is stock you hold back intentionally to reduce oversell risk (e.g. 10% of 100 = 10 units held). Stranded stock is stock that's accidentally invisible to some channels due to split allocation (e.g. 30 on Amazon, 0 on eBay, 30 on floor = 30 stranded). Buffers are controlled and visible; stranded stock is uncontrolled and can lose revenue.

Does Amazon penalise us for cancelling an oversold order?+

Yes, cancellations can affect Amazon UK account health. The exact impact depends on Amazon's current policies and your account context. Overselling plus clear refund handling is usually less risky than shipping the wrong item or dispatching late, but always follow current marketplace guidance.

How do I handle an oversell on eBay?+

Use the marketplace's correct cancellation reason and avoid misclassifying the cancellation. Contact the buyer quickly, explain clearly, and offer a suitable resolution according to your customer-service policy.

Ready to run this playbook in MaxInvent?

MaxInvent is built for UK multi-channel commerce operations. One stock and order model connects supported channels, while eligible Temu sellers and orders can use Temu shipment creation and label retrieval in dispatch.

Talk to us See pricing

Playbooks are educational content. For tax, legal or regulatory questions (especially around VAT), always consult a qualified adviser.