Tally Expiry Tracking: The Plugin Tally Doesn't Have

The search that 40,000 Indian retailers make every month — and the answer they never find

If you have ever typed "Tally expiry tracking plugin" into Google, you already know how this story goes. You get a handful of results. Some are forum threads from 2018 where someone asks if Tally can track batch-wise expiry, and the answer is a workaround involving custom voucher types. Some are YouTube videos showing how to enter batch numbers during purchase entry in Tally Prime, which technically works but solves about 15% of the actual problem. And some are links to third-party TDL customisations that cost ₹15,000-40,000, require a Tally developer to install, and break every time Tally pushes an update.

None of them give you what you actually need: a system that knows every batch of every product on your shelf, knows when each one expires, tells you before the return window closes, and makes sure the oldest batch gets billed first. Tally was never designed to do this. It is an accounting system — arguably the best accounting system for Indian businesses — and it handles ledgers, GST, invoicing, and financial reporting with remarkable capability. But inventory management in Tally, even in Tally Prime with all the bells and whistles enabled, treats stock as a quantity problem. How many units do you have. What did you pay for them. What is the valuation. These are accounting questions. Expiry tracking requires operational questions: which specific batch is expiring soonest, which batches need to ship before the distributor return window closes, and which physical units on which shelf should the billing clerk pick right now.

These are fundamentally different categories of questions, and Tally does not answer the second category. Not because Tally is a bad product. Because Tally is an accounting product.

What Tally Prime actually does with batch information (and where it stops)

There is a lot of confusion about what Tally can and cannot do with batch data, and the confusion leads people to try solutions that were never going to work.

Tally Prime allows you to enable batch-wise tracking for stock items. When this feature is turned on, during a purchase voucher entry you can specify a batch number, manufacturing date, and expiry date for each line item. The data gets stored. You can view it in stock reports. This is the part that works.

Here is where it stops working. Tally does not generate alerts when batches approach expiry. There is no dashboard that shows you "47 batches expiring in the next 90 days, total value ₹2.3 lakhs." There is no notification system — no email, no SMS, no WhatsApp message at 7 AM telling you that the return window for a specific set of batches closes this week. To find near-expiry stock in Tally, you have to actively go looking for it, running stock summary reports, filtering by batch, and manually checking dates. This is the equivalent of having a fire alarm that only works if you walk to it and press a button to ask whether the building is on fire.

Tally does not enforce FEFO (First Expiry, First Out) during billing. When a sales voucher is created, Tally can be configured to auto-select the batch with the lowest stock or the batch received first (FIFO). But it does not automatically select the batch expiring soonest. This means your billing clerk may be selling stock with a March 2027 expiry while a batch with a September 2025 expiry sits untouched on the shelf. Tally deducts from inventory in the order it was programmed to deduct, and that order does not consider expiry unless someone manually selects the right batch during every single transaction.

Tally does not connect batch data to GRN (Goods Receipt Note) workflows in a way that enables return planning. When you receive a purchase of 500 units across four batches with different expiry dates, Tally records the data. But it does not calculate that Batch A has a distributor return window closing in 4 months based on its expiry, or that Batch D's expiry falls within the monsoon season when demand for that category drops 30%. This kind of intelligence requires a layer that Tally does not have and was never built to have.

For Tally.ERP 9 users — and there are still lakhs of businesses running ERP 9 because the migration to Prime is expensive and disruptive — the limitations are even more pronounced. Batch tracking in ERP 9 is clunkier, report generation is slower, and the gap between what the software records and what the business needs to act on is wider.

The three workarounds everyone tries (and why each one fails)

The Excel sidecar. This is the most common approach. Tally handles the accounting. A parallel Excel sheet handles expiry tracking. Someone — usually the owner, sometimes a pharmacist or store manager — maintains a spreadsheet with batch numbers, expiry dates, quantities, and a conditional formatting rule that turns cells red when expiry is within 90 days. In theory this works. In practice, it falls apart within three to six months. The spreadsheet requires manual data entry that duplicates what was already entered in Tally. Entries get missed, especially during busy periods. The spreadsheet falls out of sync with Tally's actual stock levels because sales are not reflected in real-time. Nobody updates the sheet on Sundays or during festivals. By the time someone notices the discrepancy, the data is unreliable enough that the sheet gets abandoned and rebuilt, and the cycle repeats. I have spoken to pharmacy owners who have started and abandoned Excel-based expiry tracking four or five times. They are not careless people. Excel is simply the wrong tool for a problem that requires real-time synchronisation, multi-user access, and proactive alerting.

