Tally to ERPNext Migration Guide: Ledgers to Cut-over

A migration is not an import

Every Tally to ERPNext project has the same moment of truth, and it is not go-live. It is the first month-end, when the accountant runs the trial balance in ERPNext, puts it next to the last one from Tally, and looks for the difference. If there is one and nobody can explain it, the finance team stops trusting the new system that afternoon, and every report from then on starts with an asterisk. If the two tie out — account by account, party by party, warehouse by warehouse — the system is trusted, and the rest of the rollout gets easier.

That is why we treat migration as its own workstream inside every Tally to ERPNext migration and implementation, with its own plan, its own owner on the client side — usually the person who closes the books — and one deliverable: a reconciliation pack that finance signs before the first live transaction is entered. This guide is the sequence we run. It is written for the finance lead and the IT lead who will own the project, not as a click-by-click manual, and it assumes Tally Prime or Tally ERP 9 on one or more companies with GST in scope. Excel, Busy and Zoho Books follow the same shape with a different extraction step.

What Tally and ERPNext each think a ledger is

Tally maps onto ERPNext better than its reputation suggests, but only once the structural differences are understood, because every one of them is a mapping decision that has to be made before anything is loaded.

The biggest is that a Tally ledger is both an account and a party. "Sundry Debtors" contains a ledger per customer, and that ledger carries the balance, the address and the GSTIN all at once. ERPNext separates the two: the chart of accounts has one Debtors account (or a few), and customers are a master of their own with their own addresses, contacts, tax details and credit terms. So every Tally ledger has to be classified — is this an account, a customer, a supplier, a bank, an employee advance? — and the classification decides where its balance goes.

The rest follows the same pattern. Tally groups become the account tree, with the primary groups mapping to ERPNext's root types and the sub-groups to its parent accounts. Stock groups, stock items and units become item groups, items and units of measure; godowns become warehouses; cost centres and cost categories map directly to cost centres and, where needed, accounting dimensions. GST registration, state and tax classification on ledgers and items become the tax templates, tax categories and item tax templates ERPNext uses to compute GST on every document. Tally voucher types — sales, purchase, receipt, payment, contra, journal, stock journal, manufacturing journal — become ERPNext document types: sales and purchase invoices, payment entries, journal entries, stock entries and manufacturing work orders. None of it is difficult; all of it has to be written down and agreed with your accountant before the first load.

Step one: choose the cut-over date and the depth of history

The cut-over date decides most of the work. The start of a financial year is cleanest: one opening trial balance, no part-year history, and comparatives that begin at the same point in both systems. The start of a quarter is the usual compromise when the business cannot wait for April. Mid-month cut-overs are possible and we advise against them, because the GST return for that month then has to be assembled from two systems.

The second decision is how much history comes across, and the instinct to migrate everything is the wrong one. There are three honest options.

Opening balances only. Fastest and cleanest. Historical reporting stays in Tally, which is kept as a read-only archive. Right for companies whose past reporting needs are occasional.
Current financial year. The common middle ground. Comparatives, GST reconciliation and receivables ageing all work inside ERPNext from go-live, at the cost of loading and reconciling part-year documents.
Multi-year history. Justified when contracts, warranties, batch traceability or a regulator require it in the live system. This is where migration effort grows fastest, because every year's transactions must reconcile to that year's closing balances, and each year adds another reconciliation.

Whatever the depth, Tally is not deleted. Books of account have statutory retention periods, so the Tally data stays readable, its exports are kept in durable formats, and the ERPNext documents carry the old voucher numbers so an auditor's query can be traced back in seconds.

Step two: extract from Tally

Tally gives you three routes out. XML export from the Gateway, per report and per period, is the most complete for masters and vouchers and is what we use for most companies. ODBC over Tally's server port works for repeatable pulls and for reconciliation queries later. Excel exports of the trial balance, group summaries, outstanding statements and stock summaries are what the accountant already knows and are the reference copies the reconciliation is done against. Whichever route, extraction is done per company and per financial year in scope, on a frozen copy of the data, and every extract is dated and kept — the reconciliation at the end compares against these files, not against a Tally that has since moved on. Tally's own help covers the export mechanics for the version you run.

Step three: the mapping sheet

The mapping sheet is the migration's design document, and the accountant reviews and signs it before any load. It has one row for every Tally master and a column for what it becomes in ERPNext.

