Why your inventory never matches across channels without a unified catalog

Your inventory never matches across channels because each marketplace keeps its own version of the same product and nobody keeps them in sync. Without a unified catalog telling Amazon, MercadoLibre, Shopify and your 3PL that a given SKU is one single product with one single pool of stock, each platform deducts units from a number only it knows about. The result is always the same: you sell in two channels what you only had for one, or you leave stock switched off on one side that you actually have available on another. The number doesn’t match because, technically, you’re running three or four separate inventories that happen to share physical product.

The root of the problem isn’t that you’re short on units, it’s that you’re missing a common identifier. When you list the same knee brace on Amazon as B0XXXXX, on MercadoLibre as MLM-123456 and on Shopify under a different handle, to your systems those are three unrelated products. Each one has its own stock counter, its own price, its own listing. No piece of software knows, by default, that when you sell one on Amazon it should subtract one from the same tank that feeds MercadoLibre. You’re the one holding that relationship together, by hand, in your head and in a spreadsheet that was already out of date the moment you saved it.

A unified catalog solves exactly that: it’s a layer above the channels where each product exists once, with its master identifier, and connects from there to its listing on every marketplace. When the catalog is the source of truth, a sale on any channel deducts from the same pool and the number you see is the same no matter where you look. Without that layer, the mismatch isn’t an error you can fix once: it’s the natural state of having the same product living in silos that don’t talk to each other.

what it means for the same product to live in silos

Picture 100 units of a product in your warehouse, sold across three channels. Without a unified catalog, what you’re really doing is deciding how many of those 100 you “promise” to each platform. You give 40 to Amazon, 40 to MercadoLibre and 20 to Shopify. Each platform believes that number is its full inventory and deducts from it based on its own sales. But the 100 physical units are the same units, and none of the platforms knows the other two exist.

From there, everything drifts in two directions. If you over-allocate to avoid leaving sales on the table —you give 100 to every channel—, you sell 100 on Amazon and 100 on MercadoLibre and suddenly you owe 200 units you don’t have: overselling, cancellations, penalized accounts. If you under-allocate to play it safe —30 per channel—, you leave 10 dead units nobody can sell and switch off listings that could be earning. Manual allocation always loses on one side or the other, because you’re guessing how a demand that shifts every day will distribute itself.

The silo isn’t only about stock. It’s about the whole product. The title you optimized on Amazon never made it to MercadoLibre. The price change you made Friday on Shopify wasn’t replicated. The new photo landed on one channel while the others still show the old one. Every edit you make in one place becomes a pending task everywhere else, and since nobody coordinates them, your listings diverge until the same product looks like three different products with three different prices.

Glossary: a unified catalog is the layer where each product exists once with its master identifier and links from there to its listing on every channel; it’s what lets a sale on any platform deduct from the same pool of inventory.

the identifier that ties it all together: EAN and GTIN

For a catalog to say “this Amazon listing and this MercadoLibre listing are the same product,” it needs a piece of data both share without ambiguity. That data is usually the product’s barcode: its EAN or GTIN. It’s the number printed on the factory packaging and, unlike the internal SKU everyone invents however they like, it’s universal: the same product carries the same GTIN wherever you sell it.

The GTIN is the glue. When you load your listings into a unified catalog and match them by GTIN, the system stops seeing B0XXXXX, MLM-123456 and your-shopify-handle as three things: it recognizes them as three windows into the same product. Once that match exists, everything else becomes possible: deducting from the same stock, comparing prices across channels honestly, propagating a listing change everywhere. Without that common identifier, a catalog is just a long list where the same product shows up repeated with nothing aware that it is.

This is where many sellers trip: they load products without a GTIN, or with badly captured GTINs, and then wonder why the “unified catalog” doesn’t add up. If the glue is applied wrong, the pieces don’t stick. It’s worth spending time making sure every product has its correct code before you connect channels, because that boring work is exactly what makes the syncing run on its own later.

Glossary: the EAN/GTIN is the product’s universal barcode, printed from the factory and identical across all channels; it’s the identifier that lets a catalog recognize that two different listings are actually the same product.

what data each product must share across channels

Unifying isn’t only matching by code. It’s deciding which product information is unique and central, and which is specific to each channel. A good unified catalog draws that line clearly, because blurring it is as harmful as not unifying at all.

