Real-Time Inventory by Location: Stores, BOPIS & Returns

“Customers are placing orders for out-of-stock items, and we find out after the fact.” 

A customer checks your website on a Saturday morning. It says two are in stock at your Main Street store. They drive across town, walk up to the counter, and learn the last one sold yesterday afternoon. The website wasn’t lying on purpose. It showed the number it was given. 

That’s the problem real-time inventory by location is supposed to solve, and most teams attack it the wrong way. They make the sync faster. But the number on the website is usually wrong, not because it’s late, but because it’s the wrong number. On hand isn’t sellable, and every location needs its own sellable number with one owner. 

This guide is for operations, and eCommerce leads at retailers and distributors who run an ERP, an online store, and physical locations. The job is simple to say and hard to build: promise only what you can hand over. It covers why store and online stock drift apart, what pickup, ship from store and returns need from your ERP, and what to launch first. For the full map of how stores, registers, your website and your ERP fit together, start with our multi-store ERP integration guide. 

Your website shows stock a store already sold because it publishes on-hand inventory instead of sellable inventory. On-hand counts every unit the ERP thinks is in the building. Sellable is what’s left after you take out units already promised, moving, held back or waiting for inspection. Publish on-hand and you oversell, however fast the sync runs. 

This is the most common misconception we see in multi-store projects: “The ERP’s on-hand number is what I should show online.” The correction is simple to state. Sellable = on-hand minus reserved, in-transit, safety stock, and holdbacks. Publishing on-hand causes overselling. 

Three terms get used loosely, so here is how this series uses them: 

• On-hand: units physically recorded at a location. 
• Available (available to sell): on-hand minus units already committed to orders. 
• Sellable: available minus everything else you shouldn’t promise to a new customer. This is the number a website should show for each location. 

Some ERPs also calculate available to promise (ATP), which looks ahead at incoming supply and future commitments. ATP is useful for promising delivery dates. For “can I pick this up today at Main Street?”, sellable by location is the number that matters. 

What sits in the gap	What it is	Why it isn’t sellable online
Reservations	Units held for pickup orders, open sales orders or layaways.	Another customer already owns them.
In transit	Units on a store transfer or inbound shipment.	They aren’t on any shelf yet.
Safety stock	A per-location buffer you choose to hold back.	Covers count errors, shrink and the gap between sale and sync
Holdbacks	Display units, damaged stock, items allocated to B2B accounts.	Physically present but not for this customer
Returns awaiting inspection	Returned units are not yet graded and restocked.	You don’t know yet if they can be resold.

Once each location publishes sellable stock, “in stock at Main Street” becomes a promise the store can keep. That’s the core idea of this whole series: when your website, your registers and your ERP disagree, the customer finds out first. Give stock one owner and they stop disagreeing. 

Syncing more often doesn’t fix inventory mismatches because it sends the same wrong number faster. If the website receives one on hand, a one-minute sync oversells just like a nightly one. More frequent full syncs also add load on the ERP during your busiest hours, which is exactly when stock moves fastest and accuracy matters most. 

Once a day really isn’t good enough anymore. A store can sell its last unit at 10 a.m., and the website keeps offering it until tomorrow. So the instinct to speed up is right for one thing: real-time stock at checkout. The mistake is treating everything as if it needs the same speed. 

That’s misconception 5: “Everything has to be real-time.” The correction: stock and price at checkout should be close to real-time. Financial posting, the catalog and the customer master can run on a schedule, and often run better that way. 

The better design sends small changes when they happen instead of reloading everything on a timer: 

• Event-driven deltas: a sale, return, transfer or receipt changes one location’s sellable number, and only that change moves. 
• A scheduled full reconciliation: a quiet-hours pass that catches anything the deltas missed. 
• Reservations at the moment of order: a pickup order reduces that store’s sellable stock immediately, not at the next sync. 

If your numbers are still wrong after you fix the speed, the problem was never timing. It was ownership. More on telling the two apart at the end of this guide. 

Show total stock if stores never fulfill online orders, and stock per store as soon as customers can pick up or stores can ship. A ship-only business needs one network number built from the locations that fulfill online. A pickup business needs each store’s own sellable number, because the customer is choosing a building, not a warehouse. 

The two models answer different questions: 

