Guide

Allocated vs. available inventory

The number on the warehouse shelf and the number a rep can promise are different numbers. Here is what sits between them, when stock moves from one to the other, and how two reps end up selling the same last case.

Six numbers, one shelf

Ask three people in a distributor how much of a wine there is and you get three answers: what the warehouse counted, what the system says, and what a rep thinks they can sell. All three can be right, because they are answering different questions.

Inventory buckets for a wine distributor and what moves them
NumberWhat it meansWhat moves it
On handBottles physically in the warehouse, per locationUp on receiving; down on delivery, samples, breakage, and adjustments
AllocatedBottles promised to confirmed orders not yet deliveredUp when an order is confirmed; down when it is delivered or cancelled
HeldBottles on hand that are not for sale right nowSet and released deliberately: vintage release, supplier hold, set-aside for an account
AvailableOn hand minus allocated minus held. The only number a rep sells fromDerived; changes whenever any of the three above changes
InboundBottles on open purchase orders or transfers in transit to this warehouseDown as receipts post; becomes on hand at the dock
BackorderedConfirmed demand with no stock to allocateFills from receipts in a defined order, becoming allocated as it does

Everything is counted in bottles, per warehouse. Cases are derived from the SKU's pack size, as the case and bottle math guide explains.

Why on hand is the wrong number to sell from

The classic distributor failure: two reps, one afternoon, the same last six bottles of a wine two accounts want. Each rep checks the number, sees six, and promises six. The warehouse finds out tomorrow. One account gets a call nobody wants to make, and the number on screen is worth a little less to every rep from then on.

It happens because the rep was shown on hand, and on hand does not know about the order the other rep confirmed an hour ago. It gets worse with a month-end count or a nightly sync, where the number is also stale by however long it has been since the last update. The fix is not a faster sync. It is showing reps available, computed from the orders themselves, at the moment they look.

When stock becomes allocated, and when it stops

  1. Draft. A rep is writing the order. Nothing is allocated; available is unchanged for everyone else.
  2. Confirmed. The order is submitted. Every line with stock allocates its quantity, and every other rep's available drops by that much immediately. A line with no stock does not allocate; it goes to backorder.
  3. Picked and ready to deliver. Still allocated. The bottles may be on a pallet, but they are on hand until the truck leaves.
  4. Delivered. On hand drops, allocation is released, and the depletion is recorded. This is the moment inventory actually leaves.
  5. Cancelled or reduced. Allocation is released back to available. If a cancellation path forgets this step, the stock stays promised to nobody.

Two edge cases deserve a rule of their own. An order awaiting approval or confirmation can be given a deadline, and when the deadline passes the stock is released while the order itself stays, so a stalled approval never quietly cancels a sale. And a delivery that finds less stock than allocated should ship what is there and move the shortfall to backorder rather than blocking the whole order.

Holds: on the shelf, not for sale

A hold takes stock out of available without allocating it. Common reasons: a new vintage received but not yet released to reps; a supplier asking that an allocation be held for a program launch; a quality question; or bottles set aside for a specific account ahead of its order. A hold can cover the whole SKU or a quantity of it.

Holds are deliberate, which is their strength and their risk. They protect stock from being sold by accident, and they are forgotten more often than any other inventory state. Every hold should carry a reason and a person, and the list of active holds should be reviewed on a schedule.

A worked example

A wine has 120 bottles on hand at the main warehouse. Three confirmed orders total 36 bottles. Twelve bottles are held for a restaurant's wine dinner next week. A purchase order for 60 more is due Thursday.

  • On hand: 120
  • Allocated: 36
  • Held: 12
  • Available: 120 minus 36 minus 12, so 72
  • Inbound: 60, not available until it is received

A rep can promise 72 today. A rep who sees 120 promises too much. A rep who sees 132 because someone added the inbound purchase order promises wine that is on a truck somewhere. If an order for 80 arrives, 72 allocate and 8 go to backorder, to be filled Thursday when the 60 land, and available reads 0 until then.

Where it goes wrong

  • Selling from on hand. The root cause of every double promise.
  • Allocated as a stored counter. One code path or one manual edit that skips the decrement, and the number drifts silently until the next physical count.
  • Drafts that allocate. Abandoned drafts tie up stock nobody will ship.
  • Cancellations that do not release. Especially cancellations done through a side door: an admin edit, a direct database fix, an import.
  • Inbound counted as available. A container on the water is not on the shelf.
  • Samples that skip the ledger. Bottles that leave for sampling without a record leave on hand wrong, and everything downstream of it.
  • One number across warehouses. Available is per location; a case in the second warehouse cannot ship on tomorrow's route from the first.
  • Holds with no owner, which become permanent by neglect.

How PYLR does it

PYLR keeps on hand in bottles per warehouse and computes allocated at read time by summing the lines of open confirmed orders, those that are pending, picked, or ready to deliver, rather than trusting a stored counter. A counter is kept for speed and reconciled against that calculation on a schedule, so it cannot drift unnoticed. Holds block sellability whether they cover the SKU or a quantity of it. Backordered lines are demand, not allocation, and fill when stock is received. Inbound purchase orders and transfers in transit are shown as arriving, never as available. When a delivery finds a shortfall it ships what is on hand and backorders the rest, and every write path that touches an order line goes through the same allocation rules, including cancellations.

See wine inventory management software for the product side, and the depletion report guide for what happens to these numbers after delivery.

Frequently asked questions

What is the difference between allocated and available?

Allocated is stock already promised to confirmed orders that have not been delivered yet. Available is what is left to promise: on hand minus allocated minus anything on hold. A rep should only ever sell from available.

Does a draft order allocate stock?

No. Allocation starts when an order is confirmed and ends when it is delivered or cancelled. A draft is a note; if drafts allocated, abandoned drafts would quietly lock up inventory nobody intends to ship.

Why is available less than on hand minus allocated?

Holds. A wine can be physically in the warehouse and not promised to anyone, yet still not sellable: a new vintage not yet released, a supplier-directed hold, a quality hold, or stock set aside for a specific account. Holds reduce available without being allocated.

Can available go negative?

It should not. If demand exceeds stock, the excess belongs on backorder, where it is visible, waiting, and not counted against inventory. A negative available number means the system let a promise through that it could not keep.

What happens to backorders when stock arrives?

They should be filled in a defined order, oldest first or by priority, and each filled line becomes allocated at that moment. Until then a backordered line is demand, not allocation, so it does not reduce available.

Should allocated be a stored number or a calculation?

A calculation from the open orders themselves. A stored counter that is incremented and decremented on every order event drifts the first time one path forgets to update it, and drift is invisible until a rep promises stock that is not there. Recompute it from source records, and if a counter is kept for speed, reconcile it against the calculation on a schedule.

Built on community and referrals.

Reps selling from a number that was true this morning? Tell us about your warehouse and we'll show you available computed live from your own orders.

Two quick details — we'll figure out the rest, and a real person replies within a day.

Prefer email? hello@getpylr.com