When a Magento Open Source multi-source inventory setup is worth building
Multi-source inventory (MSI) is the Magento Open Source capability that lets one storefront sell from stock held in several physical or logical locations, called sources, and then group those sources into stocks that the catalog reads from. Teams implement it when they hold stock in more than one warehouse, keep inventory in branch stores, or rely on drop shippers whose stock is not in their own building, and they want customers to see one accurate salable quantity per product across all of it. If a single default source already matches how the business ships, a multi-source build adds maintenance without adding sales.
The work splits into three layers that should be scoped separately. Configuration covers sources, stocks, the assignment of sources to stocks, the source selection algorithm and the rules for how orders are allocated. Data setup covers the source item records for every SKU at every location, the initial stock import through the CSV process and the naming, codes and priorities that will be used long after launch. ERP integration covers how stock levels, reservations and shipment confirmations move between Magento and the system of record. Each layer has a different owner. Merchandising and operations usually own the source model, the data team owns the import files, and the integration team owns the sync and its failure handling.
Before committing, confirm a few facts with your own team. Ask how many locations really hold sellable stock, whether any location is a drop shipper that will never report counts, and whether sources must be ranked by priority or chosen by distance from the customer. Those answers decide whether the source selection setup stays simple or needs custom logic. Also ask who will correct stock counts when they drift, because the reservation and salable quantity figures depend on those counts being trusted by operations.
The edition matters for scope. This page assumes the Magento Open Source edition, which is the target here, and it describes what you build on that platform. Verify each module, setting and API method against the release line you will run, because the supported PHP, MySQL or MariaDB, OpenSearch and other component versions differ by release and the vendor supports only listed combinations. Plan the build as a project you can test in staging with real stock files, not as a switch you flip in production.
What Magento Open Source inventory management does across sources and stocks
Multi-source inventory in Magento Open Source separates where stock physically sits from the sales channels that sell it. Sources, stocks, source selection, reservations and salable quantity connect these two layers, and each one needs a deliberate decision before the catalog goes live.
Sources as physical stock locations
A source is a physical location that holds on-hand quantities, such as a warehouse, a store or a drop shipper's dock. Each source carries its own quantity, status and address data, and the team must decide which locations are real stock holders and which are only fulfillment points. Confirm the source fields and any import options against the documentation for your release.
Stocks as sales channels
A stock groups sources and assigns them to one or more sales channels, typically a website or store view. The team must decide which sources feed each stock, whether a source can serve several stocks, and how a stock is mapped to a website. Check the stock-to-sales-channel assignment screens for your release before finalizing the model.
Source selection by priority or distance
When an order is placed, Magento Open Source uses a source selection algorithm to decide which sources fulfill each line item. Priority ordering and distance-based selection are the configuration choices to evaluate, and the team must confirm which algorithms the release offers and what inputs they need, such as customer address and source coordinates. Test the outcome with representative orders before go-live.
Reservations on order placement
Reservations record stock committed to open orders so that two customers cannot buy the same units. Reservations are created and compensated as orders move through states such as placed, shipped and canceled, which means a failed or canceled order must release its quantity. Plan how reservations interact with fulfillment steps and confirm the reservation behavior in your release notes.
Salable quantity and low-stock alerts
Salable quantity is the amount a storefront can sell for a product in a stock, calculated from source quantities minus reservations and any configured thresholds. The team must decide the out-of-stock threshold per stock and what shoppers see when salable quantity falls to zero. Verify how the threshold and notification settings behave in your release before relying on them.
Synchronizing stock from an ERP
Source quantities often originate in an ERP or warehouse system, so the team must decide whether stock is loaded by CSV import, an integration or both, and how often it refreshes. Stale quantities produce overselling or lost sales, so define the system of record, the refresh cadence and the reconciliation check. Confirm import file formats and API endpoints against the documentation for your release.
Which source and stock model fits your warehouses, stores and drop shippers
This table compares the source and stock decisions a Magento Open Source MSI project must settle, with the setup effort, ongoing upkeep and late-change risks for each option. Read each row as a choice between two models, and check the last column before committing, because some changes are small in configuration but costly in open orders and historical stock data. Confirm feature availability in your target 2.4.x release before finalizing.
| Decision and option | When it fits | Setup and maintenance | What breaks if reversed late |
|---|---|---|---|
| Stock model: one default stock | One storefront or sales channel that shares a single stock picture across all sources | Lowest setup. Sources are assigned to one stock once. Upkeep is limited to source records and stock levels. | Splitting into several stocks later means reassigning sources and sales channels and rechecking salable quantity for existing products. |
| Stock model: separate stock per website or channel | Storefronts with different catalogs, availability or fulfillment, such as retail and wholesale | Each stock needs its own source links and product assignments. Mappings need regular review as channels change. | Merging stocks later means reconciling reservations and product-to-stock links across channels, and open orders may reference the old structure. |
| Source selection: priority-based | A preferred warehouse should ship first, with others as overflow or backup | Priority values are set per source. Easy for operations to understand. Review priorities whenever a warehouse opens, closes or changes capacity. | Changing priorities affects which source fulfills future orders. Check pending and partially shipped orders before the change goes live. |
| Source selection: distance-based | Multi-location retail or regional networks where shipping distance should drive allocation | Needs accurate source addresses and a configured distance method. Confirm which selection algorithms ship in your version. | Switching later changes allocation for new orders only. Address or coordinate errors can misroute shipments without any visible failure. |
| Drop shippers: registered as sources | Suppliers report reliable stock levels and the store should sell their inventory directly | Each drop shipper needs a stock feed through CSV import or sync, plus a named owner. Supplier data quality drives most of the effort. | Removing a drop shipper later leaves salable quantities and open orders tied to supplier stock. Reconcile reservations before deleting the source. |
| Drop shippers: external fulfillment step | Suppliers confirm orders in their own system or by EDI, or they do not report stock | Requires an integration for order handoff and status updates. Stock is not tracked in MSI, so no feed is maintained there. | Moving to a registered source later requires loading stock quantities and rebuilding reservations for products already sold. |
| Stock updates: CSV import or ERP sync | Stock changes are infrequent and a team can run imports, or the ERP is the system of record | CSV imports need an owner and a schedule. ERP sync needs a mapping, error handling and monitoring of failed updates. | Switching methods later can create conflicting quantities. Agree on one source of truth and clear the existing stock data first. |
How salable quantity and reservations behave when one product has several sources
A product's salable quantity in Magento Open Source MSI is the figure the storefront uses to decide whether a shopper can buy it, and it is calculated per stock. For each stock, the system adds the quantities of the sources assigned to that stock, counts only sources whose status is In Stock, and then subtracts the quantity already reserved by open orders. Reservations form a separate record of demand that has been committed but has not yet moved physically. A product can therefore show zero salable quantity while every warehouse still holds units on the shelf.
Illustrative example: one SKU sits in Warehouse A with 10 units (In Stock) and Warehouse B with 4 units (In Stock), and both sources are assigned to the Default Stock. Salable quantity is 14. A customer orders 3 units, which creates a reservation of 3 against the stock and drops salable quantity to 11. Source quantities remain 10 and 4 until a shipment is created. If the team then sets Warehouse B to Out of Stock, its 4 units stop counting, and salable quantity becomes 7 (10 minus the 3 reserved). The storefront shows 7 even though Warehouse B still physically holds 4 units, which is expected behavior but often surprises operations staff.
This sequencing is where overselling usually starts. It can happen when an ERP or CSV import overwrites source quantities without accounting for the reservations that open orders hold, or when a source is switched to out of stock while its units are still reserved. Ask your integrator whether stock syncs replace source quantities or adjust them, and confirm in the documentation for your exact version whether any integration may write to salable quantity directly. Also confirm the Out-of-Stock Threshold configured for each stock and how the storefront displays low or zero salable quantity, because both determine what shoppers see at the moment of purchase.
Before go-live, test the full reservation lifecycle with real orders on a staging copy that mirrors your sources and stocks. For order placement, confirm that the reservation lands on the correct stock, that salable quantity drops, and that the product page updates after indexers run in the mode you chose. For cancellation, confirm that the reservation is released, salable quantity returns, and source quantities are unchanged. For partial shipment, create a shipment for only part of an order from one source, then confirm that only the shipped units reduce source quantity, that the remaining units stay reserved, and that the second shipment draws from the correct source. Repeat these checks for two shoppers buying the last units at the same time.
Magento Open Source multi-source inventory rollout, step by step
This sequence takes a store from a confirmed Magento Open Source release and stack to a multi-source inventory setup that reserves and ships stock correctly, with a runbook the operations team can use after cutover.
Confirm the release and supported stack
Start by fixing the Magento Open Source version you will run and checking its system requirements page for the exact supported combinations of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx. Adobe supports only the listed combinations, so the team records each component version and the Varnish version if you self-manage full-page caching. The output is a signed-off stack sheet and an environment plan that names which versions are non-negotiable. Confirm the support end date for the chosen release line with Adobe's lifecycle page before the build starts.
Define sources and stocks
Map each warehouse, store, or drop shipper to a source, then group sources into stocks that correspond to the sales channels they serve. The workshop is led by the merchant's operations lead with the solution architect, and the output is a source and stock register listing source codes, addresses, enabled status, and which stock each website uses. Check the register against the warehouse list signed by operations, because a missing source or wrong stock assignment changes salable quantity for every product.
Map products and channels
Decide which products are assigned to which sources and how each source's quantity feeds the stock for each website. Catalog data is reviewed for SKUs that exist in more than one place, bundle and configurable parents, and products that should never be sold from a given channel. The deliverable is a source map: a table of SKU groups, source assignments, default stock behavior and channel visibility, reviewed by merchandising and operations. Sign-off means every active SKU has a documented source assignment and no SKU is left with an unexplained quantity.
Prepare and import source data
Build the stock source CSV import template from the source map and load a test batch into a staging copy. Each row carries SKU, source code, quantity, status, and any notify-threshold values, and the team validates encoding, decimal handling, and duplicate rows before any import. The output is an import template, a row-level validation log, and a reconciled count per source that matches the warehouse extract. Repeat the import until the staging counts match the warehouse system exactly.
Configure source selection
Choose the source selection algorithm and priority order for each stock, deciding whether orders draw from the nearest source, the highest-priority source, or a sequence that falls back when stock runs out. Test each algorithm against sample addresses and realistic baskets in staging. The output is a source selection configuration document that records the algorithm, the priority or distance inputs, and the expected source for each test case. Confirm with operations that the chosen algorithm matches how shipments actually leave the warehouses.
Connect the ERP stock feed
Define the ERP as the system of record for source quantities, then build the feed that pushes stock levels into Magento, including its schedule, error handling, and reconciliation report. Integration engineers own the connector, the ERP owner approves the field mapping, and the output is an interface specification with a feed runbook. The feed is done when a controlled change in the ERP appears in the matching source within the agreed interval and a failed record is logged and retried rather than silently dropped.
Test reservations and order flows
Run a written test script covering order placement, reservation, partial fulfillment across sources, cancellation, refund, and returns, against every stock and website combination. Each case records the expected source, the salable quantity before and after, and the actual result. The output is a signed test script and a defect log in which every critical case passes and any open defect has a named owner and a fix or workaround. Include the ERP feed in at least one end-to-end case so reservations and reconciliation are checked together.
Cut over and hand over
Schedule the cutover for a window agreed with operations, freeze source quantity changes during the switch, run the final import and feed, and reconcile salable quantities against the warehouse records before opening orders. The handover pack includes the runbook covering routine stock imports, feed failures, adding a source, and rollback steps, plus training for the team that will run it. Cutover is complete when reconciliation shows no unexplained variance and the operations team has executed each runbook task once under observation.
What drives multi-source inventory cost and how to keep it down
This table lists the drivers that change the effort and cost of a Magento Open Source multi-source inventory build, who usually pays for each one, whether it is one-time or recurring, and what keeps it manageable. Read the first two columns to set scope and the last column to decide where to invest early. The main takeaway is that stock file quality and ERP integration depth drive most of the build effort, while customizations and extensions drive most of the recurring upgrade effort.
| Driver | Who pays | One-time or recurring | How to keep it down |
|---|---|---|---|
| Number of sources and stocks | Client sets the design; partner builds the configuration | One-time build, plus change work when sources are added | Agree the source and stock map in writing before build; add stocks only where the business needs them |
| SKU count and variant complexity | Partner for import and testing; client for catalog data | One-time for the initial load, recurring as the catalog grows | Clean attribute sets and configurable variants before import; test with a representative sample of SKUs |
| Data quality of existing stock files | Client prepares the files; partner maps and validates them | One-time cleanup, recurring if feeds stay inconsistent | Standardize SKU codes, units and update times; agree file format and reject rules with each warehouse |
| ERP integration depth | Partner builds the connector; client's ERP team supplies endpoints and sign-off | One-time build, recurring support of the interface | Limit the first release to the stock fields needed; document sync direction, frequency and failure handling |
| Custom source selection logic | Partner for custom development and testing | One-time build, recurring when business rules change | Start with the standard priority or distance options; add custom logic only for rules the business has approved |
| Extension conflicts | Partner for diagnosis; client for licenses and vendor support | One-time to resolve, recurring with each extension update | Inventory every extension and confirm its vendor's support for the target 2.4.x release before build |
| Number of channels and marketplaces | Client decides the channels; partner builds feeds and mappings | One-time per channel, recurring for each channel's changes | Launch with the most important channels; define the salable quantity rule per channel before connecting |
| Upgrade drivers: customizations, extensions, integrations and coding practices | Client budgets recurring support; partner under a retainer if agreed | Recurring every patch cycle; Adobe's upgrade guide recommends applying each cycle | Keep custom code in PSR-4 modules, limit overrides, and run the Upgrade Compatibility Tool before each patch |
How multi-source inventory connects to the ERP, order flow and storefront
Multi-source inventory only works when stock figures agree across the systems that hold them. Each connection below carries a different kind of data, has a different owner, and needs its own confirmation before the storefront shows a salable quantity customers can trust.
ERP or warehouse system as stock master
Decide which system is the source of truth for on-hand quantities per source, usually the ERP or warehouse management system, and which one only receives updates. Stock source imports or API syncs push quantities into Magento Open Source, so the mapping of SKUs, source codes and units of measure must match exactly. Confirm who owns the mapping, how often the sync runs, and how it behaves when a warehouse file is late or contains a SKU Magento does not know.
Order management and source selection
When an order is placed, Magento reserves stock and selects a source by the priority or distance rules you configure, and the order then has to reach the warehouse that will ship it. Confirm which system creates the fulfillment record, how source assignments are passed to the warehouse, and who decides when a source is overridden manually. Test partial shipments and cancellations, since they change reservations and salable quantity.
Storefront, search and caching layers
Salable quantity shown on product pages and in category listings depends on the search index and the cache layers in front of the storefront. Full-page caching on self-managed installations uses Varnish, and the system requirements list supporting services such as OpenSearch, Redis or Valkey and RabbitMQ for each release. Confirm the cache invalidation and indexer schedule with the platform team, and check the exact service versions against the requirements for your release before testing stock display.
Reporting and stock reconciliation
Finance and operations need stock reports that match the ERP and the warehouse count, which means reservations, source quantities and shipped units must be reconciled on a regular cycle. Decide which system is the reporting reference, who signs off on variances, and how adjustments flow back to the stock master. Confirm that report exports use the same source and stock definitions as the sync, so that one number does not carry two meanings across teams.
Dependency and version checks before build
Each connection relies on a specific combination of PHP, database, search, cache and message queue services that Adobe supports for the release you choose. Confirm the supported combinations in the system requirements page before the ERP connector is written, because a later version change can alter stock indexing behavior. Record the chosen versions in the design document so the integration team and the platform team test against the same stack.
Stock source CSV imports and ERP sync: deciding what to automate
Decide the system of record for stock before you build anything that moves quantities. In a multi-source setup, Magento stores a quantity per source and per SKU, and those figures feed the salable quantity shoppers see. Two data paths can populate them. The first is a stock source CSV import, run once for a cutover or periodically when a warehouse sends counts. The second is an ongoing feed that pushes stock from an ERP or warehouse management system on a schedule or on events. These paths are not interchangeable. If the ERP owns quantities, a periodic CSV becomes a second writer that overwrites live values, and the two will disagree. If a warehouse team keeps counts in spreadsheets, a continuous feed may simply copy stale numbers faster. Write down which system is authoritative for each source and who may change its numbers.
Validate files before they reach the store. Test a small sample file in staging to confirm the header row, delimiter, text encoding and decimal format your release accepts, and ask your implementation partner to document the exact template. Each row needs a SKU that already exists in the catalog and a source code that already exists in Inventory. Decide what happens to rows that fail. The import should report each rejected row with a reason and not skip it quietly, and you should confirm that behavior for your release. Zero quantities usually mean out of stock at that source, but check whether the source status also needs to change. Negative quantities need a written rule. They often come from receipts posted late or shipments recorded before stock arrives, so decide whether to reject them, clamp them to zero or accept and flag them for review.
Scheduling and error reporting determine how quickly a bad file or feed outage becomes visible. A one-time import needs a rollback plan and a second person to check totals before and after the run. A recurring feed needs a fixed run schedule, a rule for overlapping runs and an alert when the last successful run is older than the business can tolerate. Confirm where import results appear in the admin and logs for your release, whether failed rows can be downloaded, and whether notifications can reach an operations mailbox. For an ERP feed, most cost sits in field mapping, handling the ERP's API limits and error cases, and testing those paths. Ask a partner to price the initial build and the ongoing maintenance separately, and to state who monitors the job after go-live.
Reconciliation is where disagreements become operational problems, so name the owner before go-live. The owner should be a single role, usually inventory or operations, with authority to decide which count wins for a given source. Agree a variance tolerance, a cadence for comparing Magento source quantities with ERP or warehouse counts, and a cycle-count routine for high-value SKUs. Define what happens when a shopper orders against a quantity that later proves wrong, including who approves a correction and how it is recorded. Before you build the feed, test the full sequence in staging with a sample of SKUs, including zero, negative and unmatched cases. Confirm the import and API behavior for the Magento Open Source release you plan to run, and keep the test results as evidence for your own controls.
Questions teams ask before hiring help with multi-source inventory
How much does a multi-source inventory implementation cost?
Cost depends on the number of sources and stocks, how many SKUs and warehouse feeds must be mapped, whether an ERP sends stock levels, and how much custom source selection logic you need. A written quote should split the work into discovery, data mapping, configuration, integration, testing, training and handover, and name who is paid for each step. Ask which costs are one-time and which recur, such as hosting, monitoring, patch cycles and optional support retainers. Check whether the quote covers test data, staging environments and repeated imports during cutover. Ask what changes if you add a warehouse after launch, and which assumptions the price depends on, such as API access from your ERP vendor. DeployOpen does not publish a price list, so a quote follows from the written scope.
How long does a multi-source inventory project take?
Duration follows the scope: the number of sources, the condition of warehouse data, the depth of any ERP integration, and how quickly your staff can make decisions. The phases that most often take longest are data cleanup and testing, not configuration, because stock counts that disagree across systems hold up every later step. No single duration fits every store, so timelines are fixed in the written scope before work starts. Ask for phase milestones, the inputs each phase needs from your side, and the number of test rounds included. Delays commonly come from late SKU lists, unsettled rules for source priority or distance, and ERP vendors who need time to grant access. As an illustration, a store with three warehouses and CSV feeds will usually move faster than one with live ERP sync and drop shippers, but confirm that against your own inventory.
What must we provide before a multi-source inventory project starts?
Your team supplies the data, access and decisions that the configuration depends on. Expect to provide:
- Warehouse data: addresses, coordinates if distance-based selection is used, opening hours, and pick or shipping constraints for each source.
- SKU lists: current product identifiers, stock levels per location, and any items with special handling.
- ERP access: API documentation, sandbox credentials and a named contact who can answer field-mapping questions.
- Decisions: source selection priority or distance rules, reservation and backorder policy, and who owns manual stock adjustments.
- Test staff: people who can place orders across several sources and confirm salable quantities match what the warehouses hold.
Missing items usually surface as extra discovery time or rework during testing, so ask the partner to list these inputs with owners and due dates in the scope.
Can our internal team set up multi-source inventory without a partner?
An internal team can do it if it has Magento developers who know the inventory modules, an administrator who understands your warehouse operations, and time set aside for testing. The configuration of sources, stocks and source selection is usually the smaller part of the work. The harder parts are mapping warehouse and ERP data, agreeing business rules, and proving that reservations and salable quantity behave correctly under real order volume. Ask yourself who will own the stock feed after launch, who will investigate mismatches, and who will apply patches. Upgrade effort is shaped by customizations, extension count, third-party integrations and coding practices, which Adobe identifies as the main drivers, so a store with heavy customization takes longer to maintain regardless of who built it. A partner is useful when those skills or hours are missing, and the scope should show which parts you keep.
What usually breaks in multi-source inventory after go-live?
The most common failures are salable quantity mismatches, stale stock from the ERP or CSV feed, and source selection that sends orders to the wrong warehouse. Reservations that are never released after cancelled or split orders can make a product look out of stock while shelves hold units. CSV imports fail quietly when SKU codes differ by a character or when a column order changes. Check these before launch: reconcile stock per source against the warehouse count, confirm that each order reserves from the expected source, and run failed-import alerts into a monitored queue. Test cancellation, partial shipment and refund paths, since these change reservations. Ask the partner to document the reconciliation report and the steps for correcting a single SKU, so your operations team can act without a developer.
What support do we need after multi-source inventory goes live?
After go-live, the work shifts to monitoring stock accuracy, applying patches and keeping the Magento Open Source version supported. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, with regular support for 2.4.8 ending on May 31, 2028 and for 2.4.9 ending on May 31, 2029. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches are released at least annually for all supported lines. Its upgrade guide recommends taking every patch cycle to stay secure and PCI compliant. Ask whether support is a fixed-scope handover, a retainer, or both, what response expectations are written down, and who pays for an upgrade if a new release changes the inventory APIs. Retainers are optional and priced separately from the implementation.
Should we sync stock from our ERP or import CSV files?
Choose a CSV import when stock changes slowly, one team controls the file, and a scheduled update is acceptable. Choose an ERP sync when stock moves often across sources, several systems write stock, or customers need accurate salable quantities during peak periods. CSV is simpler to build and test, but its accuracy depends on the schedule and on someone noticing failed files. An ERP sync needs field mapping, authentication, retry logic, error queues and a reconciliation job, which adds build and maintenance effort. Many stores use CSV for stock sources they do not control directly and an integration for the systems they do. Ask the partner to show how each option handles a failed import, a duplicated SKU and a delayed ERP response, and to confirm which connector or interface your ERP version supports.
How DeployOpen scopes, builds and supports your inventory setup
DeployOpen plans and builds Magento Open Source multi-source inventory (MSI) in your own infrastructure, starting from a written scope of your sources, stocks, source selection rules and ERP stock feeds. We document the configuration and hand it over to your team, with ongoing support available as a retainer.
How we scope
- Inventory map listing each warehouse, store or drop shipper as a source, with its stock assignments and ownership
- Source selection rule choice, either by priority or by distance, with the fallback behavior agreed in writing
- Written scope and deliverables agreed before work starts, with a quote following from that scope
How we build
- Configure sources, stocks and sales channel links in a staging copy, then test reservations and salable quantity against sample orders
- Build stock source CSV import templates and, where needed, the ERP sync job that updates source quantities
- Confirm the Magento Open Source release and its required PHP, database, search and cache versions against Adobe's system requirements
How we hand over
- Documentation of sources, stocks, assignment rules, reservation settings and the import and sync procedures
- Test records showing order splits across sources, out-of-stock behavior and salable quantity after stock changes
- Operator walkthrough so your team can add a source, correct stock counts and read sync error logs
How we support
- Retainer support covering reviews of inventory configuration after each Magento Open Source patch or minor release
- Regression checks on source selection and salable quantity whenever the ERP feed or catalog changes
- Support scope and response arrangements confirmed in the retainer agreement before service begins
