ProCraft — BlogERP & POS

When Tally isn't enough: software for growing retailers

Tally handles your books. It was never built to run your shop floor. An honest look at when an Indian retail or trading business needs more than billing.

By ProCraft6 min read
Line drawing of a retail counter with a billing terminal and a printed roll on the left and a storage rack of stacked boxes on the right, with a wide measured gap between them crossed only by a dashed line under a question mark

Almost every trading and retail business in India runs Tally, and for good reason. It handles accounts, GST and statutory filing well, your CA already knows it, and it has survived thirty years of Indian business practice.

So this isn't an article about replacing Tally. It's about the gap that opens between what Tally was built to do and what a growing shop actually needs on a Tuesday afternoon — and what to do about that gap without throwing away something that works.

The question that exposes the gap

Here it is: what is on the shelf at your second branch, right now?

Not what the books say. Not what was counted on Saturday. What is physically there at this moment, including what was sold in the last hour and the delivery that arrived before lunch.

If answering that means calling someone, the gap is real. Your accounting software knows what was recorded. It doesn't know what's happening.

What Tally does well, and what it was never for

Worth being precise here, because "Tally is bad" is both untrue and the reason a lot of bad software gets sold in this market.

Tally is built for the books. Ledgers, vouchers, GST returns, statutory compliance, your accountant's workflow. It does that job properly and you should not disturb it.

It was not built to run operations across locations in real time. A counter staff member ringing up a sale, a godown transferring stock to a branch, a salesman checking availability from a customer's shop, an owner seeing today's margin before deciding tomorrow's purchase — those are operational questions, and they sit outside what an accounting package is for.

The problem isn't the software. It's that businesses ask it a question it was never designed to answer, then build a parallel system of registers, WhatsApp messages and a staff member's memory to cover the difference.

Line drawing of two bounded areas on one sheet: on the left a ledger book and stacked document sheets, on the right a shelf rack, a counter and a delivery crate, with a single arrow running from the right area into the left

The six signs you've hit the ceiling

  1. Stock is counted, not known. Someone walks the godown with a register every week, and the number is stale by evening.
  2. Billing and books are separate acts. Sales are written at the counter and entered into Tally later — usually by one person, usually in a batch, usually at month end.
  3. Branches don't see each other. A customer wants an item your other shop has. Nobody can confirm it without a phone call.
  4. Your best salesperson is your inventory system. They know what's in stock, which customer buys what, and what was promised last month. None of it is written down.
  5. The month-end close takes a week. Not because accounting is hard, but because the operational data has to be reconstructed before it can be recorded.
  6. Growth made it worse. A second branch didn't double the admin. It quadrupled the reconciliation.

These are the retail version of a wider pattern. If your operation runs on spreadsheets rather than registers, the same ceiling shows up as the six signs you've outgrown a spreadsheet.

What actually solves it — and what doesn't

It's rarely "replace Tally." In most projects we've seen, the right structure is an operational system that runs the shop floor — billing, stock, branches, customers — which then hands clean data to Tally for accounts and compliance. Your CA keeps working the way they always have. Your counter stops writing in a register.

It's rarely a generic POS either. Billing software prints bills. That's useful, and it's not the same as knowing stock across three locations, tracking which customer owes what, or telling you today's margin by category.

And sometimes the honest answer is: not yet. If you run one shop, one godown and one person who genuinely knows everything, a good billing package plus Tally may be all you need. Buying an operational system before you have an operational problem is money spent to feel modern.

The India-specific things that matter

A system built for this market has to handle realities that generic software often gets wrong:

  • GST-compliant invoicing that produces what your CA and the portal actually expect, in the formats they expect — and that keeps up when rules change
  • Multiple rate slabs and HSN codes applied correctly at the point of billing, not corrected afterwards
  • Credit and udhaar tracking by customer, because a large share of trade here runs on relationship credit that no international package models properly
  • Bill formats people expect — the printed invoice your customer wants is not the one a US-built system produces by default
  • Working offline and syncing later, because connectivity in a godown or a shop in a smaller town is not the same as connectivity in a tech park
  • Local language support where your counter staff need it
  • Hardware that's actually on the counter — thermal printers, barcode scanners, the tablet someone already bought

That last group is where most imported software quietly fails. Not because it's badly built, but because it assumed a different country.

Line drawing of a counter workstation: a billing terminal at the centre, a thermal printer beside it feeding out a long narrow receipt strip, a handheld barcode scanner on a stand and a small tablet propped at an angle, each marked with dimension lines

What this costs, honestly

Indicative, for an Indian retail or trading business:

  • A good billing and inventory package — a few thousand rupees a month per location, subscription. Right for most single-location shops.
  • A configured system with your workflows, branches and Tally integration — a one-time project in the low lakhs, depending on scope.
  • A fully custom operational platform — priced as software, and only worth it when your process is genuinely the thing you compete on.

Anyone quoting a custom system before understanding your process is quoting a guess. Ask them to write the scope first.

How we approach it

We build operational software for retail and trading businesses, and we run our own — StockFlow, a retail ERP, and RestPOS for restaurants, both in production with paying users and support tickets that come to us. Living with our own decisions is what taught us to start small.

Before we quote, we map how your business actually runs — the counter, the godown, the delivery register, the WhatsApp group, the things one person keeps in their head. Then you get a written scope: what gets built, what stays manual, what it costs, how long. You approve it before anyone writes code.

And when a subscription package would serve you better than something custom, we say so. That conversation costs you nothing.

The short version

Keep Tally. It's doing its job.

The question is whether anything is doing the other job — knowing what's on the shelf, in which branch, at this moment, and what that means for what you buy next week.

If the answer to that requires a phone call, that's the gap. It doesn't need a rip-and-replace. It needs one system that handles the floor and hands clean numbers to the books.