Multi-Warehouse Inventory for Marketplace Sellers
How sellers with several warehouses, stores and marketplace-run fulfilment centres pool stock into one number per channel and decide which location ships each order.
The basic rule of multi-warehouse inventory is this: every location keeps its own count, and marketplaces see the sellable total. The integration pools stock from all locations, subtracts reserved and damaged units, writes the remainder to each channel, and when an order lands it picks the shipping location by rule and writes it to the ERP with that location attached. Any business that holds stock in more than one place, a central warehouse, retail stores, a contract manufacturer, a 3PL or a marketplace-run fulfilment centre, needs this setup. This guide explains how the single pool is built and how the shipping location is chosen.
Why stock ends up in several places
Most businesses start with one warehouse, but stock spreads quickly. Besides the central warehouse there is stock in stores; seasonal goods ship straight from a contract manufacturer; units wait in an Amazon FBA centre or a marketplace's own fulfilment programme; sometimes a 3PL or a carrier warehouse is used as well.
Counting each location separately creates two problems. First, you do not know which number to write to the marketplace: write only the central warehouse and store stock never sells; write everything and you sell a unit on the marketplace that was just sold in a store. Second, when an order arrives the warehouse team has to ask which location should ship it, and at a hundred orders a day that does not scale.
The fix is to define each location in the integration and manage them through one pool. Inventory sync and overselling covers the single-warehouse pool; here the same logic is extended to several locations.
The single stock pool: adding up locations
The single stock pool is the sum of a product's sellable quantity across all locations. Sellable quantity is the physical count minus reserved units (ordered but not yet shipped), damaged units and anything frozen for a stock count. The integration does this per product and writes the result to every channel.
The source of the pool is your ERP. Whether it is SAP, Logo, Mikro or Nebim V3, every location is defined separately and stock movements are posted per location. The integration reads those counts; you choose which locations join the pool. The central warehouse and two stores can be in, while a store doing its annual count is taken out for a week.
For some products you will not want to expose all stock. Listing the single unit on a store's display shelf means overselling the moment a walk-in customer buys it. For this, a share is defined per location: only part of the store stock enters the pool, not all of it. The store-stock example is described in Nebim V3 marketplace integration.
Which location ships: the routing rule
When an order drops, the system must decide where it ships from; leaving that to a person causes delay. The routing rule is a sequence of decisions:
- The location that has stock. If the product is in only one place, the decision is made.
- The priority location. If several have it, the defined priority warehouse, usually the central one, goes first, because packing and carrier pickups are organised there.
- Proximity to the customer. If the priority location is out, the one closest to the delivery address is chosen, which cuts transit time and cost.
- Split orders. If the lines cannot be completed from one location, the order is either split and shipped from two places or consolidated at the central warehouse first. Which is better depends on shipping cost and customer expectation.
The chosen location is written to the ERP with the order. Warehouse staff see only the orders that ship from their own location; the Warehouse role in user permissions exists for exactly this. Carrier choice can also depend on the location; carrier integration covers the warehouse × carrier mapping.
Marketplace-run and third-party locations
Amazon FBA, a marketplace's own fulfilment programme or a 3PL run by their own rules. Stock there is not physically yours to hand over, and it must not be exposed to other channels. These locations join the pool with an "own channel only" flag: the FBA centre counts only toward Amazon, a marketplace fulfilment centre only toward that marketplace.
The ownership flag comes into play here. For every product × channel pair it is clear whether the integration writes the stock or an external system does. Stock held at an external location is read from the marketplace but never written from the panel, so there is no risk of overwriting the fulfilment-centre quantity. See Amazon Global FBA and FBM integration for the Amazon case.
Reading external stock regularly matters too. If the fulfilment centre holds 50 units while your panel shows 80, a return or a damage write-off has not been posted; the more often you read, the smaller the gap.
Low-stock alerts and inter-warehouse transfers
The single pool shows the total, but a sufficient total may sit in the wrong place. Two units in the central warehouse and 40 in a remote store show as 42, yet most orders will have to ship from the store and shipping cost climbs.
That is why the low-stock alert should also work per location. When the central warehouse drops below threshold an alert fires; the days-of-cover report shows how many days of stock remain at each location. With that, you plan transfers: pulling 30 units from the store to the centre means next week's orders ship from the centre.
The transfer itself is posted in the ERP; the integration reads the movement and updates the pool. Units in transit are counted at neither location; like reserved units they leave the pool and are added back on arrival. Threshold calculation is covered in critical stock and days-of-cover.
Multi-warehouse setup checklist
When connecting several locations to an integration, work through this list:
- Is every location defined separately in the ERP with movements posted per location?
- Which locations are in the pool and which are out (stock count, damaged, display)?
- Is a share defined for store locations, all of the stock or part of it?
- Do external locations (FBA, marketplace fulfilment) count only toward their own channel?
- Is the routing rule ordered: priority location, proximity, split orders?
- Do Warehouse-role users see only their own location's orders?
- Is the low-stock threshold set per location?
- Were location counts compared with the ERP during shadow mode?
How it works with Bulutegra
Bulutegra reads each location in your ERP (SAP, Logo, Mikro, Nebim V3) separately and pools them; you decide which locations enter the pool, how much store stock is exposed and which channel each external location counts toward. When an order arrives the routing rule runs and the order is written to the ERP with the chosen location, customer, line items, carrier and payment details. A Warehouse-role user sees only their own location's orders. The low-stock alert and days-of-cover report work per location, and the ownership flag protects external stock. Setup begins in shadow mode: for one to two weeks location counts are only read and compared with the ERP. This setup was used across the founding company's own store and warehouse network. More on Why Bulutegra?.
To pool your locations into one number per channel, request a demo.
Frequently asked questions
If I have several warehouses, which quantity should the marketplace see?
The most common approach is to show the total sellable quantity: the integration adds up the warehouses, subtracts reserved and damaged units and writes the remainder to the marketplace. For some products you may want to expose only certain locations, which is configured per warehouse × channel.
Can I sell store stock on marketplaces?
You can, but a unit sold in the store at the same moment creates an overselling risk. Store stock in your ERP is connected as a warehouse and the marketplace quantity drops as soon as the store sale is posted. Exposing only part of the store stock reduces the risk.
Who decides which warehouse ships an order?
A routing rule defined in the integration: first the location that has stock, then the priority warehouse, then the one closest to the customer or cheapest to ship from. The order is written to the ERP with the chosen location and dispatched from there.
