Batch, Expiry and Recall Tracker
A pharmacy, clinic or distributor holding stock it received without recording batch numbers or expiry dates, discovering expired product on the shelf, and unable to answer a recall notice except by physically searching.
The problem
Two obligations — do not sell expired stock, and be able to trace a recalled batch — both depend on one record nobody is keeping.
In scope
- Batch capture at receiving
- Expiry tracking and alerting
- First-expiry-first-out picking
- Quarantine and write-off
- Recall trace
- Expiry exposure reporting
Out of scope
- Point of sale
- Dispensing
- Purchasing
- Pricing
- Patient records
- This is the smallest concept in the set and does one thing: it knows what batches exist, where they are, when they expire and where they went.
What this would cover
Grouped by module — open the ones you want to read.
Receiving
- Batch number, expiry date, quantity, supplier and invoice captured at intake, with barcode scanning where the packaging supports it
Batch register
- Every batch held, its location, its quantity and its expiry
Expiry alerting
- Configurable horizons (ninety, sixty, thirty days), with exposure valued in money so the alert carries weight
Picking
- First-expiry-first-out suggested, with an override that is logged
Quarantine
- A state that removes a batch from availability without deleting it, for expired, damaged, recalled or suspect stock
Write-off
- With reason, authorisation and value, feeding a loss report
Recall trace
- Enter a batch number and see quantity received, quantity remaining, where it is, and where it went, in seconds
Reporting
- Expiry exposure by horizon, write-off value by period and reason, supplier short-dating analysis showing which supplier consistently ships stock close to expiry
Data model
- Product
- Batch → BatchLocation → Quantity
- GoodsReceipt
- StockMovement
- Quarantine → Reason
- WriteOff → Authorisation
- RecallNotice → TraceResult
Invariants
- A batch is the atomic stock unit; quantity is never held against a product alone.
- Expiry is captured at receiving, not inferred or estimated.
- Quarantine never deletes — a recalled batch must remain traceable after it is removed from sale.
- Every movement records a person.
Offline behavior
Receiving and picking should work offline on a phone in a stockroom, queued.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
This concept asks a business to do additional work at receiving in exchange for a benefit that is invisible until the day it matters.
Nobody thanks the system on a normal day. It pays for itself the first time a recall notice arrives, or the first time a ninety-day alert clears stock that would have expired. That is a genuinely hard sale, and the honest framing is the expiry write-off figure — most businesses have never calculated it, and once they do, the case makes itself.
Existing stock has no batch data.
The options are a full stock take capturing batches, which is a real cost, or forward-only capture with the existing shelf remaining opaque until it turns over. Most choose forward-only; they should choose it knowingly.
End state
What would be true about their day once this is running.
- Every batch received has a number, an expiry and a location.
- Stock approaching expiry is a costed alert with time to act.
- Picking defaults to first-expiry-first-out.
- A recall notice is answered in minutes from a screen rather than by searching shelves.
- The business knows what it writes off each year and which supplier ships short-dated stock.
This is a deliberate first step toward Pharmacy Retail and Dispensing Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review