Acro Commerce

ERP reality checks

Multi-warehouse availability between Acumatica and a storefront: what one stock number costs you

Acumatica holds availability per warehouse and most storefronts show a buyer one number, which is a promise the business cannot keep. BigCommerce does support inventory locations, four to eight by plan, but its Stencil storefront queries return stock from the default location only unless you request an aggregated model, and Acumatica’s own community answer for per-customer warehouse availability is still a customization keyed on something like ship-to state.

What does a single stock number actually cost a distributor?

Acumatica knows that item ABC has 40 in Calgary and none in Toronto. If the storefront publishes 40, a Toronto buyer orders 40 and discovers his lead time is a cross-country transfer. If the storefront publishes only the Toronto figure, you have hidden 40 units of sellable stock from everyone. Neither number is right, because Multi-warehouse availability is showing a buyer what is in stock for them specifically, based on which warehouse or warehouses can actually serve their order, rather than a single company-wide total. is not one number, it is a question with a customer in it.

The cost lands on the sales team rather than on the website. A rep who has been burned twice by the portal promising stock he cannot ship stops sending customers to the portal, and after that no amount of user experience work moves adoption. This is the most common reason we see a technically working B2B storefront sitting at low order share.

The decision to make early is which of three answers you are buying: one aggregated number with a caveat, one number scoped to the buyer’s default warehouse, or real per-location availability on the product page. They cost very different amounts, and the first one is not always wrong.

Checked against: BigCommerce developer docs: inventory locations and default-location storefront stock

What do BigCommerce and Shopify actually do with locations?

BigCommerce has inventory locations. Its developer documentation, read on 20 August 2026, gives limits of up to four locations on Standard, five on Plus, eight on Pro and 100 on Enterprise, customizable by request. The important sentence is the next one: “By default, Stencil’s native storefront and locations queries support stock levels from only the default location.” Stores can ask BigCommerce for an aggregated stock model instead, which keeps a product in stock on the storefront if any location has it.

Read those two facts together and the shape of the problem is clear. Out of the box you get either the default warehouse’s number or the sum of all warehouses, and the sum is exactly the promise you cannot keep. Neither is per-buyer availability.

Shopify also tracks inventory by location, and Shopify B2B models a company’s multiple locations as company locations. What neither platform gives you natively is the rule that says this buyer sees this warehouse’s number. That rule lives in your business, which means it lives in your integration.

Checked against: BigCommerce developer docs: inventory locations and default-location storefront stock

Can an Acumatica customer shop only the warehouse assigned to them?

Not natively, and Acumatica’s own team has said so in the community. In thread 5378 a user asked how to show inventory by warehouse and force sales orders to the customer’s default warehouse on BigCommerce. Sergey Marenich, then Acumatica’s Commerce Edition Team Lead, answered “BigCommerce does not have any inventory locations” and suggested writing a customization: “if you know that all customers from Florida, will go to the warehouse A, you can write a customization that will choose warehouse A when State == ‘Florida’”.

That thread ran across 2021 and 2022 with the client on Acumatica 20R1, and BigCommerce has shipped inventory locations since, so the first half of that answer has aged. The second half has not. Routing a buyer to a warehouse by geography, by customer record, or by ship-to is still a rule you write rather than a setting you tick, and it is still the shape of every working implementation we have seen.

Two field-built patterns show up in the same thread and are worth knowing, because they are what people actually do. One user built a generic inquiry listing SKU and quantity per warehouse, then used Acumatica push notifications to write warehouse-specific values into BigCommerce custom fields. Another suggested an iPaaS reading Acumatica’s OData INSiteStatus feed into custom fields. Both put per-warehouse numbers on the page as data the theme renders, rather than as inventory the platform manages, which means the platform will not use them to prevent an oversell.

Checked against: Community 5378: best way to handle a multi-warehouse setup with BigCommerce

What happens when you change a warehouse to location mapping after export?

The old location keeps its old quantity, indefinitely, and nothing warns you. This is deliberate. Karthik Gajendran, Acumatica’s Technical Product Manager for Retail Commerce, answered exactly this question in community thread 6261 in July 2021: “The Commerce Connector will not make the existing California location quantity to 0 as it is not sure if it is has to make it to 0 or leave it with the existing value.” The reasoning is that some users manage unmapped locations by hand, so a destructive automatic change would be worse.

The remediation he gives is a three-step manoeuvre, and it is the sort of thing that is obvious once you have done it and invisible before. Map the location you need zeroed to an Acumatica warehouse that holds no stock, a dummy warehouse. Process the Product Availability entity so the zero exports. Once it has exported cleanly, remove the temporary mapping.

