What is the difference between availability and a promise date?
This is the missing half of requirement four on Acro’s Acumatica fit test, multi-warehouse allocation and promise dates. The allocation half gets written about constantly under the heading of real-time inventory. The promise half almost never does, and it is the half a buyer actually reads.
Availability answers "is there stock". A promise date answers "when will it be at my dock", and those are separated by everything that happens between the two: whether the stock is already committed to somebody else, which location will actually ship, how long your warehouse takes to pick, whether the carrier runs on a Saturday, and what happens if the answer is that you have none and the next container lands on the 14th.
Available to promise is the quantity you can commit to a customer for a given date, counting stock on hand, stock already allocated elsewhere, and inbound purchase orders. It is a smaller and more honest number than on-hand quantity. is the ERP term for the quantity you can commit to a new order without breaking a promise you already made. It is not the on-hand number and it is usually smaller. A storefront that publishes on hand and calls it availability is publishing a number that will be wrong the moment two customers want the same pallet.
The commercial reason to care is narrow and worth stating. A distributor who shows no date loses orders to one who shows a date. A distributor who shows a date they miss loses the customer. So the useful question is not whether to show a date, it is which dates you can compute honestly and what you say for the rest.
Which six inputs does an honest promise date need?
Work through these against your own systems and mark which ones you can actually read through an API today. Most mid-market distributors can read the first two and stall on the third, and the third is the one that decides whether you can promise anything on an out-of-stock line.
The point of the list is triage. If inputs one to five are available, you can compute a date. If only one and two are, you can compute an availability statement and nothing more, and you should say so on the page rather than guess.
On hand at the location that will actually ship this order, not the company-wide total.
Quantity already committed to other orders at that location. This is the difference between on hand and Available to promise is the quantity you can commit to a customer for a given date, counting stock on hand, stock already allocated elsewhere, and inbound purchase orders. It is a smaller and more honest number than on-hand quantity., and it moves all day.
Inbound receipts with a confirmed date. A purchase order with a supplier-confirmed date is a promise you can pass on. A purchase order with a planned date is a guess you should not pass on as a commitment.
Supplier or production lead time for anything you do not stock, including whether that lead time is in calendar days or working days. This is where made-to-order lines get their date.
Pick, pack and dispatch time at that location, including the daily cutoff. A 4pm order does not ship on a 2pm cutoff, and no software fixes that.
A transit calendar for the service the customer chose, including which days the carrier does not deliver.
What does the storefront compute natively, and where does it stop?
Storefront platforms compute delivery dates from shipping configuration rather than from supply. That distinction is the whole story: they can tell a buyer how long the parcel takes once it leaves, and they cannot tell a buyer when the item will exist.
Shopify documents manual delivery dates built from a fulfilment time set globally for the store plus a transit time set per shipping rate. The constraints published with it matter more than the feature. Shopify states that "Expected delivery dates are displayed at checkout if a product’s inventory exceeds 0", that "Delivery dates don’t work with shipping rates provided by third-party apps", that "If your checkout displays a mix of eligible and ineligible shipping rates, then delivery dates aren’t displayed", that "Weekends and statutory holidays are included in the estimated delivery dates calculation", and that "The business day cutoff time is 12 pm in the local timezone of the shipping origin". For a distributor, three of those five are disqualifying on their own: the date disappears exactly when the item is out of stock, which is when the buyer most needs one, and the cutoff is not your warehouse’s cutoff.
Shopware carries the date on the product rather than on the rate. Shopware documents a delivery time field where "you indicate, how long it approximately takes for the product to reach the customer", plus a restock time in days that "indicates how long it will take until a sold out item is back in stock", and states that for items not in stock "this time is added to the delivery time". That is closer to a lead-time model, and it is still a static number per product rather than a computed date from your actual inbound receipts.
For BigCommerce and Drupal Commerce we did not find a documented native promise-date engine of this kind, and we are not going to assert one either way. Treat the date on those platforms as something you supply from the ERP or from a service, which is what most distributors end up doing on every platform anyway.
| Criterion | What computes the date | Where it stops |
|---|---|---|
| Shopify | Global fulfilment time plus per-rate transit time, displayed at checkout. | Only shown when inventory exceeds zero, not shown with third-party app rates, and the business day cutoff is fixed at 12pm in the shipping origin’s timezone. |
| Shopware | A delivery time on the product, plus a restock time in days added to it when the item is sold out. | Static per product. It does not read your inbound purchase orders, so the restock number is only as good as whoever last edited it. |
| BigCommerce and Drupal Commerce | No native promise-date engine of this kind that we could verify in vendor documentation on 20 August 2026. | The date is whatever your integration supplies, which is the honest position on all four platforms once backorders are involved. |
| Acumatica or Cin7 behind any of them | The only place that holds committed quantity, inbound receipts and lead times together. | The ERP will give you the ingredients. Turning them into one date the storefront can show is integration work with an owner, not a setting. |
Checked against: Shopify Help Centre: setting up manual delivery dates, fulfilment and transit time, cutoff and display rules. Read 20 August 2026, Shopware docs: product delivery time and restock time in days, added to delivery time when out of stock. Read 20 August 2026
What does Acumatica already know, and what will it refuse to do?
Acumatica already carries the date vocabulary a distributor uses. A sales order holds a requested date and a scheduled shipment date, and shipments are created against the scheduled shipment date rather than against the order date. That is the field your storefront date has to agree with, because it is the one your warehouse works from.
It also enforces that date in a direction that surprises people. In Acumatica community thread 21741, posted February 2024, a user reported the error "Order does not contain any items planned for shipment on (date)" when trying to create a shipment earlier than the scheduled shipment date, with stock on hand. The workarounds discussed in the thread were to move the scheduled shipment date, change the line quantities, or change the warehouse, and the thread closed without an accepted answer or a confirmed fix. Read it as a design position rather than a defect: Acumatica treats the scheduled date as a plan, not as a suggestion.
The practical consequence for a storefront is that a promise date is not decoration. Whatever date you show, something has to write a matching scheduled shipment date onto the order, or your warehouse will work to a different date from the one your customer read. Decide which system computes the date and which system merely displays it, and write it down before anybody builds either side.
Note the date on that thread. It describes behaviour observed in 2024 and it should be re-checked against your own release before you design around it.
What do you show when you cannot compute a date?
This is the part nobody publishes, because admitting you cannot compute a date is not a good look on a datasheet. It is, however, the situation most distributors are actually in for a large part of the catalogue, and there are four honest answers that all outperform a made-up date.
The anti-pattern is worth naming plainly. A static "ships in 3 to 5 days" applied to the whole catalogue is a promise your operations team never agreed to, and buyers learn within a quarter that it means nothing. Once they learn that, every date you show afterwards is discounted, including the ones that were accurate.
Show a computed date only where you have all the inputs, and show it as a date rather than a range. Buyers plan against dates.
Show a lead-time band with its source named, for example "made to order, currently 4 to 6 weeks", where the band comes from a field somebody owns and updates rather than from a theme setting.
Show quantity available now and quantity on order with the inbound date, and let the buyer decide. Distributors underestimate how much buyers prefer this to a single optimistic number.
Show nothing and commit to a response time instead, for example "we confirm a date within four working hours". This is the correct answer for configured and made-to-order lines, and it converts better than a date the buyer does not believe.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- What is available to promise, in plain terms?
- Available to promise is the quantity you can commit to a customer for a given date, counting stock on hand, stock already allocated elsewhere, and inbound purchase orders. It is a smaller and more honest number than on-hand quantity. is the quantity you can commit to a new order without breaking a commitment you have already made. It starts from what is physically on hand at a location, subtracts what is already allocated or committed to existing orders, and optionally adds inbound stock that has a confirmed arrival date. It is almost always a smaller number than on hand, and publishing on hand instead is the most common reason two customers get promised the same pallet.
- Can Shopify show an accurate delivery date for a backordered B2B item?
- Not from its own delivery date feature. Shopify documents that expected delivery dates are displayed at checkout if a product’s inventory exceeds zero, so the date disappears in exactly the case where the buyer needs it most. A backorder date depends on an inbound purchase order with a confirmed supplier date, which lives in Acumatica or Cin7, so showing one means passing that date to the storefront through an integration and displaying it yourself.
- Should a promise date reserve stock?
- Only at the point the buyer commits, and you should decide this explicitly rather than by default. Reserving stock when a date is displayed will strand inventory against carts that never convert. Reserving nothing until the order posts means two buyers can be shown the same date for the same last pallet. Most distributors land on showing available to promise without reserving, then allocating on order submission, and they tell the buyer that on the page.
- How do we handle a promise date for a made-to-order product?
- Do not compute one on the page. A made-to-order date depends on the production schedule, the configuration the buyer chose, and material availability, and no storefront holds those. The pattern that works is to show the current lead-time band, capture the order or quote, and commit to confirming a date within a stated response time. That converts better than an invented date and it does not put your operations team in the position of arguing with a website.
- Whose cutoff time applies, the platform’s or the warehouse’s?
- The warehouse’s, always, and this catches people out on Shopify specifically. Shopify documents that the business day cutoff for its delivery date calculation is 12pm in the local timezone of the shipping origin, which is unlikely to match your actual dispatch cutoff. If your real cutoff is 3pm, the platform will either under-promise or over-promise every afternoon order, so either compute the date yourself or change what you display.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.