There are two bottles of talcum powder left on the shelf. They are the same brand, the same size, the same price. One expires in October. One expires in November.

A customer buys one.

Your software now has a question it cannot answer on its own, and the answer decides whether every expiry figure in your system is worth anything at all: which bottle went out of the door?

That is the whole subject. Everything else — the reports, the alerts, the batch columns, the FIFO and FEFO settings — sits downstream of a person at a counter picking up one of two identical bottles and either knowing which one it is, or not.

The shelf has no memory

This is the thing that makes expiry tracking harder than it looks, and it is worth saying plainly because most software conversations skip it.

Your system can hold both dates perfectly. It knows there is one October bottle and one November bottle, because somebody entered them that way when the goods came in. The trouble is that the shelf does not know. Two bottles stand side by side looking exactly alike, and the moment a hand reaches for one of them, the system's careful record becomes a guess.

If the guess is wrong often enough, the stock figures drift apart from the shelf, the expiry report starts naming batches that were sold weeks ago, and somebody eventually stops opening it. Which is worse than never having had it, because for those weeks you believed it.

So the real question is never "can the software track expiry?" Every serious product can. The question is whether your counter can tell the software the truth, every time, without slowing down.

Where the cost actually lands

Expiry tracking has a cost, and the cost is not the software. It is time, and it lands in one specific place: goods inward.

Without expiry, receiving a delivery is one line per item. Forty cartons of soap, done. With expiry, it is one line per item per batch. If those forty cartons arrived as three production batches with three different dates, that is three lines, three dates read off three cartons, three quantities counted separately.

That is not a large amount of work. It is a small amount of work, repeated on every delivery, forever, by somebody who is usually in a hurry. And the person doing it gets no benefit from it at all — the benefit arrives months later, on a different screen, to a different person.

That separation is why shops get this decision wrong in both directions. The cost is visible daily and the benefit is invisible until the day it isn't, so purchase entry quietly falls behind, and dates start getting typed as whatever the last carton said.

FIFO, FEFO, and the day they disagree

Once dates are in the system, there is a second choice that sounds technical and is actually quite simple.

FIFO — first in, first out — sells whatever arrived earliest.

FEFO — first expired, first out — sells whatever expires soonest.

Most of the time these give the same answer, which is why people treat them as the same thing. They are not. They diverge the moment a later delivery arrives with an earlier expiry date, and that happens constantly: a supplier clearing older stock, a slow-moving line, a batch that sat in a distributor's godown before it reached you.

On that day FIFO will sell the older delivery and leave the sooner-expiring one on your shelf. FEFO will not. That single case is the entire reason FEFO exists, and it is why pharmaceutical and chemical distribution runs on FEFO rather than FIFO.

LIFO — last in, first out — sells the newest first. For anything perishable it is the wrong tool and will bury your oldest stock at the back. It has its uses in costing and in trades where the goods do not deteriorate, but if you are reading this for expiry reasons, FEFO is almost certainly what you want.

For some shops, this is not a decision

Before weighing anything up, it is worth knowing whether the decision has already been made for you.

A pharmacy does not get to choose. Rule 65 of the Drugs and Cosmetics Rules requires a retail licensee to keep purchase records showing the name of the drug, the quantity and the batch number, and for scheduled drugs, records carrying the manufacturer, the batch number and the date of expiry. Expired stock may not be sold or kept with the trade stock; where it is waiting to go back to the supplier, it has to be stored separately. Those records have to survive at least two years for inspection.

None of that is possible without batch and expiry in the system. For a pharmacy the question is not whether to track, it is how to make the tracking fast enough that the counter does not suffer.

Food carries a related obligation of a different shape. India's food recall framework reaches distributors and retailers, not only manufacturers, and a recall is only executable if you can say which batches you received and where they went. A shop that cannot identify affected lots cannot act on a recall notice in any meaningful way. If you handle packaged food at any scale, this is worth a conversation with whoever handles your compliance rather than a decision made on convenience.

For some shops, the shelf already tells you

At the other end there are trades where expiry tracking in software is close to pointless, and it is worth being just as honest about those.

Milk and fresh dairy. The date is measured in days. Stock turns over before any report could usefully warn you, and the person at the shelf can read the date faster than the system can be asked. Tracking it adds work and tells you nothing you did not already know by looking.

Bakery and anything made daily. Bread, sweets made in-house, tiffin items. The process is bake, sell, discard. There is no batch worth recording because nothing survives to a second day.

Fast-moving packaged goods with long dates. A biscuit packet with nine months on it, in a shop that sells the carton in three weeks, will never come close to expiry. The tracking would be technically correct and practically useless.

