Magento Multi-Source Inventory for B2B Distributors: Setup and Pitfalls

Magento Multi-Source Inventory, usually called MSI, lets one Magento store track stock in several warehouses and decide which warehouse ships each order. For a B2B distributor, that is the difference between a site that says "in stock" because some branch somewhere has the part and a site that knows which branch can ship it. The inventory screens are only half the job. The other half is the Magento ERP integration that feeds warehouse quantities into Magento and sends orders and shipments back.

This guide explains how Magento MSI models inventory, how source selection and split shipments work, why shipping rates get complicated across origins, how to sync quantities from an ERP, and the B2B and performance pitfalls we see on multi-warehouse builds. MSI is the same Inventory Management feature in Magento Open Source and Adobe Commerce, so everything here applies to both editions.

How Magento MSI models inventory

MSI separates where stock physically sits from what a sales channel is allowed to sell.

Concept	What it is	B2B note
Source	A physical location that holds stock: a warehouse, branch, store or drop shipper	Usually one per ERP warehouse or location code
Stock	A group of sources assigned to one or more websites	Each website can use only one stock
Source item	The quantity and status of one SKU at one source	Usually fed by the ERP, not edited by hand
Reservation	A pending deduction recorded when an order is placed	Cleared when the order ships, is canceled or is refunded to stock
Salable quantity	Source quantities in the stock, minus reservations and the out-of-stock threshold	What the store checks when a buyer adds to cart

Sources and stocks

You create sources under Stores, Inventory, Sources, each with a code, an address and an optional pickup location flag. You then group them into stocks under Stores, Inventory, Stocks, set the priority order of sources inside each stock, and assign each stock to one or more websites. A store with a single warehouse can stay on the Default Source and Default Stock and never touch any of this.

The rule that shapes most B2B designs: Magento treats the website as the sales channel, and a website can be assigned to only one stock. Every buyer on that website sees availability from the same group of warehouses.

Reservations and salable quantity

When an order is placed, MSI does not deduct stock from a warehouse. It writes a reservation against the stock, which lowers salable quantity right away. The physical deduction happens when a shipment is created and a source is chosen, and at that point a compensating reservation cancels the original one. Cancellations and credit memos that return items to stock add compensating reservations too.

Salable quantity is calculated per stock, not per source. If one warehouse holds 6 units and another holds 4, a buyer can order 10, and the order will ship from two places. That is usually what a distributor wants, as long as everyone downstream expects it.

Source selection and split shipments

Magento decides which source ships an order with a source selection algorithm. Two ship with MSI:

• Source Priority works down the ordered list of sources in the stock, taking stock from each source in turn until the order is covered.
• Distance Priority picks the source closest to the shipping address, using either the Google Maps API or offline geocoding data imported with bin/magento inventory-geonames:import.

By default the algorithm runs when someone creates a shipment in the admin. It recommends sources and quantities, staff can override them, and each source becomes its own shipment. Magento does not assign a source when the order is placed. If your ERP expects a sales order per warehouse as soon as the buyer checks out, or your warehouses ship without anyone opening the Magento admin, you need custom logic. Developers can register their own algorithms, which is how most distributor builds handle it.

For QC Supply, a farm and ranch supply retailer that sells to consumers and B2B Pro accounts, we built a headless Adobe Commerce store wired into Microsoft Dynamics NAV with a line-item source algorithm. It chose sources by maximum availability, capped the number of warehouses per order, used a fallback source when needed, and split each order into per-source NAV sub-orders. That work also meant retrofitting Magento MSI against QC Supply's existing custom extensions for order management, call-for-pricing, fast ordering, stock status and the NAV integration itself.

Shipping rates across origins

Native Magento carriers calculate rates from the one shipping origin set in configuration, not from each source. A cart that will ship from two warehouses gets quoted as if it ships from one, and the difference comes out of your margin or the buyer's pocket.

ShipperHQ is the usual tool for multi-origin rating, but check exactly what it returns for your setup. On the QC Supply build, ShipperHQ did not return per-origin rates, so we made multiple rate requests and stitched them into accurate per-shipment rates. Before that, the gap between a single rate and the real cost of shipping from several warehouses had been leaking shipping margin.

Decide early whether buyers see one combined rate or a rate per shipment, how many origins a single order may ship from, and how the cart explains that an order may arrive in more than one box.

Syncing source quantities from an ERP

For most distributors the ERP owns on-hand quantity by warehouse, and Magento should treat it that way.