Your model	What the shopper asks	Number to publish
Ship only, from warehouses	“Can you send it to me?”	Total sellable across the locations that ship online orders
Ship from warehouses and stores	“Can you send it to me?”	Total sellable across eligible locations, after store buffers
Pickup in store	“Can I collect it at Main Street today?”	Sellable at that one store
Distributor branch with will-call	“Is it on the shelf at my branch?”	Sellable at that branch, at the account’s price

Two practical points. First, a store that doesn’t fulfill online orders shouldn’t feed the online total at all, or you’ll promise units no one can ship. Second, per-store numbers don’t have to be shown as exact counts. Many retailers display bands such as “In stock”, “Low stock” or “Call the store”, driven by sellable stock and the location’s buffer. That keeps the promise honest without exposing a count that changes every few minutes. 

Each platform models a store as a stock location, but they do it differently. Shopify uses locations with their own IDs. Adobe Commerce and Magento use multi-source inventory, where sources roll up into stocks. BigCommerce uses locations and relies on a partner POS. Your ERP’s warehouses or locations have to map one-to-one onto whichever model you use. 

Platform	How a store is modelled	Built-in POS	What the integration updates	Watch out for
Shopify / Shopify Plus	Locations, each with an ID	Yes, Shopify POS	Stock per location ID, mapped from ERP warehouses or stores	A store on a non-Shopify POS needs an integration to deduct stock from the right Shopify location
Adobe Commerce / Magento	Multi-Source Inventory: sources (warehouses, stores) aggregated into stocks that serve sales channels	No, stores use a third-party POS	Source quantities	Which sources feed which stock, so a store’s units only show where they can be fulfilled
BigCommerce	Locations	No, connects to partner POS	Stock per location	Native pickup APIs have limits (see platform limits below)

On the ERP side, the same store goes by different names: a location (and sometimes a subsidiary) in NetSuite, a location in Business Central, a warehouse in SAP Business One, and a retail channel in Dynamics 365 F&O. Getting this mapping right, and documented, is the first step in any multi-location inventory sync. One ERP location, one platform location, one owner of its sellable number. 

In Shopify, stores are usually set lower in fulfillment priority than warehouses, so online orders draw on warehouse stock first and store shelves stay stocked for walk-in customers. 

During a store transfer, units should leave the sending store’s sellable stock when they’re picked, and join the receiving store’s only when they’re received. In between, they’re in transit and belong to neither shelf. A return works the same way: it isn’t sellable again until someone inspects it and restocks it to a specific location. 

Transfers are where many multi-store setups quietly break. If the sending store’s stock drops but the receiving store’s rises before the boxes arrive, the website promises units that are still on a truck. If the receiving side is never confirmed, the units vanish from both. The fix is a clear transfer status in one system, with in-transit stock excluded from every location’s sellable number until receipt. 

Returns awaiting inspection need the same discipline. A returned jacket might go back on the rail, go to a clearance location, or be written off. Until that decision is made, it shouldn’t count anywhere online. 

Set safety stock per location based on how much that store’s count can drift between a sale and the next update. Fast sellers, high-theft items and stores with weaker count accuracy need a bigger buffer. Slow movers and locations with reliable counts need little or none. One buffer for every store is easy to configure and wrong almost everywhere. 

A few rules that hold up in practice: 

• Set buffers per product and location, not one number for the whole catalog. 
• Keep the buffer in one place. If the ERP holds back two units and the integration holds back two more, you’ve hidden four. 
• Raise buffers before peak season and promotions, then lower them after. (Our holiday eCommerce readiness checklist covers the rest of the pre-peak list.) 
• Review them after cycle counts. A store whose counts keep surprising you needs a larger buffer until the counting improves. 

Buy online, pick up in store (BOPIS) works when one system reserves the units at a specific store the moment the order is placed, the store is told to pick it, and the sale completes at handover. The ERP integration’s job is to keep that store’s sellable stock, the reservation and the final sale in step across the website, the register and the ERP. 

The same flow covers click and collect and reserve online, pick up in store (ROPIS), where the customer pays at the counter instead of online. Here is the full sequence and where each step usually breaks: 

