What is Magento Multi-Source Inventory (MSI)?
Multi-Source Inventory (MSI) is the inventory system built into Magento since 2.3. Instead of one quantity per product, it tracks stock per location with Sources → Stocks → Reservations. That lets one store sell from several warehouses, suppliers, shops or pickup points, while a Source Selection Algorithm suggests which location ships each order.
Below I go through how the parts fit together, when MSI is worth turning on, and the three setup mistakes I see most often on live stores.
- Native since Magento 2.3 (2018)
- Cost Free · Open Source + Adobe Commerce
- Replaces Single qty-per-product model
The four moving parts of MSI
MSI comes down to four parts. Every multi-warehouse setup I have built is some mix of these four.
-
Sources = physical locations
A source is a real place that holds stock: a warehouse, a shop, a supplier or a 3PL. You create them under Stores > Inventory > Sources with a code, name and address. One SKU can sit at several sources, and each source keeps its own quantity in the
inventory_source_itemtable. -
Stocks = logical groupings
A stock groups sources and links them to one or more websites. For example, an "EU Stock" could hold a Berlin and an Amsterdam warehouse. The salable quantity a shopper sees is the total across the sources in that stock, minus open reservations. Most stores I set up have one stock per website, but several websites can share one stock.
-
Reservations = soft locks
Placing an order does not touch the source quantity. Magento writes a negative row to the
inventory_reservationtable instead, which lowers the salable quantity right away. When you ship, the source quantity goes down and a matching positive reservation cancels the first one. If the numbers ever look wrong,bin/magento inventory:reservation:list-inconsistenciesis where I start. -
SSA = Source Selection Algorithm
When the admin creates a shipment, the SSA suggests which source ships each line. The default, Source Priority, goes through the sources in the order you set on the stock. Distance Priority picks the closest source to the shipping address, using Google Maps or offline geo data. If neither fits, you can write your own algorithm against the
SourceSelectionInterface.
Five scenarios where MSI earns its keep
For a store with one warehouse and no plans for more, MSI adds work you do not need. These are the cases where it earns its place.
-
Multiple warehouses
Two or more places you ship from, which is common for retail, D2C brands and wholesalers with regional depots. MSI can ship one order from a single source or split it across several when no single source has everything.
-
Multi-region storefronts
One stock per website: the EU site sells what is in the EU warehouses, the US site sells what is in the US ones, and neither oversells the other. This fits well with multi-store setups.
-
Drop-shipping
Each supplier becomes a source with its own quantity, usually fed by a stock import. The SSA then suggests which supplier ships each line based on stock and priority. With a custom SSA you can route by supplier lead time or shipping cost instead.
-
BOPIS / click-and-collect
Buy online, pick up in store. Each shop is a source with "Use as Pickup Location" switched on, and Magento 2.4 adds an In-Store Pickup delivery method at checkout. The shopper picks a store, and the order is fulfilled from that shop’s stock.
-
Pre-orders & negative inventory
With backorders enabled and a negative Out-of-Stock Threshold, MSI lets you keep selling below zero. The open orders show up as reservations and are covered when new stock arrives. For a simple pre-order you do not need an extension; for deposits or release dates, you still do.
Three configuration mistakes that bite stores in production
Most MSI problems I get asked to fix come back to one of these three. Checking for them now is cheaper than cleaning up oversold orders later.
-
Disabling MSI for "simplicity"
A common upgrade-from-2.2 reflex. You lose native pre-order support, the reservation safety net (overselling prevention), and the SSA. Single-stock mode is implemented as a "Default Stock" containing all sources: the framework is always present. Disabling the modules just hides the admin UI; the cost is later when you actually need a second warehouse.
-
Misconfigured stock-website links
If website-A is linked to stock-EU but the storefront route also serves website-B (linked to stock-US), customers may see EU availability but the order ends up in US stock. Always verify
inventory_stock_sales_channelrows match yourstore_websitesetup. Test with each website’s URL in an incognito window. -
Forgotten source priorities
Without explicit priority numbers the SSA falls back to source-code alphabetical order, which is rarely what you want. Always set priority on every source: lower numbers ship first. Common pattern: priority 10 for primary warehouse, 50 for overflow, 90 for drop-ship.
Six questions stores ask before turning MSI on
Is MSI on by default in Magento 2?
Yes, from Magento 2.3 onwards, MSI ships enabled by default in both Open Source and Adobe Commerce. A new install creates a Default Source and a Default Stock so the platform behaves like a single-warehouse system out of the box. You only see the multi-source admin once you add a second source.
MSI vs the old single-stock model: what’s the performance cost?
Negligible for stores under ~100k SKUs and ~5 sources. The MSI tables (inventory_source_item, inventory_reservation) add an indexer pass and one JOIN at PDP qty resolution, which Adobe shipped with built-in caching. On 1M+ SKU catalogs with 20+ sources you may need to tune the inventory indexer mode (set to "Update on Schedule") and run the reservation cleanup cron regularly. Real-world overhead: 2-5% on TTFB, fully offset by the operational gains from multi-warehouse routing.
Does MSI work with Hyvä Themes?
Yes, MSI is a backend system. Hyvä only changes the storefront layer; the inventory tables, indexers, reservations, and SSA are all pure Magento backend. Hyvä ships its own PDP/cart/checkout templates which call the same StockResolver service Luma does. Source-display widgets (e.g. "stock at your nearest store") may need a small Hyvä-compatible re-skin if the original was Knockout-based.
Can I write a custom Source Selection Algorithm?
Yes, implement Magento\InventorySourceSelectionApi\Api\SourceSelectionInterface and register it via di.xml with a unique algorithm code. Common custom SSAs: ship-from-cheapest-shipping-cost, ship-by-margin-priority, ship-by-supplier-SLA, ship-by-carrier-coverage. The interface receives an InventoryRequestInterface (SKU + qty + destination) and returns a SourceSelectionResultInterface with the source-allocation breakdown. Full reference in the InventorySourceSelection module.
Does MSI play nicely with B2B + customer-segment pricing?
Yes. MSI sits at the inventory layer, B2B and customer-segment pricing sit at the catalog/quote layer, they don’t conflict. A B2B company with negotiated pricing on its quote still routes fulfilment through the SSA on the order’s assigned stock. The only gotcha: if you use stock-per-website to isolate a B2B website, make sure the B2B company’s default website matches.
Adobe Commerce vs Open Source: any MSI feature difference?
Two notable differences: (1) the Distance-based SSA using Google Maps / OpenStreetMap lat-long routing is Adobe-Commerce-only, Open Source ships only the Priority-based SSA. (2) Adobe Commerce’s B2B module exposes per-company source restrictions in the admin UI. Everything else, Sources, Stocks, Reservations, custom SSAs, indexer behaviour, BOPIS support, is identical between editions.
Need MSI configured for a real multi-warehouse build?
I’ve set up MSI on multi-region stores with 5+ warehouses, drop-shipper networks, and BOPIS retail chains. Sources, stocks, custom SSA, indexer tuning, the full kit. Fixed-price quote in 24 hours.