Sync Inventory Across Marketplaces Without Cancellations

Why overselling turns into cancellations

When one unit is listed on three marketplaces, each channel only knows the quantity you last told it. If the unit sells on Amazon while Flipkart and Myntra still show it as available, the next order is one you cannot ship. You then cancel it, and the cancellation is usually attributed to you.

The usual causes are:

• Delayed sync: stock is updated hourly, daily or by manual file, while orders arrive every minute.
• No buffer: the full physical count is pushed to every channel.
• SKU mismatches: the same product has different codes on each panel and an update lands on the wrong listing.
• Returns restocked wrongly: units are added back before they are received or checked.
• Physical vs system gaps: shelf stock differs from what the system shows because of damage, mis-picks or unrecorded transfers.

Cancellation consequences differ by marketplace and change over time. They can include penalties, lower seller ratings or reduced listing visibility. Read the cancellation clauses in your seller agreement and each marketplace's current policy pages, and confirm the latest terms before you set targets.

Build one source of truth for stock

Marketplaces should receive stock numbers from your master record. They should not be where you work out the numbers.

1. Pick the master. This can be your ERP, OMS, WMS or a dedicated inventory tool. For a small catalogue, a tightly controlled sheet can work temporarily, but it will not keep up as order volume grows.
2. Create a SKU mapping table. Give every product one internal SKU and map it to each channel's identifier.
3. Freeze naming. Do not change SKU codes on a panel without updating the mapping first.
4. Define bundles. If a combo is built from single units, the combo's availability must be calculated from its components.
5. Run cycle counts. Count fast-moving SKUs more often and correct the master straight away.

Check each panel for the exact identifier names, as they can change.

Allocate stock and set safety buffers

Never push total stock. Push available-to-sell (ATS):

ATS = on-hand stock − units reserved for packed or pending orders − damaged or QC-hold units − safety buffer

You then have two allocation models:

• Shared pool: every channel shows the same ATS and the master reduces it after each order. This maximises sales but needs fast, reliable sync.
• Fixed allocation: you split ATS across channels based on recent sales share. It is safer for slower channels but can leave stock stranded on one channel.

Set buffers by risk, not by habit. Raise them for fast movers, for channels that update slowly, and before sale events. Your own order history should drive the numbers. Some teams cut a slow channel to zero first when ATS runs low, so the faster channels keep selling the last units.

If you use marketplace-fulfilled stock, keep it as a separate pool so units are not counted twice. Check the programme terms for how that stock is handled.

Set an update cadence for each channel

Find out how each marketplace accepts stock updates: API, bulk file upload or panel entry. Look at the seller help documentation or ask your account manager. Then match the buffer to the slowest method.

1. Trigger updates on events. Run an update after every new order, cancellation, return receipt, inward GRN and stock adjustment, not only on a timer.
2. Log every push. Keep a record of what was sent, when, and whether the channel accepted it.
3. Alert on failures. A failed sync should notify someone. It should never be silently assumed to have worked.
4. Plan sale events. Before a big sale, freeze allocations, widen buffers on hero SKUs and recount stock.
5. Reconcile daily. Compare the quantity shown on each panel with the master, and investigate any difference.

A channel that relies on manual or scheduled file uploads needs a bigger buffer than one that updates in near real time.

Count returns, RTOs and holds correctly

Returns can quietly distort stock in both directions. Add a unit back too early and you oversell. Never add it back and you understate stock and lose sales.

• Use statuses such as in transit, received, QC passed and sellable, and add to ATS only at the last one.
• Move damaged or unsellable items to a hold location that is excluded from ATS.
• Match RTO and customer-return receipts to marketplace return IDs, so missing or wrong items can be raised as cases.
• Record who restocked what and when, so a spike in cancellations can be traced to a restocking error.

Audit cancellations and related charges weekly

Prevention needs a feedback loop. Once a week:

1. Export cancellations from each panel and group them by reason and SKU.
2. Mark which were genuinely seller-fault (out of stock) and which were not, such as customer-initiated or logistics-related.
3. Compare the SKUs involved with your sync logs. Look for failed pushes, wrong mappings or thin buffers.
4. Check settlement reports for cancellation or penalty lines and compare them with your seller agreement or rate card. Confirm the terms are the latest ones.
5. Raise disputes where a cancellation was wrongly attributed or a charge does not match the agreed terms.

MarketplaceMetrics by Fundle reconciles marketplace sales and settlements, checks commissions and fees against agreed terms, and tracks returns and recovery cases. Myntra Excel reports are reviewed; other marketplaces are in scope discussion, so confirm coverage for your channels.