SKU-based inventory pools stock across every variant that shares a SKU. Here's how the pool works, how to enable it, and what to check before you switch.
Every SKUSavvy company runs in one of two inventory modes:
Variant-based (the default): each product variant tracks its own inventory independently, even if two variants happen to share a SKU.
SKU-based: every variant that shares a SKU (case-insensitive) is merged onto one shared inventory pool. Stock counts, bin locations, unit costs, barcodes, lots, and replenishment rules are all tracked once, on the pool, instead of once per variant.
SKU-based mode is opt-in and company-wide — it's not the default, and it isn't something Shopify or individual products toggle on their own. An account owner turns it on once for the whole company (see How to Enable It below).
Store A's count: 40 → 35 (−5 units)
Store B's count: 25 — unchanged, because nothing connects them
Shared pool: 65 → 60 (−5 units, locked at the database row so a same-instant sale on Store B can't double-spend it)
Outbox worker pushes the new count to every sibling store within seconds
The pool isn't limited to identical SKU strings — different SKUs and bundles across storefronts can still draw from one shared shelf.
The picker's ticket shows one bin and one quantity — never a channel-specific SKU
A bundle sale on Store C decrements the pool by 3 units, same as three single-unit sales anywhere else
Aggregated instead of siloed, the same demand signal feeds cost, lead time, and reorder math — for every storefront at once.
Landed cost, lead time, and reorder math are computed once from the full pooled signal — not estimated per storefront and reconciled by hand
Switching a company from unique to sku_based mode is a one-way,
owner-only action: existing duplicate-SKU items are merged in the background using a
sum or max quantity strategy, and Shopify → SKUSavvy inventory
pulls are disabled afterward since SKUSavvy becomes the single source of truth.
SKUSavvy tracks physical stock on an InventoryItem, not directly on the variant. In variant-based mode, every variant gets its own InventoryItem — a 1:1 relationship, so it looks and behaves like stock lives on the variant. In SKU-based mode, multiple variants can point to the same InventoryItem whenever they share a SKU. That shared InventoryItem holds the barcodes, unit costs (one per vendor), bin locations, and the actual on-hand/available quantities — all of it consolidated in one place instead of duplicated per variant.
If multiple Shopify stores are connected to your company, SKUSavvy manages one global level per SKU across all of them. When stock is committed or released on Store A, the change fans out to every other variant sharing that SKU, on Store B, C, and beyond. New products imported from Shopify automatically join the shared pool the moment their SKU matches an existing one. Because that pool is shared, SKUSavvy also guards against double-counting on import: once a shared pool already has a quantity recorded in a given warehouse, later Shopify imports for other variants pointing at that same pool skip re-adding stock to that warehouse, so the same physical inventory never gets counted twice under one pool.
Bin transfer and purchasing replenishment rules run against the pooled SKU, giving you one accurate sales-velocity signal instead of one per variant. Kit recipes reference a component's SKU rather than a specific variant — the system pulls from whichever shared pool matches. Barcodes are attached to the InventoryItem: when a picker scans one, SKUSavvy resolves the physical item by SKU first, then figures out which order/variant it applies to, which is what makes the same physical item sellable under multiple listings without duplicate-barcode conflicts.
When two variants' inventory is merged onto one shared pool, it isn't only the stock count that combines. Lot and serial numbers, cycle count history, replenishment rules, and existing bin assignments all carry over onto the shared item as well, so nothing is left behind on the variant that gets folded in. If a kit recipe's components all collapse into the very same shared item as a result of a merge, that kit no longer represents a real bundling relationship and is automatically removed rather than left behind as a confusing single-item "kit."
Once SKU-based mode is on, SKUSavvy stops accepting inventory-level changes made directly in Shopify — SKUSavvy becomes the sole source of truth and pushes levels out to every connected store instead of pulling them in. This is enforced by the platform, not a setting you can toggle back per-store.
Switching to SKU-based inventory is done once, for the whole company, from Company > Owner Actions. Only the account owner (or a SKUSavvy super user) can make this change.
Go to Company > Owner Actions and find the Inventory Mode card — it explains that your account currently uses unique (variant-based) inventory mode.
Choose a Quantity Merge Strategy for how quantities combine wherever variants already share a SKU: Sum adds the merged variants' quantities together; Max keeps only the highest quantity found among them.
Confirm the switch. SKUSavvy queues a background job to merge your catalog onto shared inventory pools — for a large catalog this can take several minutes to finish.
This switch is one-way
You can switch from unique to sku_based mode. There is no supported path back. Once the merge runs, the Inventory Mode card disappears from Owner Actions because there's nothing left to switch — audit your catalog first (see below) rather than treating this as reversible.
A quick-reference list before you decide to switch, plus what to expect afterward:
SKU-based mode treats any two variants sharing a SKU as the same physical item — that's the whole point of the pool, but it means an accidental duplicate SKU on two genuinely different products will merge their inventory together the moment you switch. Review your catalog and make sure every physically distinct item has its own unique SKU. Fixing duplicates now is far easier than untangling a merged pool afterward.
There's no supported path back to variant-based mode once you switch. The merge itself runs in the background and can take several minutes to finish on a large catalog — your data isn't at risk, but don't expect it to be instant.
SKU-based mode is opt-in. If you never switch, your account keeps working exactly as it does today — every variant tracks its own inventory independently, and none of the pooling, one-way Shopify sync, or SKU Mismatches behavior described in this guide applies.
Once you're on SKU-based mode, SKUSavvy becomes the sole source of truth for inventory and only pushes levels out to Shopify — it no longer pulls inventory-level changes in from Shopify. This is a platform rule, not a per-store setting you can turn back on.
Renaming a SKU in Shopify can leave a variant out of step with its pool. SKUSavvy re-checks for this automatically every few hours and merges anything that newly matches, so most drift needs no action from you — cases that do need a decision surface on the SKU Mismatches page (see below).
If you ever need to unlink a variant from a shared pool (from the SKU Mismatches page), SKUSavvy blocks the split while that stock is reserved by an active pick batch. Finish or cancel the batch first, then unlink.
Once SKU-based mode is on, a new Company > SKU Mismatches page appears. It exists because a variant's SKU can drift away from its pool after the initial merge — most commonly when a SKU is renamed in Shopify on a variant that isn't the pool's original owner. SKUSavvy doesn't silently re-merge a drifted variant; it leaves the mismatch for you to review here instead.
A background job re-checks for drift and merges any newly-matching SKUs automatically every few hours, so most drift resolves itself without any action from you.
For cases that need a decision, use SKU Mismatches to resync a variant back onto the correct pool, or unlink it into its own inventory item if it turns out it was never the same physical product.
Unlinking a variant is blocked while its stock is reserved by an active pick batch — finish or cancel the batch first.
Yes. The merge combines your existing stock levels onto the new shared inventory items using whichever Quantity Merge Strategy you chose (Sum or Max) — nothing is lost or reset.
They'll be merged into the same inventory pool, since SKU-based mode has no way to tell them apart. This is exactly why the pre-switch SKU audit matters — fix accidental duplicates before enabling the mode, not after.
Yes, in one specific way: SKUSavvy stops accepting inventory-level changes made directly in Shopify and becomes the sole source of truth, pushing levels out instead. Everything else about your Shopify connection — orders, products, fulfillment — is unaffected.
Historical purchase orders and fulfilled orders stay exactly as they were — your past reports and cost data don't change. Going forward, new purchase order lines, picking, and fulfillment resolve to the shared inventory item by SKU instead of the variant.
No. The switch to SKU-based mode is one-way — there's no supported path back to variant-based mode once your catalog has been merged.
Questions before you switch, or need help resolving a SKU mismatch? Reach out to our support team or create a ticket in the platform.
In SKU-based mode, inventory is pooled by SKU — but an individual variant's SKU can drift out of sync with its pool later, for example after an edit in Shopify. When that happens the variant shows up as a mismatch. Go to Products > SKU Mismatches to review them (only shown once you're in SKU-based inventory mode).
Most mismatches resolve themselves: an automatic resync runs every 4 hours and fixes the simple cases — a pool with only one variant left, or a pool where every variant already agrees on the new SKU. What's left on this list are mixed pools, where siblings disagree, and those need a manual decision. Click Resync Now to re-run the automatic pass early if you don't want to wait.
1) Expand a mismatched variant to see its pool
2) Choose a Destination: create a new inventory item, or move to an existing one
3) Check which barcodes and quantities should move with the variant — anything you leave unchecked stays behind with the other variants in the pool
4) Confirm the move
Moving a variant doesn't delete or empty the original pool — it's left in place for the siblings that remain, still holding whatever barcodes and quantities you didn't check.