Nobody outgrows Tally because of Tally. They outgrow it because of the spreadsheets that have grown up around it.
That is the pattern in almost every business that calls us about this. Tally is still doing exactly what it was built to do, and doing it well. But alongside it there is now a stock sheet one person maintains, a quotation template in Word, a WhatsApp group where dispatch gets coordinated, a separate file for who owes what and since when, and a monthly ritual where somebody reconciles all of it by hand. The accounting is fine. The business running on top of the accounting is held together by one person's attention.
This article is about telling apart a business that needs a bigger accounting package from one that needs a different kind of system — and about what the move actually costs in disruption, which is the part vendors tend to skip.
First, the honest case for staying where you are
Tally's reputation is earned, and four things about it are genuinely hard to beat:
- Every CA in India can open your books. That is not a small thing — it means your filings, your audit and your loan application all run on software the other side already knows.
- It is fast at what it does. Voucher entry by someone experienced is quicker than almost any web application will ever be.
- It is cheap relative to anything that replaces it, and the licence is one you already own.
- It is stable. Ten-year-old data opens, and the statutory updates arrive.
If your business is essentially one location, selling a stable set of products, with a CA who files on time and nobody waiting on information to do their job, an ERP will cost you money and change nothing you care about. We have told people exactly that. It is a better conversation than the alternative one, eight months later.
The five signals you have actually outgrown it
These are the triggers that turn out to be real, in rough order of how often they are the actual reason somebody calls.
1. The same fact gets typed in more than once
A customer's order is typed into a quotation, then a delivery challan, then an invoice, then the stock sheet. Four keystrokes for one fact. The cost is not the typing. It is that the four copies drift apart, and nobody can say which one is right without going back to the person who typed them.
2. The answer to “how much stock do we have” is “let me check”
In a business of any size the on-hand figure should be derived, not maintained: every receipt, issue, transfer and adjustment recorded in order, with the current quantity as the arithmetic result of that ledger. If instead it is a number a person keeps up to date, then it is a number that is wrong in between the times they do it — and the gap is invisible until a customer is promised something that is not there.
3. Sales and accounts are working from different records
Sales knows a deal closed on Tuesday. Accounts finds out when the paperwork arrives on Friday. Sales promises a delivery date based on stock that was committed to someone else that morning. Nobody is being careless; the two teams are simply reading two different books, and the cost shows up as a credit note, a missed collection, or a customer told two different things in one week.
4. Compliance has become a monthly event rather than a by-product
GST should fall out of invoices you have already raised. If the end of the month starts with assembling those invoices, then the accounting sits downstream of the real work instead of inside it. The same test applies to TDS, to e-way bills generated one at a time on the portal while a truck waits, and to payroll someone computes in a sheet and then posts as a journal.
5. You cannot answer a question about last quarter without starting a project
“Which customers bought this product and did not come back?” “What did that job actually cost us against what we quoted?” “Which salesperson's deals are slipping?” These are ordinary questions. If each one needs a person, a day and three exports, the information exists but the business cannot reach it, which in practice is the same as not having it.
What is actually breaking, specifically
It is worth naming the mechanism rather than the symptom, because the mechanism is what tells you whether more software of the same kind will help.
| What you notice | What is actually happening | What fixes it |
|---|---|---|
| Stock figures are never quite right | On-hand is maintained by hand, not derived from movements | A movement ledger that every document writes to |
| The same delivery gets invoiced twice | Documents are unconnected; nothing tallies what was already billed | A document chain where each converts into the next |
| Receivables chased late or twice | Ageing lives in a sheet that is only as fresh as last Friday | Ageing derived from posted invoices and receipts |
| E-way bills hold up dispatch | Generated one at a time on the portal from re-typed data | Payload built and validated from the invoice itself |
| Nobody can explain a number | No audit trail, so a figure has no history | Per-record audit trail that survives edits |
| Month-end takes a week | Compliance assembled from scattered sources | Documents that post their own entries |
What an ERP changes, and the one thing worth insisting on
An ERP is sold to you as modules — sales, purchase, inventory, accounts, payroll. What you are actually buying is the record engine underneath them, and that is where these purchases succeed or quietly fail.
Here is the test we would put to any vendor, including ourselves. Ask what happens to the stock figure at the moment you raise an invoice. If the answer involves a sync, a nightly job, or a person, then the modules are separate products sharing one login, and you have bought your integration problem again at a higher price. If the answer is that there is one movement ledger and the invoice has written a line in it, the integration is real.
Orbis is built the second way, which is the whole argument for it: every module shares the same forms, permissions, audit trail, import, reporting, numbering and API, so switching one on later is a setting rather than a project. That also means you buy the modules you need — a workshop runs leads, inventory and accounts; a restaurant adds tables, a kitchen display and QR ordering — instead of a bundle with nine-tenths switched off.
Four more things worth testing before you sign anything:
- Does GST come out of the place of supply, or does somebody pick CGST and SGST from a dropdown? The second is a data-entry decision, which means it will sometimes be wrong, which means a notice.
- Does each document convert into the next, in part or in full, with quantities already drawn down tallied before billing? That mechanism is what stops one delivery being invoiced twice.
- Is there an audit trail on every record, and does it survive an edit? “Who changed this price and when” is the question you will want answered on your worst day.
- Can you get your own data out — the rows, not just the reports — without asking the vendor? If not, you are renting your history.
Migration: what carries over and what does not
The honest version, because the optimistic version is where migrations go wrong:
- Masters carry over cleanly. Customers, suppliers, products, the chart of accounts, price lists. These are spreadsheet imports and they are the easy half.
- Opening balances carry over as balances, not as history. Debtors, creditors, stock and ledger closing figures as at your cutover date.
- Transaction history usually does not carry over, and usually should not. Re-creating five years of vouchers in a new schema produces records that look authoritative and are subtly wrong. Keep Tally, read-only, as the archive for prior years. Your CA will thank you.
- Document numbering should carry over, and most teams forget to ask. Invoice numbers restarting at 1 mid-year is a conversation with an auditor nobody enjoys.
- Nothing carries over that was never in Tally. The stock sheet, the quotation folder, the follow-up notes — those get entered once, properly, and that work is the real cost of the move.
The sequence that hurts least: pick a cutover at the start of a quarter, import masters and opening balances, leave Tally read-only for prior years, and run one month in parallel on the two document types that matter most — usually invoices and stock movements. Parallel running on everything is a tax nobody can sustain; parallel running on two things catches the errors that matter.
The cost nobody quotes you
Licences and implementation fees get quoted. Attention does not. Two or three of your people will spend a real part of a month on cleaning masters, agreeing numbering, deciding who is allowed to approve what, and finding out that two departments have been using the same product code for different things. That work is not optional and it is not the vendor's to do — they do not know which of your two “Valve 40mm” records is the real one.
Budget for it explicitly and the project lands. Pretend it is free and it slips, and the slippage gets blamed on the software.
A short decision rule
If the question is “can our accounting software do more”, buy more accounting software. If the question is “why does everyone keep asking each other for numbers that should already exist”, that is an ERP question, and no accounting package will answer it — because the problem was never the accounting.
If you want a second opinion on which of those you are actually in, book a walkthrough and bring your two worst spreadsheets. Those tell us more in ten minutes than a feature list does in an hour, and if the answer is that you should stay on Tally for another year, we will say so.
Frequently asked questions
Can we keep using Tally alongside an ERP?
For prior years, yes, and we recommend it — keep Tally read-only as the archive so your filed years stay exactly as filed. Running both live for the same period is different, and it is a trap: two systems both accepting entries means two sets of books and a reconciliation job forever. The exception is a deliberate one-month parallel run on invoices and stock during cutover, which is there to catch errors, not to be permanent.
Will our CA be able to work with the new system?
Ask two questions of any vendor. Can it produce a ledger, trial balance, profit and loss, balance sheet and ageing on demand? And can it export the rows your CA actually wants in a format they already use? If both answers are yes, the CA's workflow barely changes. What usually changes for the better is that they stop receiving a shoebox of spreadsheets each month.
How long does a migration from Tally take?
The import itself is days. What sets the timeline is cleaning your masters and agreeing your own process — who approves a discount, what the numbering series is, which of your duplicate product codes survives. For a single-location business with reasonably tidy data, a quarter-start cutover with one month of parallel running is a realistic plan. The businesses that take six months are almost always the ones that treated data cleaning as something that would happen by itself.
Do we have to buy every module at once?
You should not, and with Orbis you do not — modules are sold and switched on per client, so a business sees only what it bought. Start with the part that hurts most, which is usually billing and stock, and add the rest when the first part is working. Because every module sits on one engine, adding one later inherits the same forms, permissions, audit trail, import, reporting and API with no new plumbing.
Is a cloud ERP safe for our financial data?
The question to ask is not cloud versus on-premise, it is who holds the keys and what the access model looks like. Ask whether staff, API clients, customers and suppliers are separate kinds of identity with their own routes and signing secrets, or one login with a flag on it. Ask whether salary and bank details sit behind separate permissions from the rest of the record. Ask what the audit trail captures. A business whose ERP cannot answer those three has a problem whether it runs in a data centre or a cupboard.