Step	What happens	Usually handled by	What breaks
1. Choose a store	Shopper sees sellable stock per store and picks one	Storefront, fed by the integration	Showing on-hand instead of sellable
2. Place the order	Order created; units reserved at that store	The system that owns sellable stock	No reservation, so the store sells the units to a walk-in
3. Notify the store	The order appears in the store’s pickup queue	POS or store app	Orders land in an inbox nobody watches
4. Pick and confirm	Staff pick the items and mark the order ready	POS or store app	Item missing; no rule for partial stock
5. Tell the customer	“Ready for pickup” message with an order code	Storefront or notification service	Message sent before the order is actually picked
6. Hand over	Staff confirm pickup by order number or QR code	POS	No confirmation, so the order never closes
7. Complete the sale	Reservation becomes a sale; the sale posts to the ERP	Integration and ERP	Sale posts twice, or not at all

For a retailer’s view of how this played out in practice, see how a 34-store furniture and mattress chain launched buy online, pick up in store on Magento with ERP integration. 

The system that owns sellable stock for that store should create the reservation, at the moment the order is placed. Everything else reads from it. If the website reserves but the register doesn’t see the reservation, a walk-in customer buys the last unit. If the register reserves but the website doesn’t, the next online shopper sees it as available. Reservation is the most common pickup failure we see. 

In NetSuite, a pickup order commonly enters as a Sales Order rather than a Cash Sale, because it needs a fulfillment step before it’s complete. In Business Central, Microsoft’s Shopify connector maps the locations used to calculate inventory for each shop. LS Central 28.0 added an extension to that connector that maps Shopify locations to LS Central stores for click-and-collect routing. If you’re already on the connector, our Microsoft Shopify Connector support services cover location mapping and the gaps around it. 

The store confirms pickup by scanning a QR code or entering the order number at the register, which closes the reservation and completes the sale. Partial stock and no-shows need rules decided in advance: whether to ship the rest, substitute, or cancel the missing lines, and how long to hold an uncollected order before releasing its units back to sellable stock. 

Decide these before launch, not at the counter: 

• Partial stock: offer the in-stock items now and ship the rest (a split shipment), or hold the whole order. Tell the customer before they drive in. 
• No-shows: set a hold window per store. When it expires, cancel or refund, and release the units back to that store’s sellable stock in the same step. 
• Changed minds at the counter: treat it as a pickup followed by a return, so refund and restock follow the normal return rules. 

Proof in practice: for a beverage manufacturer-distributor on Dynamics 365 F&O, i95Dev built click and collect with QR pickup confirmation and one order ID that follows the order across the website, the call centre, the POS and the ERP. The full scenario is in our Commerce Scale Unit series: 7 retail scenarios where Commerce Scale Unit makes all the difference. 

Ship from the store decides which location ships through order routing rules: which locations are allowed to fulfil online orders, in what priority, and what each must have on hand after its buffer. Most businesses put warehouses first and stores second, prefer one location that can ship the whole order, and fall back to splitting only when they must. 

Routing rules usually weigh these, roughly in this order: 

1. Eligibility: is this store set up to ship online orders at all? 
2. Full order or split: can one location ship every line? Split shipments cost more to send and annoy customers, so many retailers only allow them above a certain order value or for items that would otherwise be backordered. 
3. Priority: warehouses before stores, so shop floors keep stock for walk-in customers. 
4. Sellable after buffer: a store with two units and a two-unit buffer can’t ship. 
5. Distance and capacity: the closest eligible location, unless it has hit its daily cutoff. 

Who runs these rules matters as much as the rules themselves. They can live in the eCommerce platform, the ERP or a separate order management system. Whichever it is, it needs live sellable stock per location from the integration, or it routes orders to stores that can’t fill them. (See how a pool, spa and patio distributor automated order routing across warehouses with ERP-driven sourcing.) For how to decide which system should own routing and stock, see who owns stock and price. 

An online order returned in store (buy online, return in store, or BORIS) has to find the original web order at the register, refund it to the right tender at the original tax, restock the item at the store where it came back, and record the return against the original order in the ERP. Each of those steps touches a different system. 

That’s why misconception 8 causes so much trouble: “Returns are just negative sales.” The correction: a web order returned in store touches refund, restock location, tender and tax across two channels. Treat it as a negative sale at the register and you get a refund with no link to the order, tax calculated at the store’s rate instead of the order’s, and stock restocked to a warehouse it never returns to. 

Event	Usually recorded in	What has to be right
Find the original order	POS, reading the web order	The register can see web orders by order number or customer
Refund	Original payment channel, or store credit	Refund goes to the tender used online, or store credit by policy
Tax	The original order	Refund the tax charged on the order, not the store’s local rate
Restock	The store where it was returned	Stock lands at that store, not the shipping warehouse
Condition	POS or ERP	Resellable, awaiting inspection, or damaged decides where it counts
Financial record	ERP, against the original order	Revenue, tax and inventory reverse on the right order

