What do you do in the next hour?
Do these six in order. The mistake under pressure is to start at step six, because the integration is the interesting part and the phone calls are the unpleasant part.
Step three is the one people skip and it is the one that decides whether you keep the customer. A B2B buyer who is phoned about a shortage and offered an option will usually accept it. The same buyer who receives an automated email two days later, after telling their own customer a date, will not.
Cap the item. Set it to a quantity you can honour today, or take it off sale. Do this before you diagnose anything, because the clock is still running.
List the affected orders and rank them by ship date and by customer, not by order date. The order that ships tomorrow to your largest account is not the same problem as the one that ships next month.
Phone, do not email. Offer a specific option per order: partial shipment now, a named substitute, or a firm date.
Check whether it is one item or a pattern. Run a query for every item where the storefront quantity exceeds the ERP available quantity right now. If the answer is dozens, you have a systemic problem and the next incident is already in flight.
Write down the substitution and partial-shipment policy you just improvised, because you will need it again this quarter and improvising it twice produces two different answers.
Now look at the integration, using the three-number test below.
Three numbers, and which two match tells you the cause
For the item that oversold, collect three figures. The on-hand quantity in the ERP. The available quantity after allocations and commitments, which is the number your own order desk would have been shown. And the quantity the storefront was displaying at the moment the order was placed, which you get from the sync log or from the order record rather than from the current page.
Then compare. There are only four outcomes, and each one is a different fix with a different cost. This test matters because the reflex diagnosis is always latency, and latency is the least common of the four in the cases we see.
| Criterion | What you see | What it means | What to do |
|---|---|---|---|
| Storefront matched an older ERP available figure | The number on the site was correct at some point earlier and the item moved in between. | Staleness. The sync interval is longer than the time it takes this item to sell out. | Shorten the interval for fast movers only, or add a buffer on them. Do not shorten it for the whole catalogue and pay for it in API calls. |
| Storefront matched ERP on-hand, not ERP availableThis is the most common cause and the cheapest to fix, which is a good combination to check first. | The site was publishing stock that was already promised to somebody else. | The wrong field is mapped. This is a configuration fault, not a timing fault, and no amount of extra sync frequency fixes it. | Change the mapping to the available quantity and re-publish. Acumatica has a documented case of the Shopify connector getting availability wrong because of unassigned commitments, so check that specific behaviour too. |
| All three matched, and the quantity was genuinely there | The number was right. Two buyers took the same units inside one window, or a rep keyed an order for the same stock at the same time. | Nothing is reserving stock between the moment it is displayed and the moment the order posts. | Either reserve at cart or checkout, or hold a safety buffer sized to your peak concurrent demand. Buffering is cheaper and gives away some availability. |
| The item is a kit, a matrix item or a non-stock item | None of the three numbers agree and the ERP available figure looks odd on its own. | Availability of an assembled or configured item is a calculation over components, not a stored quantity, and connectors handle it inconsistently. | Treat these items as a separate class with their own rule. Publishing a component-derived figure or publishing nothing are both defensible; publishing a stored number is not. |
Checked against: Acumatica community 30078: connector not setting correct available due to unassigned commitments, Acumatica community 5378: multi-warehouse availability with BigCommerce
What does a safety buffer actually cost?
A buffer is the cheapest control and it is the one most teams reach for last, usually because it feels like giving up. Do the arithmetic before you decide that.
A buffer means you publish an availability figure lower than the real one by some quantity. The cost is the orders you decline on items that were actually in stock. The benefit is the oversells you avoid. For a fast-moving item with a healthy reorder cycle, the cost of a small buffer is close to nothing, because the item is replenished before the suppressed demand becomes a lost sale.
Size it per item class rather than globally. A single buffer applied to your whole catalogue will be too large for slow movers, where it hides genuinely available stock for months, and too small for the handful of items that turn several times a day. If you can only afford one rule, apply the buffer to the top items by turn rate and leave the rest alone.
The alternative, reserving stock at cart or checkout, is stronger and more expensive. It requires the storefront and the ERP to agree on a reservation that expires, which is real integration work and introduces its own failure mode when a cart is abandoned and the reservation is not released. Buy it when a buffer is not enough, not before.
When is overselling a policy rather than a fault?
Plenty of distributors sell past zero deliberately and manage it well. If your customers accept backorders and your promise dates are reliable, an oversell is not an incident, it is a backorder with a bad user experience wrapped around it.
The distinction is whether the buyer was told. A storefront that says available to order, ships in about two weeks is doing something entirely different from a storefront that says 14 in stock and then does not ship 14. The first sets an expectation; the second breaks one.
So before you build reservation logic, check whether your real problem is that your site cannot express a backorder. Publishing an availability state that includes an ordering-but-not-in-stock option removes most of the pain of overselling without any change to sync frequency, and it is usually a configuration and copy exercise rather than an integration project.
What it does need is a promise date you can stand behind, which comes from purchase order and work order data in the ERP rather than from the stock figure. If you cannot produce that date, say the date comes from a person and route those lines to someone who can answer.
What should you change permanently?
Three things, in decreasing order of value and increasing order of cost. Nothing here requires a platform change.
The third is the one that gets cut and then gets rediscovered after the second incident. An integration that nobody watches will fail silently, and a stock figure is the field where silent failure is most expensive, because a frozen number looks exactly like a healthy one.
Publish the correct field. Available after allocations and commitments, never on-hand. This one change removes the largest category of oversells and costs a configuration session.
Buffer or band the fast movers. Either a numeric buffer on high-turn items or a banded display for the whole catalogue, and say which you chose and why in writing.
Alert on the sync itself: an alert when the job has not run, and an alert when a quantity has not changed on an item that normally moves daily. A frozen figure is the failure mode that does not raise an error.
Checked against: Acumatica community 15799: ecommerce and API limits, which is what a shorter sync interval spends
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Will syncing inventory more often stop us overselling?
- Only if staleness was the cause, and in most cases it is not. If the storefront was showing your on-hand quantity rather than your available quantity, the number was wrong the instant it was published and syncing it more often just republishes a wrong number faster. Run the three-number test first: compare ERP on-hand, ERP available after allocations, and what the storefront displayed when the order was placed. Extra sync frequency also costs API calls, and both Acumatica and the storefront platforms enforce limits.
- Should we reserve stock when a customer adds it to a cart?
- It is the strongest control and the most expensive one. Reservation requires the storefront and the ERP to agree on a hold that expires, plus a rule for what happens to an abandoned cart, and it introduces a new failure mode where stock is held for nobody. Most mid-market distributors get the same practical result from a safety buffer on high-turn items, which costs a configuration session rather than a project. Buy reservation when a buffer has demonstrably not been enough.
- What number should we publish, on-hand or available?
- Available, after allocations and commitments, and never on-hand. On-hand includes stock already promised to other orders, so publishing it guarantees you will eventually sell the same unit twice. Acumatica community 30078 records a case of the Shopify connector producing a wrong availability figure because of unassigned commitments, so check what your connector is actually sending rather than what the field is labelled.
- How do we handle kits and assembled items?
- As their own class, with their own rule, decided deliberately. The availability of a kit or an assembled item is a calculation over its components rather than a stored quantity, and connectors handle it inconsistently, so a number that looks plausible on the product page may be arithmetic nobody has checked. Publishing a component-derived figure or publishing a lead time instead are both defensible. Publishing a stored quantity for an item that is assembled on demand is not.
- Our customers accept backorders. Do we still need to fix this?
- You need to fix the promise, not necessarily the number. If your site can display available to order with a date you can stand behind, an oversell stops being an incident and becomes an ordinary backorder. The work is then in producing the date, which comes from purchase order and work order data in the ERP rather than from the stock figure, and in making sure the order confirmation says the same thing the product page said.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.