Put that on your runbook now, not the week you reorganize your warehouses. The failure mode is a phantom stock figure sitting on a storefront location that no longer maps to anything, which reads as perfectly normal inventory until somebody orders it.

  1. Create or identify an Acumatica warehouse with zero quantity for the affected items.

  2. Map the storefront location that must be zeroed to that warehouse.

  3. Prepare and process the Product Availability entity, and confirm the export completed rather than assuming it did.

  4. Remove the temporary mapping and put the real mapping in place.

Checked against: Community 6261: product availability when warehouse-location mapping changes

Which architecture should you buy?

Pick on what your buyers do, not on what the platform can theoretically model. If your customers each ship from one warehouse and rarely change, the second row below is usually the right answer and it is far cheaper than the third.

Three ways to answer “is it in stock” from Acumatica, and who each one suits
CriterionHow it worksWho it suits, and what it costs
One aggregated number, honestly labelledSum availability across the warehouses that can serve online orders and say so on the page, with lead time rather than a hard promise.Sellers who transfer stock routinely and quote lead times anyway. Cheapest by a wide margin. Fails for anyone selling same-day or on a will-call basis.
One number, scoped to the buyer’s warehouseA rule in the integration resolves the buyer’s warehouse from the customer record or ship-to, and publishes only that warehouse’s quantity to that buyer’s catalogue or account.Most distributors with a branch network. Needs per-account or per-catalogue publishing on the platform and a rule you own. This is the Acumatica community’s own recommendation, in customization form.
Real per-location availability on the pageThe product page shows a table of warehouses and quantities, sourced live or near-live, and the cart chooses a source.Sellers whose buyers genuinely choose a branch, such as will-call and counter businesses. The most expensive, and the one that most often needs Middleware is a layer of software that sits between the ERP and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform or a custom service. and a custom front end.

Checked against: Community 5378: Acumatica’s own recommendation, a customization keyed on the order

What we cannot tell you from a page

Whether your Acumatica availability figure is even the right figure before it reaches the storefront. Acumatica calculates several availability quantities and the one the connector publishes may not be the one your team means when they say available, particularly where allocations and unassigned commitments are in play. That is a tenant-specific question and we have not verified a general answer to it.

Whether BigCommerce’s aggregated stock model is available to your store, since the documentation describes it as something a store requests rather than a switch you flip. Ask before you design around it.

The Celeste diagnostic asks how many warehouses you run, whether customers are tied to one, and whether you promise same-day, because those three answers move the platform shortlist more than almost anything else you can tell us.

Checked against: BigCommerce developer docs: inventory locations and default-location storefront stock

The wider picture

This page answers one narrow question. Acro Commerce covers the strategy around it.

Common questions

Does BigCommerce support multiple inventory locations now?
Yes. BigCommerce developer documentation, read 20 August 2026, gives limits of four locations on Standard, five on Plus, eight on Pro and 100 on Enterprise, customizable by request. The catch is on the storefront: by default Stencil’s native storefront and locations queries return stock from the default location only. An aggregated model that combines all locations is available on request. Neither of those is per-customer warehouse availability.
Can Acumatica force a web order to the customer’s default warehouse?
Not as a native connector setting, based on Acumatica’s own answer in community thread 5378. The Commerce Edition team lead’s recommendation there was a customization that selects the warehouse from a known attribute of the order, with ship-to state given as the example. Later threads on limiting which warehouse a website customer can shop from are still open questions rather than answered ones, so treat this as a build item on every project.
We changed a warehouse mapping and the old location still shows stock. What now?
That is expected behaviour rather than a fault. Acumatica’s Retail Commerce product manager confirmed in community thread 6261 that the Commerce Connector leaves the existing quantity alone because it cannot tell whether you want it zeroed. Map the stale location to an Acumatica warehouse holding zero stock, process the Product Availability entity so the zero exports, confirm it exported, then remove the temporary mapping.
Is showing per-warehouse quantities in custom fields a real solution?
It puts the right numbers in front of the buyer, which is worth something, and it does not make the platform enforce anything. Custom field values are content, not inventory, so the cart will not use them to stop an oversell and the platform will not decrement them. Two users in Acumatica community thread 5378 describe building exactly this, one with generic inquiries plus push notifications and one with an iPaaS reading OData. Treat it as a display layer with a separate oversell control.
How fresh does availability have to be?
It depends on how fast your fastest-moving item sells relative to your sync interval, not on a general best practice. The test is simple: take your highest-velocity item, work out how many units move in one sync window on a busy day, and ask whether you are comfortable overselling that many. If the answer is no, you need either a shorter interval, a buffer quantity, or a live check at add-to-cart.

Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.