The piece that makes all of this work is a shared order identity: the same order number visible to the website, the register and the ERP. Without it, staff improvise and finance reconciles by hand. How returns and exchanges should post to the ERP is covered in posting store sales to your ERP . 

Three limits catch teams most often. BigCommerce’s native pickup APIs support one storefront channel and don’t handle in-store stock transfers. Adobe Commerce and Magento have no built-in POS, so store sales depend on a third-party POS and an integration. Shopify stores running a non-Shopify POS need an integration to deduct stock from the right location. 

None of these is a reason to avoid a platform. They’re reasons to plan the integration before you promise pickup: 

• BigCommerce: the native Buy Online, Pick Up in Store APIs currently support pickup on a single storefront channel and don’t support in-store stock transfers. If you run several storefronts or move stock between stores, the transfer logic and per-store stock have to come from the ERP side. 
• Adobe Commerce / Magento: neither Magento Open Source nor Adobe Commerce ships a built-in POS. The store’s POS and the ERP must keep MSI source quantities current, or the storefront promises stock based on stale sources. 
• Shopify with another POS: Shopify POS deducts from its own location automatically. Any other POS doesn’t, so every register sale needs to reach the right Shopify location quickly enough to protect checkout. 

Launch accurate stock by location first, then pickup, then returns anywhere, then ship from store. Each step depends on the one before it. Pickup fails without trustworthy per-store stock, returns anywhere needs the shared order identity that pickup creates, and ship from store needs routing on top of all three. Skipping ahead builds on numbers you can’t trust yet. 

1. Show real stock at every store. Sellable by location, one owner, buffers set. Until this is right, every later feature inherits the error. 
2. Pick up in store. Adds reservations, store notification and pickup confirmation. It’s the first feature customers notice, and the first to expose a bad stock number. 
3. Return it anywhere. Adds web order lookup at the register, refund rules and restock by location. It reuses the order identity built for pickup. 
4. Ship from store. Adds routing rules and protects store floor stock. It’s the most valuable when stores hold inventory the warehouse doesn’t, and the riskiest if steps 1 to 3 aren’t solid. 

A real-time stock count by location is the foundation of omnichannel inventory. Pickup, returns and ship from store are features built on top of it. 

Your problem is timing if stock is right but late, and ownership if it’s wrong even when fresh. A fast sync of the wrong number still oversells. These five questions tell the two apart in a few minutes. If you answer “no” to two or more, speeding up the sync won’t help; deciding who owns sellable stock will. 

“Our inventory is never accurate online.” 

1. Does the website show sellable stock per location, not on-hand? 
2. Can you name the one system that owns each store’s sellable number? 
3. Does a pickup order reserve stock at that store the moment it’s placed? 
4. Are in-transit units and returns awaiting inspection excluded everywhere online? 
5. Is each store’s safety buffer set in one place, and reviewed after counts? 

All yes, and still overselling at peak? Then it really is timing, and event-driven updates for stock at checkout are the next step. (Our Beyond the Sync series looks at why integrations that “work” still fail in the real world.) 

When you don’t need this yet. One location plus a website, shipping only, with low order volume, can usually live with a simple scheduled sync and a modest buffer. The trigger for everything in this guide is store number two, or the day you first offer pickup. 

Make “in stock at Main Street” a promise you keep i95Dev has connected storefronts, stores and ERPs for 450+ businesses. We’ll map your locations, decide who owns sellable stock, and plan pickup and returns in the right order. 

Book a call with an integration expert → · Get the Integration Requirements Template 

Part of i95Dev’s series on connecting stores, registers, websites and ERPs. 

• Multi-Store ERP Integration: How to Get Every Store, Register, and Your Website to Agree  
• Real-Time Inventory by Location, BOPIS, and Returns
• POS, eCommerce, or ERP: Which System Should Own Your Stores’ Stock and Prices?
• Should Every Store Sale Post to Your ERP?
• Same Stores, Different ERP: NetSuite, Dynamics 365, and SAP Business One
• 12 Multi-Store Integration Mistakes, and the Vendor Question That Catches Each One
• For Dynamics 365 F&O specifically: Commerce Scale Unit (CSU) series