• Map locations to sources. Every ERP warehouse or location code needs a matching source code, and opening a new warehouse needs a process for adding both.
• Send source items in batches. Use the POST /V1/inventory/source-items endpoint, which accepts many SKU and source pairs per call, or the Stock Sources entity in the admin import. Saving products one at a time is slow and triggers more reindexing.
• Pick a frequency that matches the risk. QC Supply's warehouse sources synced daily from Dynamics NAV. On a Fortune 500 equipment manufacturer's Magento store, each warehouse was its own source, fed by inventory files from the ERP. Scarce or fast-moving stock needs shorter cycles than slow movers.
• Send shipments back with the source. When the ERP ships, create the Magento shipment through the API with the source code, so MSI deducts from the right warehouse and clears the reservation.

The double-counting trap

This is the sync mistake we see most often. If the ERP sends available quantity, meaning on-hand minus open orders, while Magento still holds reservations for those same unshipped orders, every open order is subtracted twice and the store undersells. The opposite mistake oversells: a Magento shipment clears the reservation, but the next ERP sync still reports the pre-shipment on-hand quantity, so those units become salable again. Agree on which number the ERP sends, and make sure reservations clear when the ERP confirms a shipment.

B2B considerations

Customer-specific availability

Because each website uses one stock, MSI cannot natively show different warehouses to different companies on the same site. Adobe Commerce B2B shared catalogs control which products and prices a company sees, not which warehouses serve it. The options are separate websites with their own stocks, custom salable-quantity logic by customer group or company, or a live ERP call for branch-level availability on the product page.

Lead times and backorders

MSI has no lead-time field, and backorders are set per product or globally rather than per source. If buyers need a ship date by warehouse, store lead time per source in a custom attribute or pull it from the ERP, and decide which warehouse a backorder will ship from before you promise a date.

Branch pickup

Magento's In-Store Pickup delivery method uses sources flagged as pickup locations. For distributors with will-call counters it is a reasonable starting point, though most need extra rules for pickup hours and account permissions.

Our page on B2B ecommerce for distributors covers the wider distributor feature set, and Magento B2B covers company accounts, quotes and account pricing.

Performance and indexing pitfalls

• Run indexers on schedule. Set the Inventory indexer, and the others, to Update by Schedule so stock changes are processed in batches by cron instead of on every save.
• Count your source items. Each SKU at each source is a row. 50,000 SKUs across 20 sources is a million source items to index, sync and validate, so create sources only for locations you actually sell from.
• Watch reservation drift. Orders changed outside the normal flow can leave reservations behind. The inventory:reservation:list-inconsistencies and inventory:reservation:create-compensations commands find and fix them, and they belong in your support runbook.
• Mind the page cache. When a product's stock status changes, Magento clears cached pages for that product. A full sync that flips thousands of statuses at once can empty much of the page cache at peak hours.
• Audit extensions. Older code that reads the legacy stock tables directly can show wrong quantities once you run more than one source, which is why QC Supply's custom extensions needed retrofitting.

Setup checklist

1. Confirm you need more than one source. A single warehouse rarely justifies the extra moving parts.
2. List every ERP location and map it to a source code.
3. Decide how stocks map to websites, and whether any buyers need different availability.
4. Choose a source selection approach: Source Priority, Distance Priority or custom.
5. Decide when sources are assigned: at shipment, which is the default, or at order placement, which is custom.
6. Plan multi-origin shipping rates and how the cart explains split shipments.
7. Agree whether the ERP sends on-hand or available quantity, and test reservations against it.
8. Build the source item sync with batching, error handling and a daily reconciliation.
9. Set indexers to Update by Schedule and load test a full sync.
10. Audit custom and third-party extensions for MSI compatibility.

Frequently asked questions

What is Magento Multi-Source Inventory?

Magento Multi-Source Inventory (MSI) is the Inventory Management feature that tracks stock at multiple physical locations, called sources, and groups them into stocks that websites sell from. It also handles reservations, salable quantity and the source selection that decides which warehouse ships an order.

Is MSI available in Magento Open Source?

Yes. MSI has been part of both Magento Open Source and Adobe Commerce since version 2.3. Stores with one warehouse can use the default source and stock without configuring anything else.

What is salable quantity in Magento?

Salable quantity is the amount a store can still sell from a stock: the total quantity at the sources in that stock, minus reservations for orders not yet shipped and minus the out-of-stock threshold. It is calculated per stock, not per warehouse.

Does Magento split orders across warehouses automatically?

Magento can ship one order from several sources, and its source selection algorithm recommends the split when a shipment is created in the admin. Splitting at order placement, or sending per-warehouse orders to an ERP, requires custom development.

Can MSI show different stock to different B2B customers?

Not natively on one website, because each website uses a single stock. Distributors handle it with separate websites, custom availability logic by customer group or company, or a live availability call to the ERP.