Free AuditEnterprise AIShelfSense
Back to Blog
TechnologyFeb 202613 min read

Batch-Level Expiry Tracking: Why SKU-Level Falls Short

One product can have 5 different expiry dates. SKU-level tracking misses this. Why batch-level tracking is essential for perishables.

Your inventory system says you have 42 units. It does not say that 15 of them expire next week.

Here is a situation that plays out in retail stores and pharmacies across India every single day. The system shows 42 units of a product in stock. A customer buys one. The system shows 41. Another purchase. 40. Everything looks fine. The stock level is healthy, the reorder point is not triggered, and nobody has any reason to look more closely.

Then a staff member doing a shelf check pulls 15 units that expired three days ago. Now you actually have 25 sellable units, not 40. And those 15 expired units represent a complete loss — product cost, shelf space, working capital, the lot.

The system was not wrong. You did have 42 units. Then 41. Then 40. The system knew the quantity. What it did not know — because it was never told — was that those 42 units were not a single, uniform pool of identical products. They were three different batches with three different expiry dates, and one of those batches was about to die.

This is the fundamental limitation of SKU-level inventory tracking, and it is the reason that SKU-level is structurally insufficient for any business that sells products with expiry dates.

Free Tool

Not sure how much you're losing to expiry?

Run a free inventory waste audit — find your bleeding SKUs in 60 seconds. No sign-up required.

Run free audit

What SKU-level tracking actually tracks

A SKU (Stock Keeping Unit) is a unique identifier for a product. One SKU for Amul Taaza 500ml. One SKU for Tata Salt 1kg. One SKU for Crocin Advance 15-strip. When a unit is received, the SKU quantity increases. When a unit is sold, it decreases. The system maintains a running count.

This is useful. It tells you how much of each product you have. It enables reorder point calculations, sales velocity analysis, and dead stock identification. For products that do not expire — or whose shelf lives are so long that expiry is never a practical concern — SKU-level tracking is entirely adequate.

The problem begins the moment a product has a shelf life that matters. Because a SKU, by definition, treats all units of a product as interchangeable. 42 units of Amul Taaza 500ml is 42 units of Amul Taaza 500ml. The system does not distinguish between the 15 units expiring next Tuesday and the 27 units expiring next month. They are all just "Amul Taaza 500ml," and they all count the same.

Why the same SKU has different expiry dates

This is the point that many store owners initially resist. "Same product, same manufacturer, same expiry," they assume. This assumption is incorrect, and understanding why it is incorrect is essential.

Manufacturing happens in batches

A manufacturer does not produce one continuous stream of product. They produce in batches — discrete production runs. Each batch gets a batch number and a manufacturing date. The expiry date is calculated from the manufacturing date (manufacturing date plus shelf life equals expiry date).

A product manufactured on January 5 and given a 12-month shelf life expires on January 4 of the following year. The same product manufactured on February 20 expires on February 19. Same product. Same manufacturer. Same SKU. Different expiry dates — six weeks apart.

You receive from multiple batches

Your distributor does not maintain single-batch purity. Their warehouse has stock from multiple manufacturing batches. When they fulfil your order, they pick from whatever is available. Monday's delivery to your store might contain Batch A (manufactured January) and Batch B (manufactured March) in the same carton. Your store now has two different expiry dates on the same shelf, for the same SKU, often physically mixed together.

Multiple suppliers amplify the variation

If you source a product from two different distributors — which is common in Indian retail, especially for high-demand staples — the batch variation doubles. Distributor 1 sends stock from Batch X (expiry September). Distributor 2 sends stock from Batch Y (expiry June). Same product. Three months apart in expiry. A SKU-level system sees only "received 50 units." It has no idea that 30 of those units expire three months after the other 20.

The pharmacy example: identical medicine, wildly different dates