In the central, shared layer lives what defines the product regardless of where it sells: the master identifier (SKU and GTIN), dimensions and weight, the variant structure if it carries sizes and colors, the cost, and above all the inventory pool. That last point is the heart of it: physical stock is one thing and must be deducted once, wherever the sale comes from. When inventory lives in the central layer, the question “how many do I have?” has a single correct answer instead of four answers that don’t match.

In the per-channel layer lives what legitimately changes between platforms: the title optimized for each marketplace’s search engine, the price (which responds to different fees and competition), the category, the attributes each platform demands. Here you don’t want forced uniformity, you want control: knowing the same product is named two different ways on purpose, not by neglect. The parent-and-child structure for variants is part of this balance, and we cover it in depth in parent and child products: the structure for managing sizes and colors: each size-color is a child with its own stock, hanging off a parent that groups them, so the catalog knows Small-Blue and Large-Red are variants of the same product and not loose items.

the number that really matters: real availability

A well-unified catalog doesn’t just tell you how much you have in total, it tells you how much you can sell right now on each channel. And those two numbers are almost never the same. Physical stock in the warehouse is one figure; real availability —what can go out and sell today, once you subtract reservations, units in internal transit, returns being reprocessed and blocked inventory— is another, and it’s usually quite a bit lower.

Without a unified catalog, this distinction is lost entirely, because each channel only sees the slice of stock you assigned it and none sees the full picture. With a unified catalog over a common pool, the system can calculate real availability once and distribute it with judgment: how much of that availability to expose on each channel based on its sales velocity, instead of a fixed split that ages the first day. That way the number each platform shows stops being a promise you made weeks ago and becomes a live reflection of what’s actually there.

Glossary: real availability is the stock you can sell right now, once reservations, internal transits, returns in process and blocked inventory are subtracted; it’s what a unified catalog calculates over the common pool so it never promises on one channel units already committed on another.

why real time is what makes it match

You could have the best-structured catalog in the world and still drift out of sync if the syncing isn’t real time. The mismatch doesn’t live in the structure, it lives in the delay. If you sell one on Amazon at 3 p.m. and that deduction takes two hours to reach MercadoLibre, you have a two-hour window in which MercadoLibre can sell a unit that no longer exists. Multiply that window by every sale on every channel and you understand why overselling shows up precisely on your best-moving products, the ones you can least afford to cancel.

The manual pattern is one you know by heart: you open Seller Central to check FBA, then MercadoLibre for Full and Flex, then the 3PL sheet that came by email on Monday, you paste it all into a spreadsheet and adjust quantities by hand. By the time you finish balancing, you’ve sold three more units and the number is wrong again. It’s not that you’re doing it badly; it’s that you’re racing the clock with a tool that was never built for that speed. The mismatch isn’t fixed by checking more often, it’s fixed by removing the manual step.

A unified catalog with real-time syncing closes that window. A sale on any channel deducts from the common pool instantly, and that new availability is reflected across all the other listings before another sale can commit a phantom unit. You stop allocating stock blindly and stop canceling for overselling, not because you check more, but because there’s nothing left to check: the catalog keeps the channels matched without you mediating. That shift, from manual allocation to synced pool, is also what gives meaning to coordinating prices across platforms with your price calendar, because unifying inventory and price over the same base is what turns four uncoordinated operations into one.

how to start unifying without breaking anything

You don’t need to redo everything at once. Start by auditing your identifiers: check that each product has its correct GTIN and that the same product isn’t loaded under conflicting SKUs. That cleanup is the foundation; without it, any unification tool matches wrong and inherits the mess.

Then decide where your source of truth lives. The master catalog should be the place where you create and edit the product, and from there it propagates to the channels, not the other way around. If you keep editing on each platform separately, no central layer stays clean. Choose the common pool as the origin and treat each listing as a projection of that origin, with its per-channel adjustments allowed but its stock and structure inherited from the center.

Close by connecting inventory syncing first, before prices or listings, because that’s the one costing you money today in cancellations and stockouts. Once stock matches on its own across channels, the rest of the unification —titles, prices, attributes— becomes an incremental improvement rather than an emergency. Order matters: first stop the number from lying, then make the product look consistent everywhere.