Merge duplicate products

When the same physical item exists under two SKUs, Product Merge folds one product into the other. The source product (the duplicate you want to retire) hands all of its transactional history — orders, stock movements, FIFO layers, returns, listings, accounting — to the destination product, and is then deleted. The destination keeps its own name, images, pricing, and categories; it simply inherits the source's records.

A merge is permanent — there is no undo. So the tool always makes you review a preview before anything happens: it spells out every record that will be moved, everything on the source that will be deleted, the stock quantity that transfers per warehouse, and any warnings or hard blockers. Read that preview carefully.

This guide covers both entry points (a single pair, or a CSV batch), how to read the preview, and what actually happens when you execute.

Before you begin

• You need write access to Products (the same access that lets you create and edit products — see Product permissions reference). There is no separate "merge" permission, but unlike importing the merge tool is available to anyone who can edit products, so treat it with care.
• Decide which SKU is the survivor. The destination is the product you keep; the source is the one that disappears. Getting these backwards deletes the wrong product's descriptive data.
• Make sure the source product isn't archived. An archived source is a hard blocker — unarchive it first.
• If you are cleaning up many duplicates at once, have your pairs ready in a spreadsheet so you can use the CSV path.

The five steps at a glance

Every merge — single or batch — moves through the same pipeline:

1. Choose the pairs (single SKU pair, or upload a CSV of pairs).
2. SKU validates the pairs and opens a merge session (cached for 2 hours).
3. You review the preview for each pair.
4. You confirm — the merge runs in the background job tray.
5. The source products are deleted and the destination caches refresh.

Option A — merge a single pair

1. Open the Product Merge tool and keep it on Single Merge.
2. Under Source SKU (will be merged away), search by SKU or name and select the duplicate you want to retire. You can also click the browse icon to pick from the full products list.
3. Under Destination SKU (will receive data), select the product you want to keep.
4. Click Validate & Preview. SKU checks that both SKUs exist and that they're not the same SKU, then opens the session and takes you straight to the preview.

If validation fails you see an inline error — the two most common are "SKU not found" (a typo, or the product was already merged away) and "Source and destination SKUs cannot be the same".

Option B — merge a batch from CSV

Use this when you have many duplicates to clear at once.

1. Switch the tool to Upload CSV.
2. Click Download Template. The template has exactly two columns: old_sku and destination_sku. (old_sku is the source that gets merged away; destination_sku is the survivor.)
3. Fill one row per pair — old_sku,destination_sku — and save the file as CSV.
4. Choose the file and click Upload & Validate.

SKU validates the whole file before creating the session and rejects it if any row is bad. A row fails when:

Problem	Message
A row has fewer than two columns	Invalid format. Expected two columns: old_sku,destination_sku
Either SKU doesn't exist	SKU not found: <sku>
Source equals destination on a row	Source and destination SKUs cannot be the same: <sku>
The same old_sku → destination_sku pair appears twice	Duplicate merge pair found: <sku> -> <sku>
No usable rows at all	No valid product merge pairs found in CSV

Fix the flagged rows and re-upload. On success you see how many pairs were validated; click Next: Preview to continue.

note

The upload validator only checks that each SKU exists and that the pair is well-formed. It does not check blockers like an archived source at this stage — those surface in the preview, and are enforced again when the merge actually runs.

Review the preview

The preview shows one expandable panel per pair, each headed with a status chip:

• Ready (green) — no warnings, no blockers.
• Warnings (amber) — the merge can proceed, but read the notes first.
• Blockers (red) — the merge can't run for this pair until you resolve the issue.

Each panel breaks down into three columns plus any warnings and blockers.

Data to be moved

Everything that will be repointed from the source to the destination — its transactional and integration history. This spans nearly thirty distinct record types, including:

• Sales order lines, sales credit lines, and any sales-order bundle references
• Purchase order lines and warehouse transfer lines
• Inventory movements, adjustments, assembly lines, allocations, and holds
• FIFO cost layers
• Product listings and blemished-product links
• Amazon records (FNSKU products, merchant-SKU mappings, FIFO layers and consumptions, pending inbound items, ledger discrepancies, auto-mapping logs, draft FBA inbound items)
• Return receipt lines and RMA lines
• Subscription editions, eBay product settings, and accounting COGS batches
• Non-conflicting product attributes (see below)

Data to be deleted

Everything owned by the source that's discarded rather than moved — because the destination already has its own:

• Product images, pricing, and supplier links (plus supplier inventory)
• Categories, tags, and notes
• Variations
• Benchmarks and reporting/profit rows
• Bundle-component records — both where the source is a bundle parent and where it's used as a component inside other bundles
• Conflicting attributes — any attribute the source shares with the destination (same attribute). The destination's value wins; the source's copy is dropped.

Inventory impact

