Why the same physical item ends up with a different name in every system, and what that costs you as you scale.
You sell one product. Somewhere in your business, that single product has quietly picked up five different product codes or SKUs.
On Shopify it is TSHIRT-BLACK-MEDIUM. In Unleashed it is TSHIRT-BLK-M. On Amazon it is a string of characters nobody chose and nobody can read. On eBay it is something else again, and in the warehouse system it is a code from a supplier you stopped using two years ago.
Five names. One item on a shelf. And every one of your systems believes it is looking at a different thing.
For a while, this does not matter. Then it matters a lot.
Early on, someone on the team simply knows that the Amazon code maps to the internal one. It lives in their head, or in a spreadsheet, and it works. Then you add a channel, then a warehouse, then a 3PL. then someone leaves. The knowledge that held it all together was never written down anywhere a system could use, and the cracks start to show.
If your team is reconciling stock by hand at month end, if you have oversold an item that your reports swore was in stock, or if you are finding “ghost” inventory that exists in the warehouse but in none of your channels, this is very likely the reason. It is worth understanding what is actually happening underneath, because it is fixable, and the fix is not more spreadsheets.
The technical bit (worth forwarding to whoever runs your systems)
Here is the mechanism, in plain terms. The problem has a name: SKU mismatch. It happens when the same physical product is represented by different identifiers across your channels, marketplaces, warehouses and ERP. At low volume it is an inconvenience. At scale it becomes structurally dangerous, because your systems have stopped sharing a single, agreed identity for each product.
Why one product ends up with five names
Channel-specific SKUs are identifiers created for a particular marketplace rather than your canonical internal product code. They multiply for reasons that are all individually sensible:
Marketplaces impose their own SKU rules and uniqueness constraints. Legacy systems were set up independently, at different times, by different people. Products get re-listed over time and pick up new codes. Multiple fulfilment models coexist. Different teams own different channels. And acquisitions or migrations quietly import whole duplicate catalogues. None of these is a mistake exactly. Together they mean no two systems agree on what to call the same box.
The same t-shirt, seen by each system:
| System | SKU it uses |
|---|---|
| ERP (Unleashed) | TSHIRT-BLK-M |
| Shopify | TSHIRT-BLACK-MEDIUM |
| Amazon FBA | X001ABCD12 (FNSKU) |
| eBay | BLKTS-M-2026 |
| Warehouse system | APP-4432 |
How the sync logic actually fails
Inventory sync is the first thing to break. Shopify decrements stock against its SKU. Amazon decrements against a different one. Unleashed only recognises the canonical code. So a sale on one channel never reaches the count on another. One channel still shows stock that is physically gone, and you oversell. At a small scale that is an apology and a refund. At scale it is marketplace penalties, breached fulfilment SLAs, and ad spend burned on items you cannot ship.
Duplicate inventory pools are the more expensive failure. When two channels treat their SKUs as unrelated products, your software fragments one physical pool into several imaginary ones. You can be holding 500 units in a single bin while your systems report zero available on Channel A and zero on Channel B. That triggers false stockouts, unnecessary purchase orders, and stranded cash, all against stock you already own.
Fulfilment routing fails the same way. A warehouse maps SKU-RED-M correctly, an Amazon order arrives as REDMEDIUM2026, the routing logic cannot match it, and the order drops into an exception queue for a human to fix. One or two of those is nothing. During Black Friday or a seasonal peak, the exception queue becomes the bottleneck that defines your week.
The damage you do not see until later
Reporting corrupts silently. Analytics depend on SKU normalisation, so without it your revenue splits across duplicate products and your true demand hides in plain sight:
| SKU in the report | Units sold |
|---|---|
| TSHIRT-BLK-M | 500 |
| TSHIRTBLACKMED | 400 |
| AMZ-BLK-MEDIUM | 700 |
Real demand is 1,600 units. Your forecasting, your purchasing and your supplier conversations are all working from a number that is wrong, and nothing on the screen tells you so.
Returns are the other quiet drain. Amazon may send back an FNSKU or an ASIN while your ERP expects the internal SKU only. Nothing matches automatically, so refunds are delayed, write-offs go in wrong, and inventory gets recorded as “lost” when it is sitting on a returns shelf. At volume, that stops being an operations annoyance and becomes an accounting problem.
Harry from TIDE: I work with an FMCG wellness brand who use SKU Mapping to great effect. They sell huge volumes on Amazon using both Fulfilled-by-Amazon (FBA) and Fulfilled-by-Merchant (FBM) channels, where a single product needs a different SKU code for each. The issue? Unlike with FBA, FBM-specific SKUs do not exist in their inventory management system, meaning FBM orders were unable to sync across, and so the stock impact is not recorded. This was causing inventory mismatches across their other channels sales, and deflating their product performance reports. This meant many hours per week were spent manually updating stock levels and reconciling finances. Now, TIDEConnects takes the pain away with its SKU Mapping feature – SKUs are automatically converted to their canonical version whenever a sale, fulfilment, or stock update is synced across
Why it always gets worse, never better, on its own
The thing that makes this dangerous is that it compounds. A business with 200 SKUs, two channels and one warehouse can run on informal knowledge indefinitely. A business with tens of thousands of SKUs across a dozen channels, several warehouses, and FBA plus a 3PL cannot. Every new channel, warehouse or fulfilment model multiplies the number of places two identifiers can drift apart. The cost does not rise in a straight line. It rises with the connections between systems, which is far faster.
Put plainly: SKU mismatch is an identity problem wearing an inventory problem’s clothes. The physical product is singular. The software’s picture of it is fragmented. Until something enforces a single identity, every workaround you add is another spreadsheet, another manual check, another thing that breaks when the person who understood it is on holiday.
How TIDE fixes it
TIDE puts an identity layer between your channels and Unleashed, so every system finally agrees on what each product is. Three things happen underneath:
It enforces a canonical product identity, so one physical item has one true code that everything else answers to. It translates channel-specific identifiers, mapping Amazon’s FNSKU, Shopify’s SKU and your warehouse code back to that single canonical product automatically, in both directions. And it synchronises inventory centrally, so a sale on any channel updates the real count everywhere, in near real time, with no one re-keying anything.
The result is the thing you actually wanted: one honest view of stock across every channel, orders that route themselves, reports that show real demand, and returns that reconcile on their own. The manual translation layer, the person quietly holding it together, is no longer load-bearing.
Harry from TIDE: The issue caused by mismatched SKUs is that sales cannot sync to inventory management, so the impact on stock and cost of goods sold is not recorded. For high-volume sellers, this can mean several hours per week making manual changes. SKU Mapping in TIDEConnects takes this pain away, by automatically swapping the temporary SKU with the real, canonical SKU whenever a sale, fulfilment, or stock update is synchronised.
How to tell if this is already happening to you
You probably do not need to audit your systems to know. The symptoms are familiar: unexplained overselling, ghost stock, the same product showing up as duplicates in reports, warehouse exception queues, marketplace availability that never quite matches, inventory adjustments nobody can fully explain, and returns that will not match automatically. If a spreadsheet is currently doing the job an identity layer should be doing, you have the problem.
If this sounds familiar
If your business is growing and the operational strain is showing up faster than your order numbers explain, it is usually worth looking at how your systems are actually connected, and whether they agree on what your products are.
A short conversation is normally enough to spot where identities are drifting apart and what a cleaner setup would look like. If that would help, you can book a 15-minute operations review and we will walk through your current stack together.
Book a 15-minute operations review: https://calendly.com/harry-perkin-tide/15-minute-review-via-website
TIDE connects eCommerce platforms and operational systems so orders, stock and fulfilment run automatically. We work with growing product businesses using Unleashed or similar ERPs as their inventory backbone.
Read more about TIDE’s Unleashed integration functionality here