The common thread: where shelf life is far longer than shelf time, or so short that the eye handles it, the software has little to add.

The middle, where most shops actually live

Between those two ends sits the majority of Indian retail, and this is where the decision is genuinely difficult.

Cosmetics and personal care. Talcum powder, creams, shampoos, hair colour. Dates measured in years, movement measured in months, and a lot of money sitting on the shelf at any time. Slow enough to expire, valuable enough to hurt. This is the strongest case for tracking outside a pharmacy.

Packaged snacks, sauces, health foods. Six to twelve months, moderate movement, and a long tail of slow lines that sit there quietly. The fast-moving items do not need tracking. The tail does, and the tail is where the write-offs come from.

Baby food and infant formula. Short-dated, closely watched, and the one category where an expired sale is not a commercial problem but a reputational one. Most owners treat this separately regardless of what they do elsewhere.

Non-food that nobody thinks about. Batteries, adhesives, paints, photographic film, some agricultural inputs, certain automotive fluids. All carry dates. Almost nobody tracks them, and a slow-moving hardware or general store can be carrying dead stock for years without ever looking.

Medicines in a general store. Over-the-counter items in a kirana or general shop, where the owner is not running a pharmacy and does not have pharmacy processes. Small quantities, long dates, and no habit of checking. Worth a hard look.

The question that actually decides it

When an owner cannot make up his mind, this is the question we ask, and it usually settles it in under a minute:

If the system told you today that ₹40,000 of stock expires in six weeks, what would you actually do about it?

There are only a few honest answers.

"I would send it back." If your supplier takes near-expiry returns — and many distributors in food and pharma do, on terms — then the information is worth real money, and tracking pays for itself the first time you use it. This is the strongest case there is.

"I would discount it and move it." Worth something, though less. You are converting a total loss into a partial one, which is a genuine saving but a smaller one than the returns case.

"I would move it to the branch where it sells." Also worth real money, and a good reason to track if you run more than one location.

"Nothing. I would find out later and write it off." Then be honest: what you are buying is not a saving, it is earlier knowledge of the same loss. That has some value — you buy less of that line next time — but it is not worth batch entry on every delivery.

The value of expiry tracking depends almost entirely on whether you can act on it. Most articles on this subject skip that, and it is the thing that actually decides the answer.

The alternative nobody mentions: a strong manual process

There is a middle road that gets overlooked because it is not a software feature.

A disciplined physical process can do much of this work without any batch entry at all. Date-check one section of the shop each week, on a rota, so the whole shop is covered every month or two. Mark near-expiry stock with a coloured sticker as you find it. Keep a simple register of what went back to which supplier and when.

It is not as precise as the system. It misses things. But it is done by the person standing in front of the shelf, which is where the information actually is — and it does not slow down goods inward or the counter.

For a lot of shops this is the right answer, and saying so costs us nothing. A manual process that actually happens is worth more than a software feature that quietly stops being fed.

The way out is per item, not per shop

The choice is not tracking everything or tracking nothing, though it is almost always presented that way.

In Stock2Track, batch and expiry are switched on per item. So the cosmetics, the baby food and the slow-moving health lines carry batches, and the milk, the bread and the fast biscuits do not. Goods inward slows down for the twenty per cent of lines where it matters and stays fast for the rest.

The purchase entry is batch-wise where it needs to be, and the selling side then follows the rule you choose — FEFO for anything with a date you care about, FIFO or LIFO where they suit the trade better. The counter picks up the right batch by default rather than by memory, which takes us back to where this started: the two bottles.

Back to the two bottles

The October bottle and the November bottle are still on the shelf, and everything in this article is really about that moment.

If those two bottles are cosmetics in a shop that turns its stock in four months, track them. Scan the batch at billing so the record stays true, and let the system hand the October one over first.

If they are two packets of biscuits that will both be gone by Friday, do not. You would be paying at the receiving desk every day for a report nobody needs.

And if it is a pharmacy, the question was never yours to answer.

If you are not sure which of those describes your shop, that is a good first conversation to have with us — better than a feature list, and quicker. Tell us what you sell, how long it sits, and whether your suppliers take it back. The answer usually falls out of those three.

---

On the regulatory points: the pharmacy record-keeping requirements referred to are those in Rule 65 of the Drugs and Cosmetics Rules, 1945, and the food recall obligations are those under India's food recall framework. Both are summarised here in general terms for orientation only — we build software, not legal advice, and your own compliance adviser should be the one who tells you what applies to your licence.