Magento inventory management is handled by Inventory Management, often called MSI (Multi-Source Inventory), which ships with Magento Open Source and Adobe Commerce. It models physical locations as sources, groups them into stocks that are assigned to websites, and shows shoppers a salable quantity calculated from source quantities minus reservations for orders not yet shipped. That is enough for many multi-warehouse retailers. Connect a warehouse management system (WMS) when picking, bin locations, lot tracking or carrier workflows need more than Magento's order and shipment screens.
The four MSI concepts, in plain terms
| Concept | What it is | Example |
|---|---|---|
| Source | A physical place where stock is held and shipped from, or a drop-shipper | "Leeds warehouse", "London store", "Supplier X dropship" |
| Stock | A virtual, combined view of the sources that can sell to a sales channel (website) | "UK stock" = Leeds + London store |
| Salable quantity | What the storefront can sell: quantities from the stock's sources, minus reservations and the out-of-stock threshold | 120 on hand - 15 reserved - threshold 5 = 100 salable |
| Reservation | A temporary hold created when an order is placed, cleared by compensation entries when it ships, is canceled or refunded | Order for 2 units creates a -2 reservation on UK stock |
A few rules from Adobe's documentation shape every design:
- Each sales channel (website) can have only one stock, but one stock can serve several websites.
- Every installation starts with a Default Source and Default Stock. Only the Default Source can be assigned to the Default Stock, so multi-source merchants create custom stocks.
- The Default Source cannot be used as an in-store pickup location.
- Products are assigned quantities per source (source items); the product's salable quantity is shown per stock.
How reservations work
Reservations are what let MSI take orders quickly without locking stock rows at checkout. Instead of reducing the on-hand quantity immediately, Magento writes a reservation:
- Order placed: a reservation is saved against the stock, so salable quantity drops. Quantity per source does not change yet.
- Shipment created: the shipped quantity is deducted from the chosen source, and a compensating reservation cancels the hold. Virtual products have no shipment, so their source deduction runs when the invoice is saved (as the Inventory module's event configuration shows).
- Order canceled: a compensation returns the quantity to salable stock. Source quantities are unchanged.
- Credit memo with Return to Stock: the quantity goes back to the source that shipped it, and salable quantity updates.
For an order in a final state (Complete, Closed or Canceled), its reservations should add up to zero. When they do not, for example after a failed import, a custom order flow or a crashed process, salable quantity drifts away from reality. Adobe provides commands to find and fix this:
# list orders whose reservations do not add up (-r gives raw output)
bin/magento inventory:reservation:list-inconsistencies -r
# create compensating reservations for them
bin/magento inventory:reservation:list-inconsistencies -r | bin/magento inventory:reservation:create-compensationsRun the list command on a schedule and alert on any output. Reservations also depend on healthy cron jobs, indexers and message queue consumers; our Magento cron and indexers guide covers how to monitor them.
Source selection: which warehouse ships the order
When you create a shipment, the Source Selection Algorithm suggests which sources should fulfill it. Two algorithms ship with Magento:
- Source Priority (default): uses the stock's source list from top to bottom.
- Distance Priority: picks the closest source to the shipping address, using Google Maps distance or travel time, or offline calculation from imported geographic data. If no route data comes back, it falls back to Source Priority.
Rules beyond these, such as "ship from the store only if the warehouse cannot fulfill the whole order" or "never split orders under a certain value", need a custom algorithm or an order management system.
Multi-warehouse setup checklist
- Create a source for each physical location and drop-shipper, with address and contact details.
- Create stocks per sales channel and assign sources in priority order.
- Assign stocks to websites; remember one stock per website.
- Import source quantities per SKU (CSV import or the REST source-items endpoint).
- Set out-of-stock thresholds and backorder rules; with backorders on, use a negative threshold to cap them.
- Choose the source selection algorithm and test it with real addresses.
- Decide who creates shipments: admins, an ERP, or a WMS.
- Schedule the reservation inconsistency check.
If you also sell in physical stores, the same sources can back in-store pickup and point of sale. See Magento POS options for how a POS fits into this model.
When to connect a WMS
MSI tells Magento how much it can sell and where to ship from. It does not run a warehouse. Look at a WMS when you see these signals:
| Signal | Why MSI alone struggles |
|---|---|
| Pickers need bin locations, wave picking or scanning | MSI has no bin, pick-path or handheld workflow |
| Lots, batches, serial numbers or expiry dates | Not modeled in core inventory |
| A 3PL runs your warehouse | The 3PL's system is the source of truth for on-hand stock |
| High order volume with carrier label printing and cut-off times | Shipment creation in the Admin does not scale |
| Stock moves between sites daily | Transfers and in-transit stock need warehouse-level tracking |
Integration pattern
A typical WMS integration is three flows:
- Orders out: Magento sends paid orders to the WMS, ideally via events or a queue.
- Stock in: the WMS sends on-hand quantities per source to Magento, usually as deltas every few minutes plus a nightly full sync, through the source-items API.
- Shipments in: the WMS sends shipment confirmations with tracking numbers; Magento creates the shipment against the correct source, which clears reservations and notifies the customer.
Keep one owner per number. If the WMS owns on-hand stock, nobody should edit source quantities in the Admin. Where an ERP also holds stock, decide whether the WMS or the ERP feeds Magento; our Magento ERP integration guide covers data ownership in detail.
FAQ
Why does the storefront show out of stock when the product has quantity?
Usually because salable quantity is lower than source quantity: unshipped orders hold reservations, the out-of-stock threshold is deducted, or the source is not assigned to the website's stock. Check the Salable Quantity column in the product grid.
Do single-warehouse stores need MSI?
They use it with just the Default Source and Default Stock. The reservation model still applies, so the same troubleshooting steps work.
Can Magento handle stock for physical stores?
Yes, each store can be a source, and sources can be pickup locations. Real-time accuracy then depends on how quickly the POS reports sales.
Next step
Inventory problems tend to show up as overselling or "ghost" out-of-stocks, and the fix is usually in the data flows, not the settings. Mistri's Adobe Commerce development team designs multi-source setups, and our Magento extension development work covers custom source selection rules and WMS integrations.
Sources
Stocks and sources (Adobe Experience League); Order status and reservations (Adobe Experience League); Inventory Management CLI reference (Adobe Experience League); Configure the Distance Priority Algorithm (Adobe Experience League); In-store delivery (Adobe Experience League); Inventory source deduction events, InventoryShipping module (magento/inventory on GitHub); inventory:reservation:list-inconsistencies command source (magento/inventory on GitHub).