Groups → chart of accounts. Tally primary and sub-groups to ERPNext root types and parent accounts, in the tree finance wants to report on, which is usually a simpler tree than the one Tally accumulated.
Ledgers → accounts, customers, suppliers, banks. Every ledger classified. Party ledgers become customer or supplier masters with the ledger's address, GSTIN, PAN and state carried onto the party and its address; their balances go to the Debtors and Creditors accounts.
Stock groups, items, units, godowns → item groups, items, UoMs, warehouses. With the valuation method decided per item or company, batch and serial tracking flagged where Tally used it, and HSN/SAC codes on every item.
Cost centres and categories → cost centres and accounting dimensions.
GST classifications → tax templates, tax categories and item tax templates. Registration type, state, place of supply logic and the intra- versus inter-state templates that will compute CGST/SGST or IGST on each document.
Voucher types → document types and naming series. Including which Tally series continue and which restart, and the reference field that will hold the Tally voucher number.

Step four: cleanse the masters

Years of Tally use produce three spellings of the same customer, items with no unit, ledgers with no GSTIN and a tax classification that was set once and never revisited. None of that is visible until the first receivables report splits one company's balance across three parties. So the masters are cleaned before they are loaded: customers, suppliers, items, accounts and employees de-duplicated, standardised and enriched, with GSTIN and PAN validated, HSN and SAC codes assigned, units and item groups rationalised, and naming made consistent. The cleaned masters go back to your team in review sheets for sign-off. This is the step people try to skip and the step that decides whether the first GST return on ERPNext is prepared by the system or by hand.

Step five: load the masters, then the balances

Masters go first — accounts, parties with addresses and contacts, items with valuation method, warehouses, cost centres, employees, price lists — through ERPNext's Data Import tool for the straightforward ones and scripted loads through the REST API with validation for the large or interdependent ones. Every load runs on a staging site first; nothing goes to production until the reconciliation on staging is clean.

Then the balances, as of the cut-over date, in a specific order.

Opening trial balance by account, loaded as an opening journal entry against a temporary opening account, and tied to Tally's trial balance to the rupee.
Receivables and payables at invoice level, not as one lump per party. Each open invoice is loaded as an opening sales or purchase invoice with its original date and due date, so that ageing is right on day one and every incoming payment can be matched to what it pays. A single balance per party makes ageing meaningless and payment matching impossible — this is the most common mistake in Tally migrations we are asked to repair.
Stock by item, warehouse and batch or serial, at quantity and valuation rate, through stock reconciliation entries, with the resulting stock value tied to the balance sheet's inventory figure. A stock ledger that starts a week after cut-over is wrong from day one.
Bank balances, reconciled to statements, with unpresented items carried so the first bank reconciliation in ERPNext does not start with a difference.
Fixed assets, loaded as existing assets with cost, accumulated depreciation and the remaining schedule so depreciation continues without a break.

Step six: history, if it is in scope

Where current-year or multi-year history is in scope, Tally vouchers become ERPNext documents: sales and purchase vouchers become invoices, receipts and payments become payment entries allocated to those invoices, journals become journal entries, stock journals become stock entries, and manufacturing journals become work orders or stock entries depending on how much of the manufacturing module is being adopted. The Tally voucher number is kept in a reference field on every migrated document. Each period's documents are loaded and then that period's closing balances are reconciled before the next period is loaded, so a difference is found in the period that caused it rather than at the end.

Step seven: the reconciliation pack finance signs

The migration's deliverable is a pack of line-by-line comparisons between Tally and ERPNext at the cut-over date, with every difference either explained or corrected.

Trial balance by account, both systems side by side, to the rupee.
Party outstanding — each customer's and supplier's balance and its invoice-level ageing.
Stock summary — quantity and value by item and warehouse, and the total tied to inventory on the balance sheet.
Bank balances against statements.
GST liability and input credit at the cut-over date, against Tally and against the portal.
Fixed-asset register — cost, accumulated depreciation and net book value.

The person who owns the books signs it, and nobody enters a live transaction until they have. It is also the document the auditor asks for at year-end, which is why it is written for them rather than for us.

GST across the cut-over

GST is where a Tally migration in India is most often judged, so it gets its own rules. Returns already filed stay with the period and the system they were filed in; nothing is refiled from ERPNext. E-invoice IRNs and e-way bill numbers generated from Tally are recorded on the migrated ERPNext documents rather than regenerated, so reconciliation with the GST portal is continuous across the cut-over. Input credit and liability balances at the cut-over date are loaded as part of the opening entries and tied to the last return. From the first period on ERPNext, GSTR-1 and GSTR-3B are prepared from the ERPNext ledger, using tax templates that were tested on the parallel month's transactions before anyone depended on them. If the tax details on masters were cleansed properly in step four, the first return is a report; if they were not, it is a spreadsheet.

The parallel run and the cut-over checklist

