Multi-Store Retail in India: Getting Stock, POS and GST to Agree

A single shop runs perfectly well on a billing package and a stock book. The trouble starts at the second outlet, and it starts on three fronts at once.

Nobody can see group stock, so each store hoards inventory while another runs out of the same item. Prices and offers diverge because they are maintained separately. And somebody spends every morning re-entering yesterday's sales into the accounts.

None of these are discipline problems. They are architectural ones, and no amount of process tightening fixes them.

Why does stock go invisible across stores?

Because each till writes to its own database. When store A's system has no view of store B's shelves, an inter-store transfer requires a phone call, and phone calls do not happen at the volume real retail needs.

The consequence is measurable. A chain running separate systems typically carries meaningfully more inventory than one running a shared pool, because every location buffers independently against its own uncertainty. That buffer is working capital sitting on shelves.

A shared inventory model changes the question from "do I have it?" to "where is it, and is it worth moving?" Transfer requests, in-transit visibility and receipt confirmation turn that into a routine rather than an escalation.

What does a POS connected to the ledger actually change?

The obvious answer is that it removes the morning reconciliation. The more useful answer is that it removes an entire class of error.

When sales are re-entered by hand, three things go wrong regularly:

• Totals are transposed or a day is skipped
• Returns and exchanges get netted differently by different people
• Card settlements do not tie to the till because they are reconciled in a separate spreadsheet

When the till writes into the same ledger that produces the financial statements, none of that arises. Tender types reconcile against payment terminal settlements automatically. Shift closing produces a variance figure rather than a debate.

How should GST e-invoicing be handled in retail?

Generate the IRN from the sales transaction itself. That single design decision removes most GST pain in Indian retail.

The common alternative — issuing an invoice at the till, then re-keying it into a compliance tool or an accountant's register — creates two records of the same sale. They diverge. When they diverge, GSTR-1 does not match what the customer's GSTR-2B shows, and the notices follow.

A correctly configured system does the following in one pass:

1. Records the sale with the right HSN classification and tax template
2. Requests the IRN and prints the QR code on the invoice
3. Posts the ledger entries
4. Contributes the same transaction to GSTR-1 and GSTR-3B data

Nothing is typed twice, so nothing can disagree.

Why does the till need to work offline?

Because connectivity in Indian retail locations is not reliable, and a till that stops billing stops revenue.

Offline mode is not a nice-to-have feature on a specification sheet. It is the difference between a two-hour ISP outage being an inconvenience and being a lost trading afternoon. The requirement is that the till continues billing locally, queues transactions, and synchronises cleanly when the connection returns — including reconciling stock without creating duplicates.

Ask any vendor to demonstrate this by unplugging the network during the demo. It is a short test and it is revealing.

Batch and expiry: where retailers get caught

For food, pharmacy and cosmetics retail, batch-wise stock with expiry dates is a compliance requirement rather than an inventory refinement.

Two capabilities matter:

• Blocking sale of expired batches at the till, so it cannot happen through inattention at a busy counter
• Reporting near-expiry stock while there is still time to discount it, move it to a faster location, or return it to the supplier under the purchase terms

The second is where the money is. Stock discovered as expired is a write-off. Stock flagged six weeks out is a margin decision.

Buying on evidence instead of instinct

Reorder levels set once, group-wide, produce simultaneous stockouts in fast locations and dead stock in slow ones. The fix is unglamorous: reorder points per item per store, derived from that store's actual sell-through, reviewed periodically.

Vendor performance deserves the same treatment. Rate is easy to compare. Fill rate and lead-time reliability are what actually determine whether your shelves are full, and they only become visible when the system accumulates them over time rather than living in a buyer's memory.

What to look for when evaluating

If you are assessing retail ERP for a growing chain, the questions that separate systems are narrower than most feature lists suggest:

• Does the till write into the same database as the accounts, or does it sync into it?
• Does the IRN come from the sales transaction, or from a re-keyed copy?
• Does billing continue during a network outage, and does sync produce duplicates?
• Can reorder levels differ per store, and are they derived from sell-through?
• Is batch and expiry enforcement at the till, or advisory?

SyvaSoft Retail ERP was built around these answers, with offline till operation and IRN generation at source. But the questions are worth asking of any vendor — including us. A system that fails the offline test will fail it in your busiest week, not in the demo.