Pharmacies experience this at an extreme level. Consider a common antibiotic — say, Augmentin 625mg. A busy pharmacy might carry stock from two or three distributors, each supplying batches from different manufacturing runs. It is entirely normal to have the following on the same shelf:

  • 2 strips from Batch P — expiry April 2025
  • 5 strips from Batch Q — expiry September 2025
  • 3 strips from Batch R — expiry January 2026

That is one SKU with three expiry dates spanning 9 months. Under SKU-level tracking, the system shows "10 strips of Augmentin 625mg." It cannot tell you that 2 of those strips expire in two months. It cannot alert you to return them to the distributor before the return window closes. It cannot ensure that those 2 strips are dispensed before the other 8.

The supermarket staple example: same dal, different lives

A supermarket stocks Toor Dal 1kg from a well-known brand. The product has a printed shelf life of 12 months. On the shelf:

  • 30 packets from a delivery three weeks ago — manufactured October 2024, expiry October 2025
  • 20 packets from a delivery yesterday — manufactured June 2024, expiry June 2025

The fresher delivery (yesterday) actually has the shorter remaining shelf life, because the manufacturing date was earlier. Under SKU-level tracking: "50 packets of Toor Dal 1kg." Under batch-level tracking: "30 packets expiring October 2025, 20 packets expiring June 2025 — sell the June batch first."

Without batch-level information, the June batch sits behind the October batch on the shelf. Staff sell the front-facing (October) stock because it is easier to reach. The June stock ages quietly in the back. By the time someone notices, the return window may have passed, and the markdown window is narrowing.

What batch-level tracking actually requires

Batch-level tracking adds one layer of data below the SKU level. Instead of just "Product X: 42 units," the system records:

  • Product X, Batch A: 15 units, expiry date March 15, 2025
  • Product X, Batch B: 12 units, expiry date May 22, 2025
  • Product X, Batch C: 15 units, expiry date August 8, 2025

This enables everything that SKU-level tracking cannot do:

FEFO (First Expiry, First Out) rotation

The system knows which batch expires first and can direct staff (or automated processes) to sell that batch before others. Without batch-level data, FEFO is impossible to implement systematically — you can tell staff to "check dates and sell the oldest," but you have no system-level enforcement, no reporting on whether it is actually happening, and no way to catch errors until they result in expired stock.

Proactive expiry alerts

"You have 15 units of Product X expiring in 21 days" is actionable. "You have 42 units of Product X" is not. Batch-level tracking enables time-based alerts that give you enough lead time to take action — return to supplier, mark down for quick sale, move to the clearance zone — before the product expires.

Accurate inventory valuation

15 units expiring next week are not worth the same as 15 units expiring in six months, even though they have the same cost price. Batch-level tracking allows for more accurate inventory valuation that reflects the real economic value of your stock, not just the quantity.

Supplier return management

Distributor return policies specify a minimum remaining shelf life for returns (typically 3-6 months). Without batch-level data, you cannot systematically identify which stock is approaching the return window until someone physically checks the shelf. With batch-level data, the system flags returnable stock automatically, giving you time to prepare returns before the window closes.

Regulatory compliance

For pharmacies, the Drugs and Cosmetics Act requires batch-level record-keeping for scheduled drugs. Drug inspectors expect to see batch numbers in purchase and sales records. A pharmacy operating at SKU-level tracking is not just at risk of waste — it is at risk of compliance findings during inspections.

For food retailers, FSSAI traceability requirements are moving toward greater specificity. Batch-level records that can trace a product from receipt to sale (or disposal) are increasingly becoming the standard expected during audits.

The objections, and why they are weaker than they appear

"It is too much data entry"

This is the most common objection, and it has the most merit. Recording expiry dates for every batch at receiving does take time. For a store processing 200-300 line items per day in deliveries, adding expiry date capture adds roughly 30-60 minutes to the daily receiving process.

However, this needs to be weighed against the time currently spent on reactive expiry management — shelf checks to find expired products, processing write-offs, handling supplier returns that could have been caught earlier, and dealing with compliance issues. Most stores that switch to batch-level tracking find that the upfront data entry time is offset by reduced time spent on damage control.