Before Tally is switched off, both systems run for one closing period. Transactions are entered in Tally as usual and in ERPNext by the team who will own it, and at period end the trial balance, GST returns, party statements and stock reports are compared line by line. The differences are almost always process rather than data — a voucher type used differently, a warehouse missed, a tax template wrong on one item group — and the parallel month is where they are found and fixed while nothing is at stake. It is also the month in which the team learns ERPNext on their own live numbers, which is better training than any workshop.

Cut-over itself is a checklist run on a date agreed with finance.

Transactions frozen in Tally at close of business on the cut-over date.
The final delta of balances since the staging load migrated and reconciled.
Master data locked; naming series confirmed; the reference field on migrated documents spot-checked against Tally.
Users, roles and permissions confirmed against who actually does what.
The first live documents — a sales invoice, a purchase, a payment, a stock entry — entered in ERPNext with our consultant in the room.
Rollback stated in one line: if the cut-over reconciliation does not sign, the business keeps transacting in Tally for another period and we fix the cause. The old system is still there, so the plan is simple.

A hypercare month follows, through the first month-end close, the first GST filing and the first payroll on the new system. The implementation page covers the rollout the migration usually sits inside.

What the discipline produces

The numbers we point to are from rollouts that started with data somewhere else and ended with one system of record. Mohan Impex, an importer, manufacturer and channel-partner seller, was running accounting, inventory, procurement and HR on disconnected tools and spreadsheets; after the ERPNext v14 rollout, 100 % of its processes were digitised with the spreadsheets retired, inventory accuracy went above 99 % with real-time multi-warehouse tracking, monthly GST filing preparation fell from three days to four hours, automated import duty and landed-cost calculation improved costing accuracy by 35 %, and payroll went from two days to under two hours a month. Jyoti CNC Automation replaced legacy on-premise systems with an ERPNext manufacturing ERP and cut inventory holding cost by 22 % through automated reorder points, while on-time production order fulfilment rose from 78 % to 94 %.

Neither of those was a single-company Tally cut-over — one came off spreadsheets and the other off older on-premise systems — and we would rather say so than dress them up. What they share with every Tally migration is the part that decided the outcome: masters cleaned before loading, balances reconciled before anyone transacted, and compliance configured into the transactions rather than prepared by hand afterwards.

How long it takes and what sets the effort

As a guide from our projects: a single-company Tally migration with opening balances only takes two to three weeks and runs inside the implementation; with current-year history and a reconciled parallel month it is four to six weeks; a multi-company, multi-year migration from a legacy ERP with stock, assets and integrations is two to four months. Five things set the effort, and none of them is the software.

The state of the data — duplicate parties, items without units, ledgers with no tax details.
The depth of history — opening balances, current year, or several years each reconciled.
Companies, warehouses and financial years in scope.
Stock, batches, serial numbers and fixed assets — each adds a reconciliation of its own.
Integrations and customisation that must be live at cut-over — e-invoicing, bank feeds, a CRM, a custom app.

Migration is quoted as part of the implementation's fixed price after discovery has looked at the actual data, which is the only honest way to price it. If you are in Saudi Arabia or the Gulf, the ZATCA and VAT specifics are on the ERPNext in Saudi Arabia page; if the process you are migrating from a spreadsheet is not one ERPNext models, it becomes a custom Frappe app on the same instance.

Where Tally migrations go wrong

Importing instead of reconciling. The balances load, nobody ties them to Tally, and the first month-end starts with an unexplained difference that is never fully explained.
One balance per party. Receivables and payables migrated as lump sums, so ageing is meaningless and no payment can be matched to an invoice.
Skipping the master cleanse. Three spellings of a customer, items without HSN codes, ledgers without GSTIN — the first GST return is prepared by hand, which is what the ERP was bought to stop.
Stock loaded late or without valuation. The stock ledger begins after the cut-over or at zero rate, and valuation is wrong from day one.
A mid-month cut-over. One GST period assembled from two systems.
Migrating everything. Ten years of vouchers loaded because they were there, each year adding a reconciliation nobody asked for.
Switching Tally off on go-live day. No parallel month, no rollback, and no archive when the auditor asks.

Before you start

The first step is a look at the real data, not a proposal. Send us a Tally backup or your exports under NDA — every company and financial year you want in scope — and we will come back within a week with what will migrate cleanly, what needs cleansing, a recommended cut-over date and history depth, and a fixed price as part of the implementation. This is the pattern behind our ERPNext work for manufacturers and traders, and the rest of the practice — the collaboration models, the stack and the case studies — is on the Frappe and ERPNext services page. If you would rather start with a conversation, tell us what you run the books on today and how many companies and warehouses are involved.