Extract India Pharma Distributor Invoices: Batch, Expiry, PTR

It is the 5th of the month at a chemist shop in Hyderabad or Hazaratganj. Fifty to a hundred stockist PDFs have come in over the past week from distributors covering everything from acute therapy to chronic-care brands, three or four of them carrying scheme lines like 10+1 mixed in among the paid items. Batch number and expiry need to land in the purchase register before the GSTR-2B reconciliation window closes, and the inventory ledger needs to update with the right batch-wise quantities so the next FEFO dispense reads correctly. Generic invoice OCR has already been tried and it dropped exactly the columns that matter.

To extract a pharma distributor invoice for an Indian chemist's workflow correctly, you have to convert the distributor's PDF into structured rows that preserve the columns generic OCR drops: batch number, manufacturing and expiry dates, pack/strip, free-quantity scheme units, PTR, MRP, GST percentage, and HSN. Each invoice line maps to one row in the resulting Excel, CSV, or JSON file so Tally's batch tracking and GSTR-2B reconciliation both stay correct, and FEFO sales sequencing can read expiry per batch. That is the workflow this article walks through.

The reason generic extractors fail on a pharma stockist PDF is structural rather than accidental. Most B2B invoices outside pharma do not carry batch number or expiry date because they are not regulated to. An extraction tool that treats invoices as a generic category therefore has no slot for those fields and either omits them or smears them into the item-description blob alongside the brand name and salt. A pharma chemist's purchase register cannot accept that loss. Batch and expiry are the keys that link inward stock to outward sale, drive the input tax credit reversal when stock expires, and make a manufacturer recall workable.

What makes the problem worth its own workflow is that a chemist serves two compliance surfaces from the same set of inward records. The GST surface is familiar: Rule 46 mandatory fields on the tax invoice, monthly GSTR-2B reconciliation against the supplier's GSTR-1, the input tax credit pipeline. The Drugs and Cosmetics Act surface sits alongside it: every pharmaceutical sale invoice and the matching purchase record must show batch and expiry, traceable from the customer the medicine was sold to, back through the dispensing register, back through the purchase register, back to the stockist invoice that brought the batch in. The Drug Inspector and the GST officer ask different questions of the same purchase register, and the answer to both lives in how cleanly the inward extraction captured the line-level columns.

Note that this is the Indian stockist-to-pharmacy frame, not the global pharmacy frame. Readers searching for pharmacy invoice processing for the US 340B and NDC context will find that the global article addresses 340B drug pricing, NDC code lookups, and group purchasing organisation contracts, none of which describe the Indian chemist's working day. The Indian pharma stockist invoice is its own document, with its own column model, and the extraction workflow has to be built around it.

---

The pharma stockist invoice column model, line by line

A pharma stockist invoice carries between nine and twelve columns per line depending on the distributor's billing software. Not every distributor prints all of them, but a chemist's extraction has to accommodate the full set because any one of them may carry the data that drives a downstream consequence. Working from left to right across a typical invoice line:

Item description is the brand name plus salt plus strength plus pack size, often in the form "Augmentin 625 Duo 10s" or "Glycomet GP 1 forte 15s". This column is the failure surface for generic OCR because pharma item descriptions are dense and the columns immediately to the right (HSN, batch, mfg, expiry) sit in the same line band on the page. Generic extractors that have not been told a pharma column model exists collapse some or all of those right-side columns into the description text, which is where the data loss happens.

