Multi-location inventory: decide per location what your store may sell

One number per item is the wrong number

A distributor holds 100 units of an item in the Reno warehouse and 10 on the showroom floor in Sacramento. An integration that adds up every location sends 110 to the store. A customer orders 105, the warehouse ships 100, and the other 5 are display units in another city. That case is on the stock and availability page. This page covers the rules that prevent it.

The problem grows with the grid. A catalog of 4,000 SKUs in two warehouses and one retail location is 4,000 times 3: 12,000 quantities. Each one has its own committed stock and each location has its own purpose. A fourth location adds 4,000 more.

How it works

Every location in the ERP gets a rule, and the quantity is calculated per location before anything is added up. Take item 00123456 in three locations:

location    on hand  for store  rule
Reno            100         84  12 committed, safety stock 4
Columbus         40         15  5 committed, 20 held for wholesale
Sacramento       10          0  showroom, not shipped
total           150         99

Adding up on hand gives 150. Adding up what each location may ship for the web store gives 99. The difference of 51 units is stock that exists and that the store must not sell.

The rules per location

A reserve can be a fixed quantity or a share. A percentage is rounded down per item, so 15% of 84 units is 12, not 12.6.

Mapping locations

The ERP and the store rarely have the same list of locations. There are four shapes.

One to many is the shape that needs a rule: one physical stock feeds two storefronts, or a store and a marketplace, and the same unit must not be offered twice. The split is recalculated on every change, so a sale in the wholesale store reduces what the retail store shows.

Who routes the order

A store with several locations assigns each order to one of them. Shopify applies its order routing rules from top to bottom: "Minimize split fulfillments", "Stay within the destination market" and "Ship from closest location" by default, with "Use ranked locations" as an option. The ERP has its own logic. NetSuite's Automatic Location Assignment uses the location type on the location record, which is Store, Warehouse or Undefined.

When both decide, they disagree on part of the orders. Shopify assigns an order to Columbus because it is closer to the buyer, the ERP commits the stock in Reno, and the shipment from Reno cannot be booked against a fulfillment order that sits at Columbus. The integration gives one system the decision. When the ERP decides, the fulfillment order in Shopify is moved to the ERP's location with fulfillmentOrderMove before the shipment is posted. That call fails when the destination does not stock the item, which is one more reason to keep the item active at every mapped location.

Throughput

A full write of 12,000 quantities to Shopify, in arrays of 250, is 12,000 divided by 250: 48 calls. A normal run sends changes only. If 900 quantities changed since the last run, that is 4 calls. The API budget is shared with prices and orders; the arithmetic is in the notes on integration throughput and Shopify API rate limits.

What goes wrong quietly

A new location is counted. The warehouse manager creates "Returns, to inspect" in the ERP on October 1. An integration that adds up all locations now sells returned goods that nobody has checked. A location without a rule is excluded and reported.

An item is not stocked at the store location. In Shopify an item has a quantity at a location only after it is activated there with inventoryActivate. A product created last week that was activated at Reno only has no inventory level at Columbus: the 15 units there are not offered, and an order cannot be moved to Columbus for that item. The integration activates the item at every mapped location when the product is created.

A transfer is in transit. 30 units leave Reno for Columbus on Monday and are received on Wednesday. For two days they are on hand in neither location and the total is 30 lower. That is correct, and it is the reason a sudden drop on one location is checked against open transfer orders before it raises an alert.

The reserve is applied twice. The ERP already subtracts a safety stock of 4 and the integration subtracts 4 again. Per location and per rule, one system owns the subtraction. The safety stock page covers how buffers are calculated.

What it covers

• A rule per location. Counts for the store or not, per sales channel.
• Reserves. A fixed quantity or a share held back per location, per channel or per item group.
• Location mapping. One to one, many to one, one to many and excluded.
• Routing. One system decides the fulfillment location, the other receives it, including split shipments and partial fulfillment.
• New and changed locations. A location without a rule is left out and listed in the run report.

Which systems

Shopify's limits are in its help center page on locations, checked on October 3, 2026. Deactivated locations and locations created by fulfillment apps do not count toward the limit.

The Business Central caveat decides the build. The item resource of the standard API v2.0 has a single read-only inventory property, and its itemLedgerEntries resource lists quantity and posting date without a location. Quantity per location is read through an API page or query added to your Business Central for that purpose.

In Adobe Commerce the store does not see locations at all. It sees a stock, which is a group of sources assigned to a sales channel. Three sources with 20, 25 and 10 units and open reservations for 15 give a salable quantity of 40. Which sources belong to which stock is the Adobe Commerce version of "which locations count".

The pair pages for Shopify and NetSuite, Magento and NetSuite and Shopify and Business Central cover the location model of each combination.

Where standard connectors stop

Standard connectors and iPaaS platforms document two settings for locations: which ERP locations contribute to the store's quantity, and a mapping that is one to one or many to one. One to many is not a documented option. A fulfillment priority, a reserve per channel and a split rule are not settings either. The nearest thing is a buffer, applied as one flat quantity to every item.

That covers a single warehouse and a store that ships everything it has. It leaves 3 of the 5 rules in the table above without a place: the channel reserve, the priority and the split. In an integration built for your locations those rules are settings you can read, with a dry run that shows the quantity per location before anything is written. The controls are on the dry run and approval page. Send us your list of locations and what each one is for. Tell us what you run.