Most companies that move from Tally to ERPNext ask the same first question: can we bring everything across? The honest answer is that you can, and that you almost never should. The projects that go badly are usually the ones that tried to rebuild ten years of vouchers in a new system before anyone had raised a single live invoice in it.
This piece sets out what we migrate, what we leave in Tally, and how we prove the numbers match on the day you switch. It also covers the case most guides skip: companies that move operations into ERPNext while their accounts stay in Tally for a while.
Why Tally data does not map one to one
Tally is a very good accounting system. Its data model is built around ledgers, groups and vouchers. A customer is a ledger under Sundry Debtors, with an address and GSTIN stored on the ledger. A supplier is a ledger under Sundry Creditors. Stock items sit in stock groups, with units and godowns. Bill-wise details hang off party ledgers.
ERPNext separates these ideas. A customer is a Customer record with its own addresses, contacts, credit limit and default price list, and a receivable account behind it. Items carry HSN codes, units of measure, conversion factors, batch and serial settings, and default warehouses. Stock lives in a stock ledger that values every movement.
So migration is not an export and an import. It is a translation, and every translation needs decisions: which Tally groups become which ERPNext account heads, whether a party that appears as both debtor and creditor becomes one record or two, which godowns are real warehouses and which were a workaround.
What we migrate
We bring across two things: masters, and opening balances on a cutover date.
| What | Detail | Where it lands in ERPNext |
|---|---|---|
| Chart of accounts | Tally groups and ledgers, cleaned and mapped to account heads | Account tree |
| Customers and suppliers | With GSTINs, addresses and contacts | Customer, Supplier, Address |
| Items | With HSN codes, units and conversion factors | Item |
| Warehouses and cost centres | Only the ones that are real | Warehouse, Cost Center |
| Trial balance | As on the cutover date | Opening journal entry |
| Open receivables and payables | Bill by bill, not as one balance per party | Opening invoices |
| Bank balances | Per account, matched to the statement | Opening journal entry |
| Stock | Quantity and value by warehouse | Stock reconciliation |
Two details in that table matter more than they look. Open receivables and payables go in bill by bill, so that the first receipt after go-live can be knocked off against the right invoice and your ageing report is correct from day one. Stock goes in with its value, warehouse by warehouse, so that the stock account in the balance sheet and the stock ledger agree before anyone moves a carton.
What we leave in Tally
Past vouchers stay in Tally, read-only, for reference and audit. We migrate history only where a regulator needs it in the new system.
The reasons are practical. Every historical voucher has to be mapped to accounts, parties and items that may no longer exist in the cleaned masters. Stock history replayed into ERPNext recalculates valuation movement by movement, and it will rarely land exactly on the closing value Tally reported, because the two systems value stock differently. Then someone spends weeks explaining a difference that has nothing to do with the business.
Your auditor does not need last year's vouchers in ERPNext. They need a closing trial balance they recognise, an opening trial balance in ERPNext that matches it, and a Tally company they can still open. Keep the Tally licence long enough to cover that.
Cleaning the masters is the real work
The migration templates go out in the first week. The data that comes back is where most of the effort sits. Common problems in any Tally company that has run for years:
- The same customer created twice, under slightly different names, with the balance split between them.
- Parties with no GSTIN, or a GSTIN that does not match the state in the address.
- Items with no HSN code, or with units that changed over time.
- Ledgers created for one transaction and never used again.
- Godowns that were really a way to park stock for a customer.
Your team does the cleaning, because only your team knows which "Sharma Traders" is the real one. We supply validators for the mechanical errors, the kind a script can catch, such as a malformed GSTIN or a missing HSN code, so that the cleaning effort goes into judgement rather than proofreading.
Picking the cutover date and proving the numbers
We cut over at the start of a month or a quarter, so that each period closes in one system. The date is yours to choose; the plan runs backwards from it.
Before the final load there are two dry runs. Each is reconciled against Tally on five things: trial balance, stock by warehouse, open receivables, open payables and bank. If any of them does not match, we find out why before the next run, not after go-live. At the final load the same five checks run again.
Between the dry runs, your accounts and operations teams run their own transactions on a staging copy. That includes GST invoices, because the cutover plan has to prove that GST, e-invoicing and e-way bills work on day one. In ERPNext that is the India Compliance app, set up against your GSTINs and tested on your own invoices before anything goes live.
After cutover we stay with the accounts team until the first month-end closes in ERPNext. The first close is where any remaining mapping mistakes show up, and it is better to find them together.
When accounts stay in Tally
Not every company moves its books on the same day it moves its operations. Sometimes the accountant is not ready, sometimes the auditor prefers a year-end switch, and sometimes the problem the company actually has is not in accounting at all.
Two of our published cases are like this, and it is worth being precise about them. Neither is a full Tally migration.
JAT Metal Pressing, an automotive components maker in Mumbai, ran its operations on Excel and manual planning. We moved sales orders, production planning, work orders, material issue, stage-wise quality checks and dispatch into ERPNext. Accounting stayed in Tally, with a daily sync from ERPNext. The problem being solved was order-linked production, not bookkeeping.
Living Liquidz, a liquor retail chain with more than 100 outlets, moved its invoice-to-payment cycle onto ERPNext: goods receipt sync, a store app, multi-level approvals and bulk payments. Tally stays integrated for accounting.
In both, ERPNext became the system of record for operations, and Tally kept doing what it already did well. That is a legitimate end state for a while, and sometimes for good. If you run it this way, decide three things up front:
- Which system owns each record. Usually ERPNext owns items, customers and transactions; Tally receives them. Never let both sides create the same master.
- What flows, and how often. Invoices and receipts on a schedule is the common pattern. Real time is rarely needed for accounts and adds failure points.
- Who looks at the failures. A sync that fails silently for a fortnight is worse than no sync. Someone needs a daily list of what did not post.
One company or two?
Plants with more than one unit often ask whether each unit should be its own company in ERPNext. Usually not. One company with a unit accounting dimension gives each unit its own profit and loss without doubling the masters. Separate companies make sense when the units are separate legal entities with separate GSTINs. We worked through exactly this decision for a two-unit film plant during its requirement workshops.
A short checklist
- Choose a cutover date at the start of a period.
- Decide what history, if any, a regulator needs in the new system. Leave the rest in Tally.
- Issue migration templates in week one and give your team validators, not just spreadsheets.
- Load open receivables and payables bill by bill.
- Run two reconciled dry runs: trial balance, stock, receivables, payables, bank.
- Test GST, e-invoicing and e-way bills on your own invoices before cutover.
- If Tally stays for accounts, name the owner of each record and the person who reads the sync log.
- Keep Tally readable until your auditor no longer needs it.
If this is your situation
If your accounts are in Tally and everything else is in Excel, or you want to move but cannot afford a month-end that does not close, start with our Tally to ERPNext page and the migration and upgrades service. Then tell us your cutover date, and we will tell you what we would bring across.
