The warehouse management system in a chilled finished-goods store says the product is there, and the dates on the cases agree. The picker sent for a retailer’s order still comes back with a pallet they were told not to touch, and customer service finds out the order went short after the vehicle has left. The manager who answers for picking, dispatch and stock accuracy puts the question plainly: the stock is in the building and in date, so why can it not be shipped, and why does the system keep offering pickers pallets they cannot use?

The word doing the damage is “available”. In much food warehouse software it means on the racking, not yet allocated, and dated later than today. In a food warehouse that is not enough to tell you whether a case may go on a truck. Whether it may depends on the order it would go to: the batch’s release state, the batch’s remaining life on the day that customer receives it measured against that customer’s rule, and where the stock physically is. Those three facts change independently, so a system that folds them into one number leaves the manager to unfold them by hand with hold tags, a daily allocation spreadsheet and a QA colleague walking the racks. Getting this wrong when specifying a system means paying for a WMS and still running the spreadsheet.

Three facts a single quantity hides

A batch, or lot, is a quantity produced or received together. Its cases share a production date, a shelf life and a quality history, and traceability records travel at batch level. The decisions below are made about batches, and then about which batch may go to which order.

Release state is the quality decision about a batch. Under positive release, nothing from a batch ships until quality has confirmed it may, typically once micro results or other checks have come back. A hold freezes a batch, whether or not it was previously released, while an investigation runs. Reject and recall are terminal. Release state is separate from how many cases the batch has and where they sit, and it changes over time: a batch can be awaiting release on Monday, released on Tuesday and on hold again on Wednesday. Each change has a reason, a person and a time behind it.

Remaining life at delivery is the shelf life minus the days that will have elapsed when the customer receives the goods, which is a different date from today. Two orders drawing on the same batch with different delivery dates have different remaining life, and the difference can decide whether one of them is acceptable.

A minimum-life rule is the customer’s requirement that goods arrive with at least a stated remaining life. Retailers commonly ask for more than foodservice or local customers do, and the rule belongs to the customer, sometimes to the customer and product together. Will this batch have enough shelf life at delivery? follows this rule from production through dispatch; here it is one input into an allocation decision.

FEFO, first expired first out, means picking the batch that expires soonest among those that qualify. The qualification carries the weight. FEFO applied to every batch on the racking sends the oldest stock to whichever order is first in the queue. FEFO applied after the qualifying set has been decided sends the oldest stock that this order can accept.

Why food separates presence from permission

In a chilled operation, stock reaches pickable racking before its release decision is made. Chilled space is expensive and dock time is short, so holding every incoming batch in a quarantine bay until the lab reports back is impractical for most sites. From the first hour, then, the batch is physically present and not yet permitted to ship. A system that equates presence with availability is wrong from the moment the pallet is put away.

The permission, once granted, is also not permanent. A seal complaint, a temperature excursion on a trailer, a micro result that arrives late or a supplier notice can put a released batch back on hold. If that batch has already been allocated to orders, the allocation made yesterday afternoon is wrong this morning.

And permission is not a single yes or no per batch. The same released batch may qualify for one customer’s delivery on Tuesday and fail another’s on Wednesday, because the customers hold different rules and the deliveries fall on different days. So the question “can this batch ship?” has no answer on its own. The question that has an answer is “can this batch go on this order line, for this delivery date, under this customer’s rule, from where it sits now?”, and it has to be asked once per line.

Allocating a morning’s orders

An illustrative scenario makes the arithmetic visible. Every quantity, day and customer rule is invented; no customer data is used. The operation is a chilled dessert manufacturer’s finished-goods store, with one product carrying 21 days of shelf life from the production day. Days count from Day 0.

On the morning of Day 5 there are three batches in pickable locations. Batch A was produced on Day 0 and has 30 cases, released. Batch B was produced on Day 3 and has 40 cases, released this morning after micro results cleared. Batch C was produced on Day 4 and has 40 cases, on hold since a sample failed a seal-integrity check and the investigation is open.

