B2B fulfillment rarely runs out of a single warehouse. A distributor with five regional warehouses needs to route orders to the closest fulfillment point. A manufacturer with separate plants for different product categories needs to split orders across plants. A multi-brand operator needs to fulfill from brand-specific warehouses while presenting a unified storefront. Adobe Commerce’s Multi-Source Inventory (MSI) module was designed for exactly these scenarios, and it has matured into a capable cross-warehouse engine that supports most B2B fulfillment models. Getting the most out of MSI requires understanding its sources, stocks, source selection algorithms, and the integration patterns that connect it to the broader operations stack.
This piece walks through how to model B2B cross-warehouse fulfillment using Adobe Commerce MSI. It is written for engineering leaders, operations directors, and IT teams building or refining B2B fulfillment on Adobe Commerce. The patterns below come from Bemeir’s MSI work across distributors, manufacturers, and multi-warehouse retailers.
The MSI Model: Sources, Stocks, Source Items
MSI introduces three core concepts that all decisions flow from:
- Sources represent physical fulfillment locations. A warehouse, a brick-and-mortar store with stock, a drop-ship partner, or a third-party logistics location are all sources.
- Stocks represent the inventory pools that storefronts present to customers. A stock can pull from one or more sources.
- Source Items are the inventory records — each source has stock for each SKU, with a per-source quantity.
The relationship between sources, stocks, and storefronts is what makes MSI flexible. A storefront is mapped to a stock. The stock can include multiple sources, which means the storefront’s apparent availability is the sum of stock across all included sources. The source selection algorithm decides which source(s) actually fulfill an order.
The Adobe Commerce MSI documentation is the canonical reference for the data model, and the Adobe Commerce developer documentation on MSI covers the architectural patterns.
Modeling Multi-Warehouse B2B
For a B2B operator with multiple regional warehouses, the natural MSI model is:
- One source per warehouse, named for the region (e.g., “East Coast DC”, “West Coast DC”, “EU Central”)
- One stock per market or channel (e.g., “US B2B Stock”, “EU B2B Stock”), with the appropriate regional sources included
- Storefronts mapped to the relevant stocks (e.g., the US B2B storefront maps to the US B2B Stock)
The model becomes more nuanced for operations with brand-specific or product-line-specific warehouses:
- Some sources may only carry a subset of SKUs (the brand-specific warehouse only has SKUs from that brand)
- Some stocks may need to combine multiple warehouses for resilience
- Some products may be drop-shipped and have a “drop ship” source representing the partner
Each of these complexities is modelable in MSI but requires explicit configuration.
Source Selection Algorithms
When an order is placed, MSI’s source selection algorithm decides which source fulfills the order. Adobe Commerce ships with several algorithms:
- Priority-based: sources have a numeric priority, and the algorithm fulfills from the highest-priority source that has stock.
- Distance-based: the algorithm calculates distance from the shipping address to each source and prefers closer sources.
- Custom: merchants can implement a custom algorithm via the `SourceSelectionInterface` extension point.
For B2B specifically, priority-based selection is often the right starting point. The merchant orders sources by preference (typically by distance to common shipping destinations, by stock holding strategy, or by drop-ship vs in-house preference) and the algorithm follows that priority.
Distance-based selection is appealing but requires accurate latitude/longitude on every source and the destination address, which means integration with a geocoding service. The setup cost is meaningful, and the actual fulfillment improvement is often marginal compared to priority-based selection if priorities are set thoughtfully.
| Source selection scenario | Recommended algorithm | Configuration cost |
|---|---|---|
| 3-5 regional warehouses, US-only | Priority-based by region | Low |
| Many warehouses across multiple countries | Distance-based with geocoding | High |
| Mix of in-house and drop-ship sources | Priority-based with custom drop-ship logic | Medium |
| Brand-specific warehouses with overlap | Priority-based with brand-aware customization | High |
| Single warehouse + manufacturer drop-ship | Priority-based with manufacturer fallback | Low |
Order Splitting for Cross-Warehouse Fulfillment
The most operationally complex scenario is order splitting: a single customer order that requires items from multiple sources. MSI’s default behavior is to fulfill from a single source when possible, but for orders that exceed a single source’s stock, the algorithm splits the order across sources.
The merchant needs to decide how splits are presented to customers and how the operations team handles them:
- Single shipment vs multiple shipments
- Customer charged once vs per-shipment
- Backorder handling for items that can’t be fulfilled from any source
- Order status reporting when shipments come from different sources
These decisions affect customer experience and operations workflow. Bemeir’s Adobe Commerce B2B practice typically models these in the discovery phase before MSI is configured, because retrofitting these decisions after operations are running is expensive.
Stock Aggregation and Out-of-Stock Behavior
The storefront-facing stock display is aggregated across sources. A product with 10 units in East Coast DC and 5 units in West Coast DC shows as 15 units available. Out-of-stock behavior triggers when the aggregate falls below the threshold.
This aggregate behavior is usually right for B2B operations, where the customer doesn’t care which warehouse fulfills their order as long as the order ships. For operations where the customer expects to know which warehouse stocks an item (e.g., distributor portals where dealers select pickup locations), the storefront needs to surface per-source stock explicitly. Adobe Commerce GraphQL exposes this data, and the storefront has to be built to use it.
Inventory Integration Patterns
For most B2B operations, the source of truth for inventory is not Adobe Commerce — it’s an ERP, a WMS, or a dedicated inventory management system. Adobe Commerce’s role is to receive inventory updates and present them to customers.
The integration patterns:
- Push from ERP: the ERP pushes inventory updates to Adobe Commerce on every change. Best for low-velocity inventory with high accuracy requirements.
- Scheduled pull: Adobe Commerce or a middleware pulls inventory updates from the ERP on a schedule (every 5-30 minutes typically). Best for high-velocity inventory where push integration would be too chatty.
- Real-time API: storefront queries the ERP directly for stock at request time, bypassing Adobe Commerce inventory. Best for very-high-velocity inventory but most operationally complex.
For most B2B operations, scheduled pull is the right pattern. The latency between actual inventory change and Adobe Commerce display is a few minutes, which is acceptable for most B2B contexts where customers expect a “stock as of last sync” model rather than real-time accuracy.
Bemeir’s integration work with NetSuite, SAP Business One, Microsoft Dynamics 365, and other ERPs typically lands on a scheduled-pull pattern with explicit conflict resolution for rare race conditions.
Source-Specific Pricing
Some B2B operations need source-specific pricing. The same SKU costs different amounts depending on which warehouse fulfills it (because of carrier rates, regional tax, or merchant-specific economics). Adobe Commerce’s pricing model is product-centric, not source-centric, which means source-specific pricing requires explicit handling.
The patterns:
- Bake source-specific costs into shipping rate calculation (the price is the same, the shipping cost varies by source)
- Use customer-specific pricing that varies by customer region (and customer assignment to region correlates with source assignment)
- Build a custom pricing layer that adjusts based on source selection
The right pattern depends on the merchant’s billing model. Bemeir’s B2B engagements model this explicitly during the catalog and pricing design phase.
Stock Reservation and Concurrency
For high-traffic B2B operations, stock reservation under concurrent orders is a real concern. Two customers ordering the last unit of a SKU at the same time produces a race condition that has to be handled.
Adobe Commerce MSI handles reservation through the `inventory_reservation` table, which tracks reservations until orders are fulfilled. The default behavior is correct for most scenarios, but high-concurrency stores need to validate that reservations are honored under load and that the reservation cleanup process is running correctly.
The Adobe Commerce MSI reservation documentation covers the reservation lifecycle.
Reporting and Visibility
Operations teams need visibility into inventory across sources. Adobe Commerce’s admin provides per-source stock reporting, but for many B2B operations the more useful reporting lives in the ERP or in a dedicated business intelligence tool.
The pattern is to export MSI data to the BI layer on a schedule, where it can be combined with sales data, fulfillment metrics, and operational KPIs. Tools like Looker, Tableau, and Power BI handle this integration through standard database or API connections.
What MSI Does Well, and What It Doesn’t
MSI is well-suited for:
- Multi-warehouse fulfillment with explicit source-to-region routing
- Drop-ship integration alongside in-house fulfillment
- Multi-brand operations with brand-specific warehouses
- B2B operations with regional stocking strategies
MSI is less well-suited for:
- Real-time inventory across thousands of stores (the data volume becomes operationally heavy)
- Highly dynamic inventory where stock changes on sub-second cadence
- Operations requiring lot-level or serial-number-level tracking (MSI tracks SKU-level inventory, not unit-level)
For operations that exceed MSI’s natural scope, the right pattern is to keep the inventory system of record outside Adobe Commerce and let MSI present a representative view rather than acting as the authoritative source. Bemeir’s Adobe Commerce B2B work and broader Shopware B2B practice both treat the ERP as the source of truth when inventory complexity exceeds MSI’s natural scope.
The B2B fulfillment landscape continues to evolve. Gartner’s B2B Commerce research and Forrester’s reports on B2B commerce platforms provide useful industry context. MSI in Adobe Commerce is a mature capability that handles the majority of mid-market B2B fulfillment patterns cleanly, and the patterns above are what produce sustainable implementations rather than ones that collapse under operational pressure.
