TL;DR
Multichannel inventory management means every sales channel sells from one stock truth, synced at the variant (EAN) level. The architecture that holds up: an inventory system as the source of truth, a channel hub distributing to marketplaces and shops, and explicit rules for which side wins when quantities disagree. Overselling is what happens when any of those three is missing.
Multichannel inventory management keeps stock consistent while the same units are for sale in several places at once: your shop, two marketplaces, a B2B portal. The failure mode is famous. Two channels both sell the last unit of the same size, one customer gets a cancellation email, and the marketplace algorithm quietly penalizes the account.
In fashion the problem is sharper than in most categories because the sellable unit is small and specific. Nobody oversells "the overshirt"; they oversell the Camel M, one EAN with three units on the shelf. Any sync that operates above the variant level is arithmetic on the wrong numbers.
This guide covers the architecture that works in 2026, where the hub model fits, and the sync rules that decide who wins when systems disagree.
One Stock Truth, and It Is Not a Marketplace
The first decision is where the authoritative quantity lives. Candidates are the inventory system, the shop platform, or a marketplace backend. The answer is the inventory system, for one structural reason: it is the only place that sees stock before it is listed anywhere.
Goods arrive from suppliers, get verified, and only then become sellable. That receiving flow (documents in, discrepancies resolved, stock posted) happens in inventory software by definition; the lifecycle is described in Wholesale Inventory Management Software for Fashion. If a sales channel holds the master quantity instead, every delivery becomes a manual update to that channel, and every other channel inherits the delay.
The source of truth is wherever stock changes first. In a business that receives physical deliveries, that is the inventory system, always.
Sync at the EAN, Roll Up for Humans
The unit of sync is the variant: one EAN, one quantity. A product-level feed ("Overshirt: 13 in stock") is useless to a channel that needs to stop selling the Navy L specifically.
The record that travels between systems is minimal:
{ "ean": "8051234560011", "quantity": 3, "updatedAt": "2026-07-02T09:14:00Z" }
The timestamp is not decoration. When two systems hold different quantities for the same EAN, recency is the only defensible tiebreaker: last writer wins, per variant, with the timestamp deciding who wrote last. A sync without per-variant timestamps ends up overwriting fresh warehouse counts with stale channel data, or the reverse, and nobody can reconstruct why.
Three directions need explicit rules:
| Situation | Rule |
|---|---|
| First connection (baseline) | Push inventory quantities to the channel side, per EAN |
| Local change (delivery, stocktake) | Local wins, push outward |
| Remote change (marketplace sale) | Remote wins, pull inward |
The baseline case deserves respect. Connecting an existing catalog to an existing channel account means thousands of EANs where both sides have opinions. Do it as an explicit one-time direction choice, not as "whatever syncs first".
The Hub Model: Why BaseLinker-Style Integration Scales
Point-to-point integration (inventory system connects to every marketplace directly) grows as N connectors, each with its own API quirks, rate limits, and category taxonomies. The alternative is a hub: the inventory system syncs to one channel manager, and the channel manager fans out to the marketplaces, shops, and fulfillment.
This is the architecture Agilo uses with BaseLinker. Agilo remains the stock truth and the catalog master; the BaseLinker integration pushes products as parent-and-variant records (the parent carries the model data, each variant carries its EAN and quantity) and reconciles stock per EAN in both directions using the last-writer rule above. BaseLinker then handles the per-marketplace mechanics: listings, orders, couriers.
What the hub model buys you:
- One integration to maintain instead of one per channel.
- Channel expansion without engineering. Adding a marketplace becomes hub configuration.
- Order aggregation on the hub side, so the inventory system consumes one stream of stock decrements.
What it costs: the hub's product model becomes a constraint. Hubs typically model parent products with flat variants, so structure the catalog accordingly (variant = size × color, EAN mandatory) and keep colorway images attached to the right variants, or listings inherit the wrong photos. The catalog side of that discipline is covered in Fashion Inventory Management Software: A Buyer's Guide.
Prices Differ by Channel; Model It, Don't Fork It
Multichannel pricing fails when the only way to run a marketplace promotion is to edit the product's price. Then the boutique price changes too, and price history is gone.
The structure that works keeps one base retail price on the product and per-channel overrides beside it:
- channel retail override (this channel sells at a different list price)
- channel promotion, as a percentage or absolute discount, computed into a final promo price
Sync sends each channel its own effective price alongside the EAN-level quantity. The base price never mutates for a campaign. Reverting a promo is deleting the override, not remembering what the number used to be.
Product Data Rides Along with Stock
Stock sync gets the attention, but the same pipe carries product data, and it fails in quieter ways. Three fields cause most multichannel listing problems in fashion:
- Images. Marketplace listings need the photo of the variant's own colorway. If the sync sends one model-level image set, every non-default color lists with the wrong photos. Keep images keyed to color in the source catalog and send them per variant.
- Categories. Every channel has its own taxonomy. Map once from your internal categories to the hub's, and let the hub handle per-marketplace category mapping; doing it per channel in the inventory system reintroduces the N-connector problem through the back door.
- Identifiers. The EAN is the join key across every system in the chain. A variant without an EAN cannot be tracked through the hub, matched to marketplace listings, or reconciled after drift. Treat missing barcodes as a blocking error at catalog time, not a warning.
The rule of thumb: quantities sync continuously, product data syncs on change, and both flow in one direction from the catalog master outward. Channels edit neither; channel-specific presentation lives in the hub or the channel itself.
Where does AI fit in this picture? Mostly upstream of the sync: extracting supplier documents into clean variants, classifying products into your taxonomy, and enriching bare EANs into listable records. AI inventory management is less about a model predicting demand and more about making sure the data being synced is right; the intake side is covered in Invoice Data Extraction: From Supplier PDF to JSON.
Latency, Buffers, and the Honest Limits
Even a correct sync has a window: a unit can sell on channel A in the seconds before channel B hears about it. Practical mitigations, in order of usefulness:
- Sync on events, not just schedules. A sale or a stock edit should trigger a push immediately; scheduled full syncs are the safety net, not the mechanism.
- Safety buffer on thin stock. Listing quantity minus one when only one or two units remain trades a little availability for zero oversells on the sizes that matter most (the last units of a good size are exactly the ones selling everywhere).
- Full reconciliation as a recurring job, comparing every EAN on both sides and logging what it corrected. Drift happens; unmeasured drift compounds.
If overselling still occurs with event-driven sync, per-EAN timestamps, and a thin-stock buffer, the cause is almost always upstream: stock that entered the system without being verified. Fix receiving first; the lifecycle discipline in Fashion ERP: What It Should Do in 2026 exists precisely to keep unverified quantities out of the sellable pool.
B2B Is a Channel Too
Wholesale businesses tend to treat marketplace sync as "the multichannel problem" while their largest channel, B2B reorders, still runs on a PDF line sheet and a phone call. From the stock ledger's perspective, a boutique reordering twelve units is exactly the same event as twelve marketplace sales: variant-level decrements that every other channel needs to hear about promptly. Bringing B2B onto the same stock truth, even just by taking reorders against live availability in the inventory system, removes the largest and least visible source of double-selling in wholesale operations.
A Checklist for 2026
Evaluating multichannel inventory management software, or auditing a setup you already run:
- Is there exactly one system where stock changes first, and is it the one that receives deliveries?
- Does sync operate per EAN with timestamps, and can you state the conflict rule in one sentence?
- Is the first-connection baseline an explicit, documented direction choice?
- Can a channel run a promotion without mutating the base price?
- When quantities on the two sides disagree, does anything notice, and where is that logged?
Five yeses and overselling stops being a recurring incident and becomes a rounding error. Anything less and the gaps are where the cancellation emails come from.