The TDL customisation route. Tally Definition Language allows developers to extend Tally's functionality. There are developers — good ones — who build custom TDL modules that add expiry tracking reports, batch filtering, and alert generation inside Tally. The problem is threefold. First, TDL modules are fragile. When Tally releases an update — which happens several times a year — custom TDL code can break, requiring the developer to patch it. If the developer is unavailable (they moved to a different city, they took on other clients, they stopped supporting old code), you are stuck with broken functionality and no fix. Second, TDL customisations are local. They live on the machine where they are installed. If you have two billing terminals and a laptop for the owner, the customisation needs to be installed and maintained on each one independently. Third, the cost structure does not scale well. The initial development costs ₹15,000-40,000. Annual maintenance runs ₹5,000-10,000. And the capability you get is still limited to what TDL can access within Tally's data model, which does not include external alert channels, mobile access, or AI-driven demand prediction.

The mental note approach. The owner "knows" which items are expiring. They walk the shelves periodically. They have a sense for which categories tend to expire and which do not. This works in a shop with 300 SKUs. It does not work in a shop with 2,500 SKUs carrying 6,000-8,000 active batches. The human brain is excellent at pattern recognition and terrible at maintaining a real-time database of 8,000 items with different deadlines. The mental note approach feels effective because the owner catches some near-expiry items during their walk. What they do not see is everything they missed, which they only discover as a write-off entry three months later.

The real cost of the gap — and it is not just expired stock

The most obvious cost is the value of stock that expires and gets destroyed. For a mid-size Indian pharmacy doing ₹8-12 lakhs per month in revenue, annual expiry losses typically run ₹1.2-2.5 lakhs. For a grocery retailer or supermarket, losses from expired FMCG products run 2-4% of inventory value annually. These numbers are significant but they are not the full picture.

The less visible cost is missed distributor returns. Every pharmaceutical distributor and most FMCG distributors have return policies for near-expiry stock. Typical windows are 3-6 months before printed expiry for full credit, and some allow partial credit at shorter windows. When you discover that 40 strips of an antibiotic are expiring in 45 days and the return window was 90 days, you have already lost the option. That ₹4,000 in stock that could have been full credit is now ₹0 — or ₹400 if the distributor is generous with a partial credit. Across a year, missed return windows often exceed the value of stock that actually expires, because the missed returns include stock that had a recoverable path and was simply not identified in time.

There is the GST complication. Under GST rules, ITC (Input Tax Credit) claimed on stock that is subsequently destroyed or written off needs to be reversed. Section 17(5) of the CGST Act covers goods lost, stolen, destroyed, or disposed of by way of gift. Expired stock that gets destroyed falls into this category. If you claimed ₹12,000 in ITC on stock that you subsequently write off as expired, that ₹12,000 needs to be reversed in your returns. Most pharmacies and retailers handle this correctly at the end-of-year stock reconciliation, but the cash flow impact is real — you paid the supplier, claimed the credit, lost the stock, and now owe the credit back.

For pharmacies, there is also the compliance layer. Expired Schedule H and H1 drugs on your shelf during a Drug Inspector visit is a show-cause situation. Repeated findings can trigger licence review proceedings. The operational overhead of documenting destruction under Form 29, maintaining the destruction register, and managing the compliance trail adds hours of work per quarter that produces no revenue.

What an intelligent add-on layer actually does (and how it connects to Tally)

Tally is excellent at what it does — accounting, GST filing, invoicing, ledger management — and replacing it would be enormously disruptive. What is needed is not a replacement but an intelligent layer that reads Tally data and adds the operational intelligence that Tally does not provide.

ShelfSense AI works this way. It connects to your Tally data — whether you are on Tally Prime or Tally.ERP 9 — and builds a real-time operational view of your inventory that Tally was never designed to provide. The integration reads your stock items, batch information, purchase records, and sales data. It does not modify your Tally data. It reads it, analyses it, and generates the intelligence layer on top.

What that intelligence layer provides is specific and practical. Daily alerts — via WhatsApp, SMS, or email — listing batches approaching expiry at 180-day, 90-day, 60-day, and 30-day thresholds. Each alert includes the product name, batch number, quantity remaining, current value, distributor return window status, and a recommended action (return, discount, push to high-traffic location, or write-off). This is the information Tally stores but does not surface. ShelfSense AI reads it from Tally's data and delivers it to your phone every morning before you open the shop.

FEFO enforcement at the billing counter. When the clerk creates a sales entry, the system identifies which batch should be billed based on expiry date, not receipt date. This is the difference between FIFO (which Tally can do) and FEFO (which Tally cannot). For a pharmacy dispensing Schedule H drugs, this is not just good practice — it is a compliance mechanism that ensures the oldest stock moves first, reducing the probability that any batch sits long enough to expire.

Return window tracking. Every batch is mapped against its distributor's return policy. When a batch enters the return-eligible window, the system flags it. When the window is closing — say, 14 days before the deadline — it escalates the alert. The pharmacy owner or store manager sees a clear list: these 23 batches across 8 distributors need return action in the next two weeks, total recoverable value ₹18,400. This single feature typically recovers more value in the first quarter than the entire annual cost of the system.

Demand velocity analysis. The system tracks how fast each SKU is actually selling, at the batch level, and calculates whether current stock will be consumed before expiry. An antibiotic selling 12 strips per week with 80 strips in stock and 14 weeks to expiry is fine — it will sell through. The same antibiotic selling 4 strips per week with 80 strips and 14 weeks to expiry has a 24-strip surplus that will not sell through. ShelfSense AI identifies these surpluses automatically, weeks before they become obvious, when there is still time to act.

