Which of three questions are your customers actually asking?
Put a tally sheet next to the phone for a week or until you have twenty calls, whichever comes first. Three boxes, one tick each, plus one note. The three boxes are: can I have it at all, when can I have it, and where is it. The note is what the caller would have needed to see to avoid calling.
These are not the same question and they do not have the same fix. A caller asking whether it exists is served by a stock indicator. A caller asking when is served by a promise date, which requires purchase order and production data your storefront probably does not have. A caller asking which branch is served by location-level availability, which is the one most connectors handle worst.
Twenty calls is enough because the distribution is usually lopsided. If sixteen of your twenty are the first question, you have a publishing problem and it is solvable this quarter.
| Criterion | What the caller asked | What it means | What to do |
|---|---|---|---|
| “Do you have any?” | The caller wants a yes or a no before committing to an order or quoting their own customer. | You are publishing nothing, or you are publishing something the caller does not trust. Either way this is the cheapest of the three to fix. | Publish an availability state rather than a raw number: in stock, low, available to order. Banding is easier to be right about and easier to live with. |
| “When can I have it?”This is the row that tells you a stock indicator alone will not stop the calls. | The caller accepts that it is out of stock and needs a date they can give their own customer or their crew. | A promise date question. Your stock number, however accurate, does not answer it, and neither does any commerce platform on its own. | Publish expected receipt dates from purchase orders or work orders, or say plainly that dates come from a person. Do not answer a date question with a quantity. |
| “Which branch has it?” | The caller wants to collect today, or wants to know whether it ships from the depot two hours away or the one four provinces away. | A multi-warehouse problem. One aggregate number is actively misleading here, because a total that includes stock in another region reads as a promise you cannot keep. | Decide the display strategy per warehouse before you publish. This is a modelling decision, not a setting. |
| “Is that number right?” | The caller is looking at your website while they phone, which is the worst outcome of publishing. | You already publish and they do not believe you. Publishing more will not help until the number is correct. | Run the accuracy check below before touching anything else. This is a data problem wearing an ecommerce problem’s clothes. |
Is the number you would publish actually correct?
Run this before you commit to any project, and run it on your twenty fastest-moving items rather than on a sample chosen for convenience. For each item, write down three figures at the same moment: the on-hand quantity in your ERP, the available quantity after allocations and commitments, and the number your storefront shows or would show.
If the storefront number matches on-hand rather than available, you are publishing stock you have already promised to somebody else, and you will oversell. This is a field mapping problem, and Acumatica’s own community has a documented case of the Shopify connector setting the wrong availability because of unassigned commitments, so it is a known shape rather than a theory.
If the three numbers agree and you still would not be comfortable putting the figure on a public page, you have learned something more useful: the fix is not real-time availability, it is a safety stock buffer and a banded display. Publishing a band you can defend beats publishing a number you have to explain.
And if the item is a kit, a matrix item or a non-stock item, expect all three numbers to disagree, because the availability of an assembled or configured item is a calculation rather than a stored quantity. Handle those separately and do not let them stall the rest of the catalogue.
Checked against: Acumatica community 30078: connector not setting correct available due to unassigned commitments, Acumatica community 5378: handling a multi-warehouse setup with BigCommerce
What does one aggregate stock number actually cost you?
A single total across every warehouse is the default that most connectors produce, and it is wrong in both directions at once. It promises stock in a region you will not ship from economically, and it hides stock that a customer standing at your counter could have collected today.
The commercial cost shows up in three places that rarely get connected to the stock number. Orders that ship from the wrong site and eat their own margin in freight. Will-call customers who phoned rather than driving over, because the site could not tell them the local branch had it. And promise dates given by a rep who trusted the total and then had to phone back.
The Acumatica community thread on multi-warehouse setups with BigCommerce is worth reading before you decide, because the practical answers in it are about how you choose to model the problem rather than about a setting to switch on. There is also a documented trap in changing a warehouse-to-location mapping after items have already been exported, so decide your model before you publish rather than after.
Checked against: Acumatica community 6261: changing warehouse to location mapping after export, Acumatica community 5378: multi-warehouse setup with BigCommerce
When should you publish nothing at all?
Publishing availability is not always the right answer, and a page that only argued for it would be a sales page. Four cases where the honest move is to publish no quantity.
In every one of those cases the calls do not stop, and that is the correct outcome. What you can still do is remove the reason for the call from the other direction: a rep who can answer in ten seconds because the answer is on one screen is a better fix than a website number nobody believes.
You make to order. A quantity is meaningless and a lead time is the real answer, so publish the lead time and say it is indicative.
Your stock accuracy has not been measured in the last year. Publish nothing until you have counted, because the first wrong number destroys more trust than the tenth right one builds.
Your competitors would use your quantities. This is a real consideration in some categories, and banding rather than exact counts is the usual compromise.
Your items are lot or serial controlled and customers care which lot. The number is not the question they are asking, and a quantity answers it misleadingly.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Should we show an exact quantity or a status like in stock?
- Bands are safer and are what most mid-market distributors settle on. An exact quantity invites the customer to order exactly that amount at the moment your number is stalest, and it exposes information you may not want public. A band such as in stock, low stock, or available to order tolerates a few minutes of latency without ever being wrong. Exact quantities earn their keep mainly when buyers are ordering full pallets and the difference between 40 and 60 changes their decision.
- How fresh does the stock number need to be?
- Freshness matters less than the field being right. A nightly figure of true available stock is more useful than a real-time figure of on-hand stock that ignores allocations, because the second one oversells and the first one does not. Once the field is correct, set the refresh interval by how fast your fastest item moves rather than by what the connector defaults to, and consider a safety buffer on the small number of items that turn several times a day.
- Can Shopify or BigCommerce show stock per warehouse?
- Both model multiple locations, and the constraint is usually what the connector sends rather than what the platform can hold. The question to ask your integrator is which Acumatica or Cin7 warehouses map to which storefront locations, what a customer sees when their assigned warehouse is empty and another is full, and what happens if you change that mapping after items have already been exported. Acumatica community 6261 documents the last one as a real trap.
- Our customers ask for a delivery date, not a quantity. What do we publish?
- Publish the expected receipt date from the purchase order or work order, and label it as expected rather than promised. That data lives in your ERP and is rarely part of a standard connector scope, so treat it as an integration item to be specified rather than a checkbox. If you cannot get the date reliably, saying that dates come from a person is more honest than a calculated date you will miss, and it keeps the conversation where you can still win it.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.