Skip to main content
Back to Blog
Automation8 min read02.09.2026Sophera Consulting

Your stock figure knows the quantity, not the date

Availability checks return a count. Whether that stock still meets the remaining shelf life your customer contracted for is a different question, and it usually gets answered at their receiving dock.

This article was generated by AI. Labelled in accordance with Article 50 of the EU AI Act. Responsible for publication: Sophera Consulting.

The most expensive place to discover a shelf life problem is a customer's receiving dock. The truck is there, the pallet is off it, a scanner reads a date, and ninety of the two hundred packs go straight back on. Everything that follows costs money: the return leg, the credit note, the replacement order, the complaint ticket, and stock that is now six weeks older than it was this morning.

Nothing in that chain was broken. The stock figure was right, the picking rule was right. The promise was wrong, and it was made four steps earlier.

Availability is a count, not a date

Ask any ERP whether you can ship 200 units and it answers with a number. 240 available, warehouse 03. That number is blind to time.

For fasteners this does not matter. For reagents, infusion solutions, sterile goods or food it is the whole question, because a good part of that stock may be unsellable to the customer who is asking.

In the case above, 90 of the 240 packs belonged to a batch expiring in seven weeks. The customer's framework agreement required at least six months of remaining shelf life on delivery. That requirement lived in a contract PDF on a shared drive. The order entry screen never saw it.

Expiry date and remaining shelf life are different things

The expiry date belongs to the batch. It is printed on the carton, it sits in the batch record, and it is a property of the goods.

Remaining shelf life is a commitment between you and one particular customer, evaluated on one particular day. Two thirds of total shelf life, six months minimum, twelve months minimum on delivery: these are contract terms, and they vary by customer, sometimes by product group within the same customer.

Hospital procurement writes clauses like this routinely, and so do public tenders. Almost none of them end up as a field in the customer master, because the standard customer master has nowhere to put them.

For a while that is survivable. The shipping supervisor knows which three accounts are strict. Then that person retires, or the number of strict accounts grows past what anyone carries in their head.

FEFO does not solve this

Warehouse systems pick first expired, first out. That part usually works.

But FEFO answers a narrow question: which batch leaves the shelf next. It says nothing about which order should receive which batch.

If twelve orders are released in the morning and three of them belong to customers with a shelf life clause, FEFO hands the oldest batches to whoever gets picked first. Whether that customer is contractually allowed to accept old stock never enters the calculation.

The usual proposal at this point is a workflow that inspects batch data after picking and raises a warning. It is better than nothing, and it is still a check at the end of a chain where the wrong decision was made at the beginning.

Blocked stock is a late signal

Expired stock gets blocked. Every business handling dated goods has this, typically as an overnight job comparing expiry date to today's date.

The date on which stock becomes commercially dead, though, arrives well before expiry. If most of your customers demand six months, a batch with five months left is already unsellable to them. The system still shows it as free stock, and it still counts in every availability answer you give.

That stock hurts twice. It suppresses replenishment because it looks like inventory, and it cannot be shipped to the customers who want the product.

Automating this needs two thresholds rather than one: the actual expiry date for blocking, and an earlier threshold that alerts sales and purchasing. What happens at that earlier point is a commercial call. Sell it to accounts without a clause, discount it, return it to the manufacturer if the supply agreement allows.

The point where automation pays

It pays at order entry, and it needs three things that many companies do not hold as data.

First, the shelf life requirement per customer, expressed as a number of days or months, in the customer master or a table beside it. A contract document on a drive does not exist as far as any workflow is concerned.

Second, batch level stock with dates in the availability answer. Not 240 units, but 150 expiring in March and 90 expiring in October.

Third, a calculation anchored to the planned delivery date. A batch that satisfies the requirement today can fail it against a delivery date four weeks out. Checking against today instead of the delivery date is one of the more common defects we find in workflows of this kind.

With those in place the logic itself is dull. Check the order against the stock that meets the requirement rather than against total stock. If that stock is short, route the order to a human before an acknowledgement leaves the building.

A same day phone call to a contract customer is cheaper than an acknowledgement you cannot honour.

Allocation is the second lever

Customers with strict clauses should get the newest stock. Customers without them should get the oldest. That is the inverse of what FEFO does when it has no additional information.

Practically, this means allocating batches when the order is created rather than when it is picked. Most ERP systems support it, usually as batch reservation, and in many companies the feature is switched off because it is considered fiddly day to day.

It is fiddly, as long as a person does it. That is exactly the kind of work worth automating, because the allocation follows a rule you can write down.

The same gap exists on the inbound side

Whatever you promise your customers, your suppliers have to promise you. Guarantee six months and accept goods with four, and you have bought the problem.

Goods receipt usually captures the expiry date, because batch management needs it. It rarely checks that date against a stored minimum. The stock is booked before anyone does the arithmetic.

The check is the easy part: expiry date minus posting date, compared to a minimum shelf life held in the item or supplier master. What is missing is normally the field to compare against.

Whether to accept or reject such a delivery is not a decision for a workflow. It belongs to purchasing, because it depends on the supplier relationship and on whether an alternative exists. The workflow's job is to raise the question while the driver is still at the dock.

Three things to check in your own data

Pull twelve months of complaints and filter for rejections on shelf life grounds. Count the goods value and the number of distinct customers affected, not the number of cases. Five cases across five customers is a different problem from five cases at one account.

Then look at the customer master. How many contract customers have a shelf life requirement stored as a field? If the answer is none, the requirement only exists in people's heads.

Finally, pull batch stock with expiry dates and work out how much value sits in batches below the strictest requirement in your customer base. No standard inventory report shows this, because inventory reports show quantities and values, never sellability.

#Mindesthaltbarkeitsdatum#Restlaufzeit#FEFO#Chargen#Verfügbarkeit#Wareneingang#Großhandel#Klinik#Logistik#ERP#Make#n8n