The GRN problem — and why it matters more than people think

Goods Receipt Notes in India are where batch data either gets captured correctly or gets corrupted at the source. When a purchase arrives — from a pharmaceutical distributor, an FMCG wholesaler, or a direct company delivery — the GRN process records what was received: product, quantity, batch, expiry, MRP, and rate. In Tally, this is typically entered through a purchase voucher with batch details enabled.

The problem is that GRN entry in Tally is manual and tedious. A typical pharmaceutical purchase contains 40-80 line items. Each line item requires batch number, manufacturing date, expiry date, MRP, and quantity. Entering all of this accurately takes 25-45 minutes per invoice. During a busy day when three deliveries arrive within an hour, the data entry gets rushed. Batch numbers get transposed. Expiry dates get entered as manufacturing dates. The month field gets swapped with the day field (is 03/25 March 2025 or the 3rd of some month in 2025?). These small errors cascade into unreliable batch data, which makes every downstream process — alerts, FEFO, return tracking — unreliable.

Invoice OCR changes this entirely. Photograph the distributor invoice, and ShelfSense AI reads it — product names, batch numbers, expiry dates, quantities, MRP, GST details — and maps the data to your existing stock items. What took 35 minutes of manual entry now takes 90 seconds of verification. More importantly, the accuracy is higher because the system reads what is printed on the invoice rather than what a tired data entry operator types at 8 PM after a long day.

The GRN accuracy improvement alone resolves the root cause of most Tally expiry tracking failures. When batch data is entered correctly at the point of receipt, every subsequent operation — alerts, FEFO billing, return tracking, compliance reporting — works on clean data. When batch data is entered with errors, nothing downstream is reliable. The GRN is the foundation, and OCR-based capture makes that foundation solid.

What this looks like in a real pharmacy

A typical day for a pharmacy using Tally plus an intelligent add-on layer:

6:45 AM. The owner's phone shows a WhatsApp message: "Daily Expiry Brief — 7 batches need attention. 3 batches in return window (value ₹6,200, deadline this week). 2 batches approaching 90-day mark. 2 slow-moving batches unlikely to sell before expiry."

7:30 AM. Shop opens. The owner tells the helper to pull the 3 return-eligible batches and pack them for pickup. Total time: 10 minutes. Recoverable value: ₹6,200 that would have been ₹0 if discovered two weeks later.

9:00 AM. A delivery arrives. Instead of spending 35 minutes entering 60 line items into Tally, the pharmacist photographs the three pages of the invoice. The OCR system processes them in under a minute. The pharmacist reviews the extracted data, corrects one line where the system flagged low confidence, and confirms. Batch data flows into the system cleanly.

Throughout the day, as sales happen through the billing counter, the system ensures FEFO batch selection. When a customer buys Azithromycin 500mg, the batch expiring in August 2025 gets billed before the batch expiring in February 2026. The clerk does not need to think about it. The system handles it.

5:00 PM. A drug company representative visits and offers a scheme: buy ₹15,000 of a cardiovascular range, get 20% in free goods. Before the Tally-only days, the pharmacist would have checked gut feeling and maybe Tally's stock summary. Now the system shows: current stock of the proposed SKUs is 45 days of supply, the scheme quantity would bring it to 90 days, the slowest-moving item in the range sells 3 units per month and the scheme would give 5 months of supply for that item. The pharmacist negotiates: accepts the scheme but substitutes the slow-moving item for a faster-moving one. The rep agrees. No surplus, no future expiry problem.

This is the same pharmacy, using the same Tally installation, with the same staff. The difference is an intelligence layer that turns Tally's accounting data into operational decisions.

The economics — what this costs versus what it recovers

For a pharmacy doing ₹10 lakhs per month, with current annual expiry losses of ₹1.8 lakhs and missed distributor returns of approximately ₹80,000, the total annual waste is around ₹2.6 lakhs.

An intelligent add-on layer typically recovers 50-70% of that waste in the first year — ₹1.3-1.8 lakhs in preserved stock value and recovered returns. By the second year, as historical data improves demand forecasting and ordering patterns adjust, the recovery reaches 65-80%.

The cost of ShelfSense AI is a fraction of the recovered value. The ROI calculation is not close. The more relevant question is not "can I afford this" but "how much am I losing every month that I delay."

If you are running Tally and managing expiry through Excel sheets, memory, or manual shelf checks — and you suspect the real losses are higher than the number you tell yourself — the gap between what you know and what you are losing is exactly the gap that an intelligent add-on layer fills.

Your Tally installation is not the problem. The absence of an intelligence layer on top of it is.

You can run a Free CSV Audit on your current stock data to see exactly what is at risk. No installation, no commitment — upload your stock file and see what the system catches. Or go straight to the free trial and connect it to your Tally data.