HSN code sits adjacent to the description and follows Chapter 30 for pharmaceutical products. The practical splits a chemist sees are 3003 (medicaments in bulk or unmixed form, less common at retail-chemist scale and mostly relevant where a hospital pharmacy procures bulk APIs), 3004 (medicaments put up in measured doses or in forms or packings for retail sale, which is the dominant chapter on a retail-chemist's inward invoice), and 3006 (pharmaceutical preparations and articles such as adhesive dressings, sterile surgical sutures, and similar). HSN must be captured at line level rather than rolled up to invoice level because the GST rate selection follows the chapter and sub-heading, and a single invoice often mixes chapters.

Batch number is the manufacturer-assigned alphanumeric identifier for the production lot. Manufacturing date and expiry date sit alongside it. These three together are the traceability triplet that the Drugs and Cosmetics Act compliance surface depends on. It is worth distinguishing the two dates explicitly: expiry is the FEFO-driving field and the field a Drug Inspector will check on a sale-against-purchase trace; manufacturing date supports recall handling and shelf-life calculations but does not drive sales sequencing on its own.

Pack/strip size records the unit of dispense. A strip of 10 tablets is one packing unit; a bottle of 100 ml of syrup is another; a vial pack of 10 ampoules is a third. The extraction must preserve this column because downstream inventory needs it to compute units-on-hand correctly. Quantity expressed as "200 strips" of a 10-tablet strip means 2,000 tablets in the dispensing pool, which is what a sales register tracks against.

Quantity is the paid quantity of packs. Free quantity sits in its own column on better stockist invoices and carries the scheme units (the +1 in 10+1, the +2 in 20+2, and so on). This column gets its own treatment in the next-but-one section because of how often generic OCR loses it.

Rate (PTR) is the price to retailer per unit, the price column the chemist is actually paying against. Discount is any line-level discount applied off the printed PTR (some distributors print pre-discount and post-discount columns; others print only the net rate). GST percentage is per line because pharma invoices mix rates. Line amount is the post-discount taxable value per line; CGST/SGST or IGST may be split into their own columns or shown as a single combined tax. MRP appears as a reference column on most distributor invoices and is the printed maximum retail price the chemist may charge the customer.

The GST-side baseline for what a tax invoice must show is set by Rule 46 mandatory fields for an Indian GST tax invoice: invoice number and date, supplier and recipient details with GSTINs, HSN, description, quantity, taxable value, tax rate, and tax amount. The pharma stockist invoice extends this baseline with the batch, expiry, pack, free-quantity, MRP, and PTR columns — fields that exist because the Drugs and Cosmetics Act regulates pharmaceutical sale on top of the GST regime, not because GST itself requires them. The same physical document satisfies both compliance surfaces, which is why the extraction has to capture both layers.

This is also the reason a separate workflow exists. The generic Indian purchase invoice extraction to Excel workflow handles the Rule 46 GST layer for any B2B vendor and is the right starting point for non-pharma inward invoices. It does not carry the pharma column layer on top, and trying to retrofit batch and expiry onto a generic extraction produces the same description-blob collapse that generic OCR produces. The pharma column model needs the columns named up front so the extraction recognises them as their own data points, not as fragments of an item description.

---

PTR, PTS and MRP, and the DPCO regulatory mechanic that links them

Three price terms appear on or around an Indian pharma stockist invoice, and they are not interchangeable. Getting them right matters because a chemist's accountant who uses them loosely will recognise a non-expert source quickly, and the extraction layer needs to know which number is the GST base, which is a reference, and which never appears at all.

PTR — Price to Retailer is the rate on the stockist-to-pharmacy invoice. It is the per-unit price the chemist is paying for the pack, before GST. PTR is the column the extraction has to capture as the rate column because every downstream calculation reads off it: the GST percentage applies to PTR (multiplied by paid quantity, net of any line discount) to give the tax amount; the inventory ledger uses PTR to compute weighted-average cost; the margin report compares PTR against the eventual sale price.

PTS — Price to Stockist is the rate on the manufacturer-to-stockist invoice — the price at which the distributor itself bought the goods. PTS is generally not visible to the pharmacy because that invoice never reaches the chemist; it sits between the manufacturer and the stockist. Worth saying explicitly because a reader new to the extraction layer sometimes goes looking for a PTS column on the stockist PDF and there is not one to find. The chemist's inward invoice carries PTR, not PTS.

MRP — Maximum Retail Price is the printed ceiling on the pack itself, inclusive of all taxes, beyond which the chemist may not legally sell. MRP appears on the stockist invoice as a reference column rather than as a price the chemist pays. Selling above MRP is a Legal Metrology violation and, for scheduled formulations, a DPCO violation as well. The chemist may sell at MRP or below; the printed MRP is the upper limit the supply chain has agreed.

The reason MRP and PTR sit on the same invoice in a predictable relationship is regulatory. Drugs (Prices Control) Order 2013 published by the Department of Pharmaceuticals sets the framework: under the Drugs (Prices Control) Order 2013, the ceiling price of a scheduled formulation is fixed as the average price to retailer plus a 16% retailer margin — the regulatory basis for the PTR-to-MRP relationship that appears on every Indian pharma stockist invoice. That formula is why, on a scheduled drug, the printed MRP and the invoiced PTR sit in roughly fixed proportion to each other once GST is added on top.

The practical extraction consequence falls out of that regulatory structure. PTR is the GST base — the rate column the GST percentage applies to per line — and MRP is a reference value to be captured for downstream sales pricing and Legal Metrology purposes but is not the GST base. Generic OCR sometimes conflates the two on distributor invoices that print PTR and MRP in adjacent columns, particularly when the column headers are abbreviated or the columns are visually close. A row that flips the two produces a wrong GST base, a wrong purchase value, an inflated input tax credit claim, and a GSTR-2B mismatch when the supplier's GSTR-1 shows the correct taxable value against the same invoice line.

One regulatory wrinkle to know about, though it does not change the extraction itself: scheduled formulations sit under the DPCO ceiling-price mechanic above; non-scheduled formulations are price-controlled by a 10% annual increase cap on the existing price rather than a fixed PTR-plus-margin ceiling. A typical stockist invoice mixes scheduled and non-scheduled lines without flagging which is which, and the extraction does not need to classify schedule status. The reader should simply know that this is why some lines on the invoice show an MRP that aligns tightly with a PTR-plus-16-percent-plus-GST formula and others sit further apart from any clean ratio. Both kinds of lines extract identically; the regulatory differentiation is upstream of the chemist's purchase register.

---

Scheme lines and free-goods extraction (10+1, 20+2, and the rest)

Scheme lines are where the pharma stockist invoice diverges most sharply from any generic B2B invoice, and where extraction tools that have not been built for pharma quietly lose data. The patterns the chemist sees: 10+1 (ten units paid, one unit free), 20+2, 5+1, "1 free with 5 strips", and quarterly-target schemes that sometimes show up as a free-quantity addendum at the end of the invoice rather than against the line that triggered them. Different stockists print these differently. Some have a dedicated Free Quantity column on the same line as the paid Quantity. Some print a separate zero-rate line below the paid line, with the same item description and batch but a price of zero and a quantity equal to the free units. Some leave it as a footnote inside the description column (such as "Pack: 10s + 1 free") with no structural column at all.

The extraction principle is the same regardless of how the stockist prints it: free quantity must be captured as a distinct column on the same row as the paid quantity, tied to the same item and the same batch. Collapsing free quantity into the description blob, which is what generic OCR will do when it does not recognise the column, loses the unit count and breaks two downstream calculations the chemist depends on.

The first downstream calculation is GST. Free units supplied as part of a scheme are not consideration under GST, and tax is not charged on them. The line's taxable value covers the paid quantity only; the GST percentage applies to that base. A row that incorrectly attributes GST to the free quantity inflates the taxable value, inflates the tax amount, and inflates the input tax credit claim. When that invoice line is reconciled against the supplier's GSTR-1 filing, where the stockist has correctly reported only the paid value, the variance surfaces as a GSTR-2B mismatch and the credit is at risk.

The second downstream calculation is effective PTR and weighted-average cost. A 10+1 line means the chemist has paid for 10 units and received 11. The effective PTR per unit is the line value divided by the total received quantity, which is paid plus free, not paid alone. Inventory weighted-average cost should move on effective PTR, not on invoice PTR, because the inventory layer is tracking the cost of the units physically present in stock. A purchase register that records 10 units of paid quantity and ignores the free unit over-values the inventory and silently inflates the gross margin number on every subsequent sale of that batch. Over a month of stockist invoices with scheme lines mixed throughout, that drift is large enough to misstate the pharmacy's profitability.

There is also a Tally voucher consequence. TallyPrime's batch-tracked inventory needs the paid quantity and the free quantity together on the same batch line so the inventory ledger receives the full physical units (paid plus free) while the accounting value reflects only the paid amount. The voucher import format supports this when the source data carries both quantities. The extraction layer is what makes this possible without retyping each scheme line manually after the import.

A pharma-aware extraction names Free Quantity as its own column on the same row as the paid Quantity, tied to the same Batch and Expiry, so a 10+1 line lands in the output Excel with two quantity columns rather than one — and the inventory upload and the Tally voucher both read off the resulting physical-units-versus-paid-units split directly.

One last consequence on the FEFO side. A 10+1 batch arrives free but is part of the same physical lot as the paid units — it has the same manufacturer batch number and the same expiry date. FEFO sequencing therefore treats the free units as part of the same expiry-driven sales pool as the paid units, which is correct behaviour only if the extraction kept the free quantity tied to the right batch number on the row.

---

Drugs and Cosmetics Act batch and expiry compliance, and ITC reversal on expired stock

The second compliance surface a chemist's purchase register serves is the Drugs and Cosmetics Act, and it is enforced separately from GST. Under the Drugs and Cosmetics Act 1940 and the Drugs and Cosmetics Rules 1945, every pharmaceutical sale invoice and the matching purchase record must show batch number and expiry date for each item supplied. The Drug Inspector arriving for a retail-pharmacy compliance inspection looks for a different evidence chain than the GST officer running an audit. The same purchase register has to satisfy both.

What the Drug Inspector does in practice is trace a specific sale backwards. A customer was supplied a particular batch of a particular drug; the dispensing register and the bill of supply should record which batch went out; the purchase register should show which inward stockist invoice brought that batch in; the stockist invoice itself should be available in the records. Each link in the chain has to carry batch and expiry at line level. A purchase register that aggregates inward purchases by item and quantity ("Paracetamol 500mg tablets, 200 strips, ₹X" with no batch detail) cannot complete the trace, and the entry is not D&C-compliant on its face. The compliance failure is structural, not procedural.

This is why batch and expiry must land at line level in the extracted output, never aggregated to invoice level. An invoice-level rollup is fine for some accounting purposes but useless for the D&C compliance surface and useless for the inventory layer. The line-level capture is the floor the inspector's trace stands on.

Schedule H, Schedule H1, and Schedule X items have stricter recordkeeping than the floor. Schedule H1 in particular triggers a separate dispensing register requirement for the listed antibiotics, anti-tuberculars, and habit-forming substances, with prescriber and patient detail required against each dispense. The extraction does not classify schedule status — that information sits in the chemist's master data, not on the stockist invoice itself — but the reader should know that batch-and-expiry capture at line level is the compliance floor, and that schedule-controlled items demand more, not less, of the records the purchase register feeds into.

The same line-level batch and expiry capture does work on the GST side that is often missed. When a batch in the chemist's stock expires, the input tax credit originally claimed on the inward purchase of that batch must be reversed under Section 17(5)(h) of the CGST Act, which blocks ITC on goods lost, stolen, destroyed, or written off. Expired pharmaceutical stock falls squarely into the written-off category. The reversal is reported in the period the write-off happens, not the period the original purchase was claimed in.

TallyPrime's batch-level inventory tracking handles this reversal cleanly when the inward extraction landed batch and expiry correctly. Tally knows which batches are physically in stock, which have crossed their expiry date, and which underlying purchase voucher each batch traces back to; the reversal can be posted against the right voucher in the right period. If batch was lost at extraction — collapsed into the description blob, or omitted because the column was not recognised — the reversal becomes a manual reconciliation against physical stock, where the accountant has to walk the shelves, pull the expired strips, hunt down the purchase invoices that brought those batches in, and compute the credit reversal by hand. This is the work that does not happen on schedule and so does not happen at all in many small chemist shops.

The pattern that follows from this is consistent across pharmacy GST returns: expired-stock ITC reversal is one of the most-missed adjustments. The cause is almost never that the accountant does not know the rule. It is that the underlying purchase data does not carry batch and expiry at the line level, so the connection between an expired strip on the shelf and a credit claimed three months earlier cannot be made without going back to PDFs. Fixing the extraction layer fixes this category of missed adjustment by default.

The same batch-level inward record is also what makes a manufacturer recall workable. When a manufacturer issues a recall, the notice lists batch numbers. The chemist needs to find which inward stockist invoices brought those batches in, which physical stock is still on the shelves under those batch numbers, and which customers (where prescription records permit) received supplies from those batches. Without batch in the purchase register, the recall trace becomes paper and memory rather than data, and the response is slower and less complete than the regulator and the manufacturer expect.

---

Per-line GST split and GSTR-2B reconciliation against extracted invoices

A pharma stockist invoice routinely mixes GST rates within the same document. Life-saving drugs and certain insulins and oncology medicaments sit at 0%, essential medicines on the listed schedule sit at 5%, and most general medicines sit at 12%. The 57th GST Council slabs that took effect on 1 February 2026 are the current anchor for which medicines fall on which slab, and a single distributor's invoice covering thirty or forty line items will commonly carry lines from at least two slabs and sometimes all three. This is not an unusual case to design around; it is the routine case.

The extraction principle that follows is that GST percentage and the corresponding tax amount have to be captured per line, not as an invoice-level rate. A weighted-average rate at the invoice level is wrong on a mixed-rate invoice for the obvious reason that it is not the rate any individual line was actually billed at, and it is wrong for a less obvious reason: the supplier files GSTR-1 line by line with the specific rate against each HSN, and the chemist's purchase register has to compare line by line against that filing for the reconciliation to work.

The reconciliation mechanic in practice is that the chemist's extracted purchase register, with one row per invoice line carrying GSTIN, invoice number, invoice date, HSN, taxable value, and the tax split into CGST/SGST or IGST, is compared against GSTR-2B downloaded from the GST portal for the relevant period. Mismatches surface at the GSTIN-invoice-line level — a mismatched HSN, a mismatched rate, a missing line where the supplier did not report the invoice, a value variance where the supplier filed a different taxable value than the chemist's invoice shows. The cleaner the extracted purchase register, the faster this comparison runs. The dirtier it is, the more time goes into resolving variances that turn out to be extraction errors rather than supplier errors.

The portal-level consequences changed in January 2026. The GST portal now blocks ITC claims on mismatched lines until either the supplier corrects their GSTR-1 to match the chemist's invoice or the chemist accepts the supplier's value as the correct one. For pharma, where ITC is a substantial monthly figure relative to a chemist's working capital, a stuck reconciliation does not just delay paperwork — it delays the credit being available, which directly delays cash-flow planning and can pull the chemist's outflow forward. Extraction quality at the inward step is the lever that determines how clean the monthly reconciliation runs and how quickly the credits clear. The full mechanic of the portal block, the IMS workflow, and the supplier-correction flow is covered in India GST ITC reconciliation through GSTR-2B and IMS, which is the natural next read for the reader who wants the reconciliation surface in full.

The IMS layer sits on top of GSTR-2B. The Invoice Management System workflow on the GST portal lets the recipient explicitly accept, reject, or keep-pending each invoice line that appears in GSTR-2B against their GSTIN. Doing this credibly at scale, across 200 to 500 stockist invoices a month, requires a clean extracted purchase register to compare against — without one, the chemist is reconciling from the PDFs themselves, which is the workflow the extraction step is removing in the first place. The choice to accept or reject a line on IMS is also a decision with cash-flow consequences, since accepting a wrong taxable value locks in the supplier's number, and the right comparison data is what makes that decision an informed one rather than a rushed one.

The expired-stock ITC reversal from the prior section connects into this surface as well. On the GSTR-3B side, the reversal is reported in Table 4(B), which captures ITC reversed under Rule 38 / Rule 42 / Rule 43 / and other reversals (the "other" bucket is where Section 17(5)(h) reversals on expired stock typically land). The Table 4(B) entry has to be defensible if questioned, and the underlying defensibility comes from the batch-level evidence in the inward extraction and Tally's batch tracking — the same chain that the Drug Inspector reads on the D&C side.

---

From extracted spreadsheet to Tally voucher, pharmacy POS, and FEFO sequencing

The extracted file has three downstream destinations in a typical chemist's workflow: a TallyPrime purchase voucher with batch and expiry preserved, a pharmacy POS inventory upload for the chains that run a Marg or eVitalRx or RetailGraph instance alongside Tally, and the FEFO sales-sequencing reference data the dispenser reads off when picking strips for a customer. All three depend on the same per-line column structure landing in the spreadsheet, which is why the extraction step does its work upstream of all of them.

The Tally voucher path is the most common landing in pharmacy practices. TallyPrime supports batch-level inventory tracking when the relevant feature is enabled at the company level (Maintain batch-wise details) and at the stock-item level (Maintain in batches, Track date of manufacture, Use expiry dates). With the feature on, a purchase voucher imported from an Excel or XML source needs the batch number, manufacturing date, and expiry date columns mapped to Tally's batch fields so the inward voucher creates or updates the batch on the stock item rather than just incrementing a non-batched stock total. The mechanics of that import — the column mapping, the voucher template, the handling of new versus existing batches — are covered in import purchase vouchers into TallyPrime from Excel. The Excel import path is what most pharmacies settle on because it survives changes to stockist PDF formats better than a direct PDF-to-voucher tool: when the stockist's billing software updates and the column order shifts, the Excel layout the chemist controls does not change.

Direct PDF-to-Tally OCR is a separate workflow surface. TallyPrime invoice OCR for posted purchase vouchers covers that route for vendors and use cases that suit it, and it is a reasonable choice for a non-pharma practice handling a stable set of supplier invoice formats. For an Indian pharma chemist, it is generally not enough on its own because it does not address the batch and expiry column layer that the stockist invoice carries on top of the GST baseline. The pharma extraction layer described in this article sits earlier in the pipeline than that OCR step and produces a structured Excel that the Tally voucher import can then consume cleanly.

The pharmacy POS path runs parallel. Pharmacy-specific POS systems typically expect an Excel or CSV inventory upload format with columns for item code (mapped to the POS's master item ID), batch number, manufacturing date, expiry date, MRP, PTR, and quantity. The extracted file maps onto that upload format directly when batch and expiry are preserved per line, with two practical caveats: the POS's item code may differ from the stockist's item description and so requires a master mapping the chemist maintains, and the POS may want the file split per supplier rather than combined across all stockists for a period. Both are layout adjustments on the extracted Excel rather than re-extraction work.

FEFO — First-Expiry-First-Out — is the dispense rule that ties the three landings together. The dispenser at the counter or the back-end inventory system is supposed to release the nearest-expiry batch of a given item before any later-expiry batch of the same item, both for patient safety and to avoid expired-stock write-offs. FEFO sequencing only works if the inventory layer knows, for each item, which batch expires soonest, which means every inward batch was recorded with its expiry. Without per-line expiry on the inward record, FEFO degrades to the dispenser pulling whatever strip is at the front of the bin, which is not FEFO and is the failure mode the regulator's guidance points at.

A chemist's day-to-day rhythm tends to settle into something like this: stockist PDFs arrive over the week as deliveries land, the chemist or the bookkeeping practice runs the extraction at end-of-week or end-of-month against the period's batch of PDFs, the resulting Excel is reviewed for line-level accuracy with particular attention paid to the scheme lines and the batch/expiry columns, the file is then imported into Tally and uploaded to the POS, and the GSTR-2B reconciliation runs against the same extracted purchase register before the monthly return is filed. The extraction step is the pivot the whole rhythm turns on, because every downstream system reads off the same Excel.

The named extraction step in this workflow is AI-powered pharma stockist invoice extraction that takes the chemist's batch of stockist PDFs and produces a structured Excel/CSV/JSON file with batch, expiry, PTR, MRP, free quantity, GST percentage, and HSN preserved at line level — ready for Tally voucher import or pharmacy POS upload. With Invoice Data Extraction, the chemist or bookkeeper uploads the period's stockist PDFs (native PDFs from distributor billing software or scanned PDFs from delivery copies, in batches up to 6,000 files in a single job, with individual PDFs up to 5,000 pages), writes a prompt that names the columns to extract — Item, HSN, Batch, Mfg Date, Expiry, Pack, Quantity, Free Quantity, PTR, MRP, Discount, GST percentage, Line Amount — and downloads the structured file. The same prompt can be saved and reused each period so the column shape stays consistent across runs.

One boundary to keep clear, because it shapes how the workflow gets set up: extraction is the entry step the chemist runs against the PDFs; the Tally voucher import and the pharmacy POS upload are user steps the chemist or the practice performs in their own systems against the resulting Excel. The extraction tool produces the file in the right shape; the chemist or their team carries it the last mile into Tally and the POS. That boundary is where pharma-aware extraction stops and Tally-side and POS-side configuration take over.