Two orders need allocating. Order 1 is for Retailer R: 40 cases, delivering on Day 8, and R requires at least 14 days remaining at delivery. Order 2 is for Foodservice F: 30 cases, delivering on Day 7, and F requires at least 7 days.

Three numbers now describe the same shelves. Physical stock is 110 cases. Released stock is 70. Usable for Order 1 is 40, because only B is released and meets R’s rule at Day 8. Usable for Order 2 is 70, because A and B both qualify for F at Day 7. Demand across the two orders is 70 cases and the released pool is 70 cases, so both orders can be filled whole, but only if A goes to F.

Consider what a queue-order allocation with a plain expiry filter does. Order 1 was entered first, so it is allocated first. Every batch is in date today, so nothing is excluded, and FEFO gives Order 1 the 30 cases of A plus 10 from B. Order 2 takes the remaining 30 from B. No warning appears, because every case allocated is in stock and in date. On Day 8, R’s receiving check finds 30 cases with 13 days remaining and refuses them. The vehicle returns with 30 cases of A, now at 13 days and falling, F has already been served from B, and A is discounted or written off.

Now consider a per-order usability rule. For each order line, keep only released batches, compute remaining life at that line’s delivery date, keep the batches that meet that customer’s rule, and take the oldest first. Order 1 can only use B, so it takes 40 from B. Order 2 can use A or B, and oldest first gives it all 30 from A. Both orders ship whole. The shortest-life released stock went to the one customer who could accept it, which is what “the right orders” means. Under this rule, A is an asset for F rather than a liability to be hidden behind fresher stock, and B is kept for the customer who has no alternative.

When the hold arrives after the allocation

The scenario continues. At 08:00 on Day 6, before picking starts, quality widens the seal investigation to Batch B, because B and C were sealed from the same film roll. B moves to hold. B is allocated in full to Order 1, and the pick list for Order 1 names B’s locations.

The system has to do three things at that moment. It must retract the allocation of B to Order 1, because the reason B qualified no longer holds. It must show Order 1 as 40 short, with the reasons visible: A fails R’s rule, B and C are on hold. And it must put that shortage in front of customer service while there is still time to call R, before the vehicle is loaded. Order 2’s allocation from A is untouched, because nothing about A changed.

If the system does not re-evaluate, the picker is sent to B’s location with yesterday’s task. What happens next depends on when release state is checked. A pick confirmation that reads the batch’s state at the moment of the scan will not confirm a pallet from a held batch, and the picker learns at the racking that something has changed. That is the last line of defence, and it is a poor place for the operation to discover a shortage, but it keeps the held stock in the building. A system that checked state only when the allocation was made confirms the pick, the pallet is loaded, and either R’s receiving team or a later recall finds out.

At 14:00 the investigation clears both batches and B and C return to released. Allocation runs again. Order 1 takes 40 from B, the oldest batch that qualifies. Order 2 was never affected. Dispatch on the evening of Day 6 goes ahead for Order 2 and, if the vehicle can still be made, for Order 1.

Two things follow from the morning. Allocation is a standing decision. Whenever one of its inputs changes it has to be revisited, and a system that treats it as a booking made once will send pickers to stock that no longer qualifies. And because quality recorded the hold in the same system that holds the allocations, it reached every open order at 08:00, rather than travelling by phone call and hold tag to whoever happened to be allocating that day.

What this asks of food warehouse software

The scenario turns into four checks a manager can put to any candidate system, whether a packaged WMS, an extension to an existing system or a platform implementation.

Does it hold release state as its own record, with history? Awaiting release, released, on hold and rejected should be states on the batch, separate from quantity and location, with who changed the state, when and why. A hold that is a note in a comments field or a location called QUARANTINE does not meet this, because nothing else in the system can act on it.

Does allocation apply the customer’s rule against the delivery date? The minimum-life rule should live on the customer, or on the customer and product together where they differ, and the allocation should compute remaining life at the order line’s delivery date and compare it with that rule. A single expiry cut-off applied to all orders cannot separate R from F.

Is allocation re-evaluated when release state changes? Placing a hold on a batch should retract or flag every open allocation that references it and show the resulting shortage, before picking. If re-planning after a hold means a person re-running the day’s allocation by hand, the system has recorded the hold without acting on it.