A per-warehouse tally of the active stock quantity that will transfer with the source's movements. Each row shows a warehouse and the net quantity moving into the destination there. "No inventory to transfer" means the source has no active stock. This figure counts only active inventory movements — for how those roll up into stock on hand, opening balance, and FIFO cost, see View product stock and FIFO layers & COGS.

Warnings

Advisory notes that don't stop the merge. You will see a warning when the source:

• Has a different product type than the destination (type -> type)
• Has variations that will be deleted
• Is itself a variation of another product
• Has conflicting attributes that will be dropped in favour of the destination's
• Is used as a component in one or more bundles, or is a bundle parent — those component records will be deleted
• Carries a large volume of data (more than 100 sales order lines, or more than 50 FIFO layers) that will be moved
• Has active inventory allocations or holds that will move to the destination — worth confirming, since these represent committed or reserved stock (see Allocations & backorders)

Blockers

Hard stops. While any pair shows a blocker, Execute Merge stays disabled. The three blockers are:

• Cannot merge product into itself — source and destination resolve to the same product.
• Destination product does not exist.
• Old product is archived — unarchive before merging.

Resolve the blocker (usually: unarchive the source, or fix the pair) and start the merge again.

Execute the merge

1. From the preview, click Execute Merge. If any pair has a blocker the button is disabled and a banner explains why.
2. A confirmation dialog appears — "Are you sure you want to merge N product(s)? This operation is IRREVERSIBLE!" Confirm to proceed.
3. The merge is handed off to a background job. You are told it has started and that you can safely leave the page.
4. Track progress — and any per-pair failures — in the job tray ("Merge Products"). When it finishes you see how many pairs merged and how many, if any, failed.

What running in the background means

The merge doesn't run on the page request. It runs as a tracked background job so that a large batch (many pairs, each moving thousands of rows) can't time out mid-way. A few consequences worth knowing:

• Each pair is merged in its own database transaction. If one pair fails, it rolls back cleanly and the job moves on to the next — a batch can partially succeed. The job's completion summary lists which pairs failed and why.
• Blockers are re-checked server-side at execution time. The preview computes blockers for display, but the merge itself re-validates them (self-merge, missing destination, archived source) before touching any data. If the state changed after you previewed — for example the source was archived in the meantime — that pair is refused rather than merged.
• The session is cached for 2 hours. If you leave the preview open longer than that and then execute, the session will have expired ("Session not found or expired") — start again.

What a merge changes on each product

A concise map of where every record ends up:

On the source product	Outcome
Orders, credits, purchases, transfers	Moved to destination
Inventory movements, adjustments, allocations, holds, assembly lines	Moved to destination
FIFO cost layers	Moved to destination (before movements, to keep costing consistent)
Listings, blemished links, Amazon / eBay records, returns, subscriptions, accounting COGS	Moved to destination
Non-conflicting attributes	Moved to destination
Conflicting attributes (destination already has them)	Deleted (destination's values kept)
Images, pricing, supplier links & supplier inventory	Deleted
Categories, tags, notes, variations, benchmarks, reporting rows	Deleted
Bundle-component records (as parent and as component)	Deleted
The source product record itself	Deleted

On the destination product	Outcome
Its own name, images, pricing, categories, attributes	Kept unchanged — nothing is copied over except non-conflicting attributes
Inventory, average cost, snapshot, and profit-reporting caches	Refreshed after the merge so its new stock and cost reflect the moved records

The destination's descriptive data is never overwritten. A merge is additive on the destination (it gains history and non-conflicting attributes) and destructive on the source (it loses its own descriptive data and then ceases to exist).

Why you can't undo a merge

There is no reverse operation. Once records are repointed and the source is deleted, SKU has no record of which rows used to belong to the source, so it can't un-merge them. The only guards against a mistake are the ones before you execute: the preview, the disabled button when blockers are present, and the confirmation dialog. Treat "Execute Merge" as final.

If you are unsure whether two SKUs are truly duplicates, archive the one you don't want instead — archiving is fully reversible and keeps both products' data intact.

Next steps

• View product stock — confirm the destination's stock after the merge.
• FIFO layers & COGS — see how the moved cost layers value the destination.
• Archive, unarchive & delete a product — the reversible alternative when you're not certain.
• Review the Product Data Health dashboard — find duplicate and incomplete products to clean up.
• Import products from a spreadsheet — the other bulk product operation.

Video transcript

Product Merge folds one product into another. Under Single Merge, pick the Source — the duplicate you'll retire — and the Destination, which keeps its own name and inherits the source's records. You can also merge a batch from a CSV. Then click Validate and Preview. The preview spells out exactly what happens before anything runs, because a merge is irreversible. Data to be Moved lists every record that transfers to the destination, like these sales order lines; Data to be Deleted is what's dropped from the source; and the inventory impact shows stock moved per warehouse. Only then do you execute.