Technology also reduces the burden. Invoice OCR (scanning the invoice and extracting batch and expiry data automatically) can cut data entry time significantly. Barcode scanning of products with batch-encoded barcodes is another path. The friction of manual data entry is real but diminishing.

"My POS system does not support batch tracking"

Many legacy POS systems in India — Marg, Busy, and others — were built around SKU-level inventory management. Batch-level tracking may be available as a module or add-on but is not always enabled by default.

If your POS system truly does not support batch tracking, you have two options: supplement it with a dedicated batch-tracking tool that operates alongside your POS, or migrate to a system that supports batch-level management natively. The first option is less disruptive. The second is more comprehensive.

"It is not worth it for our scale"

For a store with 200 SKUs and low perishable exposure, this may be true. The manual overhead of batch tracking might exceed the waste it prevents.

But for any store carrying more than 500 SKUs with meaningful perishable or medium-shelf-life categories — which includes most supermarkets, most pharmacies, and most FMCG distributors — the math consistently favours batch-level tracking. The waste prevented, the returns captured, and the compliance risk avoided are worth significantly more than the cost of implementation.

Implementing batch-level tracking: A practical path

Phase 1: Start with high-risk categories

Do not try to implement batch tracking across your entire inventory on day one. Start with the categories where expiry waste is highest: dairy, fresh produce, bakery items, and near-expiry pharmaceuticals. These are the categories where the gap between SKU-level and batch-level tracking is largest and the payoff from closing that gap is fastest.

Phase 2: Build the receiving discipline

Train your receiving staff to capture batch numbers and expiry dates for every delivery in the target categories. Provide a simple format — a register, a spreadsheet, or ideally, a digital input form tied to your inventory system. Check compliance daily for the first month. If the data is not captured at receiving, it does not exist downstream.

Phase 3: Enable expiry alerts

Once batch data is flowing into your system, configure alerts. Start simple: a daily report showing all batches expiring within 30 days. Review this report every morning. Act on it: initiate returns, apply markdowns, reposition products. The alert is only valuable if it triggers action.

Phase 4: Extend to more categories

Once the discipline is established in high-risk categories, extend batch tracking to packaged foods, snacks, personal care products, and any other category where you have observed meaningful expiry waste. Each extension is easier than the first because your staff already understands the process.

Phase 5: Integrate with purchasing decisions

The ultimate value of batch-level data is not just preventing waste on existing stock. It is informing purchasing decisions. When you can see that you have 60 days of supply remaining for a product, and 40% of that supply expires within 20 days, you know not to reorder yet. SKU-level data would show "healthy stock level, no reorder needed" and might even have you ordering more — adding to the pile of eventually-expiring inventory.

The right tool for the job

Batch-level tracking is conceptually simple but operationally demanding. The volume of data — batch numbers, expiry dates, quantities per batch, across thousands of SKUs — is beyond what manual systems can maintain reliably at scale.

ShelfLifePro was built specifically for this problem: tracking inventory at the batch level, with expiry dates as a core data point rather than an afterthought. It handles the data capture, the FEFO logic, the alerting, and the reporting that make batch-level management practical for real-world retail operations. If your current system tracks only at the SKU level and you are losing money to expiry waste, a batch-level tool is worth evaluating.

The core truth

SKU-level tracking tells you how much you have. Batch-level tracking tells you how much you have and how long each unit will last. For any business selling products that expire — and that includes virtually every grocery store, supermarket, pharmacy, and FMCG distributor in India — the second piece of information is not optional. It is the difference between knowing your inventory and understanding your inventory. And understanding is what prevents waste.

See what batch-level tracking actually looks like

ShelfLifePro tracks expiry by batch, automates FEFO rotation, and sends markdown alerts before stock expires. 14-day free trial, no credit card required.