Does pick confirmation read release state at scan time? The scan should fail against a batch whose state is not released at that moment, whatever the pick list said when it was printed.

Not every food operation needs all four in software. If quality release is completed before stock reaches a pickable location, so that held stock sits in a quarantine bay and never shows as available, the first check is met physically. If every customer shares one minimum-life rule, a single expiry cut-off is enough and the second check falls away. If holds after allocation are rare and one planner allocates a day’s orders and can walk the racks, the third and fourth can be done by a person. In those settings a packaged WMS with batch tracking, a hold status and FEFO picking does the job, and choosing warehouse management software sets out how to compare packaged, extended and platform options against the work you actually need. The case for a platform appears when release happens after putaway, rules differ by customer and holds reach back to allocated stock, because then the decision has to be recomputed continuously across many order lines. That is a statement about the requirement, not about what any named product cannot do.

How Keel runs it

Keel is an operations platform shaped around how your business works. It turns your processes into clear, guided work for your team, with your rules and checks built in, and gives you the structure to run consistently as volume grows while keeping the freedom to change how you operate. For the manager of the dessert store, the daily gap between what is on the racking and what may be shipped is closed by the system instead of by hold tags and a spreadsheet. Stock is received and put away before quality has finished with it, release and hold decisions take effect everywhere at once, pickers are only sent to stock that is usable for that customer and that delivery date, and customer service sees a shortage while there is still time to act.

Suppose the dessert manufacturer implemented this on Keel. The planner would open an allocation view for each order line that lists every candidate batch with its remaining life at that line’s delivery date and, for each excluded batch, the reason: on hold, fails this customer’s rule, or not in a pickable location. The 110, 70 and 40 from the example are on the screen rather than in the planner’s head. Quality would complete a release task, and its completion moves the batch’s state and re-evaluates every open allocation touching that batch, so the Day 6 hold is one task completed by the quality team, and the warehouse learns of it from the allocation view rather than from a phone call. The picker’s task names batch and location and will not confirm a scan against a batch whose state is not released at that moment. And a dispatch view shows customer service the lines that are short after a hold, with the reason, before loading begins.

Three things in Keel make this possible. It supplies tailored operator experiences, so the planner’s allocation view, the quality release task and the picker’s task are built for those people and show only what they need. It supplies workflows that combine human steps, such as recording a release decision, with processing steps, such as re-evaluating allocations when a state changes. And it supplies business rules expressed in code, which is why the allocation rule can be exactly this operation’s rule: filter to released, compute remaining life at the line’s delivery date, apply the customer’s rule, order by expiry. The batch record carries release state as its own field with a dated history, the minimum-life rule sits on the customer or the customer-product pairing with the version that applied recorded on the order line, and permissions decide who may release or hold. Code needs implementation, testing and maintenance, which is the cost of that exactness.

What the implementation must build for this operation is the batch state model, the customer rule, the allocation logic, the quality, pick and dispatch experiences, and whatever is needed to bring in lab results or work with the finance system. Keel does not ship a food WMS, a release workflow or a connector to any named lab or finance system. Keel leads the implementation and agrees the handover with your team. Operations that also receive purchased ingredients under release will recognise the inbound version of the same separation, what arrived versus what may be used, in procurement software, and inventory management places “what can be used or sold” in the wider record from receipt to promise.

What to bring to a requirements conversation

Before talking to any vendor, write down how release, allocation and picking run in your operation today. Where does a batch physically sit between putaway and release, and how does the picker know? Who records a hold, where, and who has to be told? How many distinct minimum-life rules do your customers hold, and where are they written down? When a hold lands on stock that is already allocated, who re-plans, and how long does it take for the pick lists to change? Those answers tell you which of the four checks you need in software and which you can meet by other means.

Then take the answers to a requirements conversation. If release happens after putaway, rules differ by customer and holds reach allocated stock, talk through how release, allocation and picking run in your operation with Keel and we will work through where each rule should live and what the picker, the planner and quality should each see.