Stock reservation rules: when to hold, release, and fulfill

A customer has an item in checkout while a sales assistant is confirming another order for the same stock. Both screens show availability. Which order gets the units?

A stock reservation gives a specific order a temporary claim on a defined quantity. It needs a start point, an expiry rule, and a reliable way to become fulfilled or released. Without those rules, goods can remain physically on the shelf while being promised twice, or stay unavailable long after an abandoned order.

This guide focuses on that reservation lifecycle. For the wider movement and reconciliation model, read the multi-branch inventory planning guide.

Separate stock on hand from stock you can still sell

On-hand stock records what is physically held at a location. Sellable stock is the quantity your rules allow another customer to order now. A reservation reduces sellable stock without moving goods out of the building.

For a simple operation that sells only received stock, use this starting rule:

Sellable quantity = on hand − active reservations − other unavailable units.

Keep those deductions separate. Damaged goods, quality holds, and safety stock must not also be counted as active reservations. Incoming goods belong outside this calculation unless you deliberately offer a separate preorder promise.

Consider a hypothetical item with 12 units on hand. Two are damaged and four are reserved. Six remain sellable. Releasing that reservation makes ten sellable; it does not increase the physical count. If you dispatch the four reserved units instead of releasing the reservation, eight remain on hand and six remain sellable.

Decide exactly when a hold begins

Adding a product to a cart does not have to reserve it. An operation might start a short hold at checkout, when staff approve a quotation, or when an order passes an availability check. Choose the event that matches the promise customers receive.

Record each reservation against an order line, product, stock location, and quantity. Include its creation time, expiry time where applicable, and status. Staff should be able to answer who holds the units and what will release them without searching messages.

Separate a temporary checkout hold from an accepted order awaiting fulfillment. They may need different expiry rules. A paid order should not silently lose its allocation because the original checkout timer kept running.

Make expiry a stock operation

Show customers when a temporary hold ends, using a clear time zone for cross-border orders. Decide whether staff may extend it, under what conditions, and who can approve the change. Log the original deadline and the extension.

At expiry, the system must check that the reservation is still eligible for release before returning its remaining quantity to sellable stock. Payment confirmation, cancellation, and expiry can arrive close together. Only one valid transition should take effect.

For example, if a hold expires before a delayed payment confirmation arrives, do not automatically recreate the reservation. Check availability again. If the stock has gone to another order, route the case to an owner for an alternative or refund decision.

A failed expiry job also needs attention. Give staff a view of overdue holds and make the release operation safe to retry, so a second attempt cannot release the same units again.

Fulfill only the quantity that actually leaves

Partial fulfillment needs line-level quantities rather than one order-wide “complete” button.

Suppose, in another hypothetical order, six units are reserved and four ship today. Reduce on-hand stock by four and consume four units of the reservation. The other two remain reserved if the customer is still waiting for them. Do not release all six or deduct the shipped four twice.

If the customer cancels the remaining two, release those two only. If they move to a different fulfillment location, record a controlled reassignment rather than temporarily promising both locations' stock. Goods already dispatched require a return process; canceling their reservation cannot put them back on the shelf.

Stop two orders from claiming the same units

A refreshed dashboard cannot prevent concurrent overselling by itself. Two requests can read the same quantity before either saves its reservation.

Ask your developer to make the availability check and reservation update one protected operation. Depending on the database, that may use a transaction with appropriate locking or a conditional update. If one request claims the last unit, the competing request must receive an unavailable response or an explicitly permitted backorder outcome.

Give each reservation request a stable identifier. Retrying after a slow connection should return the existing result, not create a second hold. This duplicate protection and the concurrency check solve different problems; both matter.

Every selling channel must follow the same authority for the stock it shares. If an offline counter cannot check that authority, define a separate allocation or a restricted selling policy instead of assuming later synchronization will prevent overselling.

Test the difficult transitions before launch

Use a small set of orders to check:

• Two simultaneous requests for the last unit produce only one reservation.
• A repeated request returns the original hold.
• Expiry and payment arriving together produce one consistent outcome.
• Partial shipment leaves the correct remainder reserved.
• Repeated cancellation or expiry does not add stock twice.
• An overdue hold is visible to the person responsible for resolving it.

Bring these cases into your inventory and warehouse management system brief. If your team is still resolving holds through spreadsheets or chat, share one reservation workflow with Rootscratch, including where the customer promise begins and who can release it.

Cover image: AI-generated editorial illustration; not a real client, deployed product, or product screenshot.