Guides, glossaries and calculators to help you scope, cost and run an ERPNext implementation — from GST and e-invoicing setup to module-by-module walkthroughs.
Quick definitions of key terms
Expert insights and updates
Simple step-by-step resources
Easy explanations through videos.
Complete IRN flow in ERPNext (2026)
ERPNext HRMS for India's Labour Codes
ERPNext for Indian hospitals (NABH, ABDM, DPDP)
DPDP Act 2023 Compliance in ERPNext
Most Indian businesses that outgrow Tally do not leave because Tally is bad at accounting. They leave because everything around the accounting — production, stock discipline, approvals, project cost — has ended up in spreadsheets. The migration itself is the part people fear, and it is the part we make boring.
The measure of a good migration is that your first ERPNext trial balance equals your last Tally one, to the rupee.
Data is extracted from Tally, mapped to ERPNext masters, loaded through the Data Import tool and then reconciled against Tally's own reports before cutover. Ledgers become accounts and parties, stock items carry their batch and serial history, and opening balances are matched to the rupee. Transaction history is normally carried as opening position rather than re-entered.
Almost every failed migration fails in the same four ways, and all four are avoidable if they are addressed before any data moves.
Tally's ledger list mixes chart-of-accounts entries with customers, suppliers and employees. Loaded directly, you get a chart of accounts with two thousand entries and a receivables report that means nothing. The split has to happen during mapping, not afterwards.
Books are often still open for the prior period when migration starts, and audit adjustments land later. Without a frozen cutover date agreed with your auditor, the opening balance moves under you and reconciliation never closes.
Tally stock is frequently maintained with alternate units, godowns that are really departments, and items whose closing value was adjusted rather than counted. Migrating the number without migrating the basis moves the problem rather than solving it.
Years of custom voucher types, optional vouchers and post-dated entries encode business rules nobody wrote down. Those rules need to be identified and redesigned as ERPNext documents and workflows, not translated one for one.
Scope is agreed in writing before extraction begins, so there is no argument later about what was supposed to come across.
Tally ledgers are separated into accounts, customers, suppliers and employees, with groups mapped to an ERPNext account tree that reports the way you want to read it.
This is where a rushed migration is normally lost. Getting the tree right at this stage is what makes every later report readable without customisation.
Trial balance, party-wise outstanding and stock value are loaded as opening entries and then compared line by line against Tally's own reports for the same date.
Reconciliation is a deliverable, not a promise. You get a variance report that resolves to zero before anyone is asked to sign off.
Items are migrated with unit of measure, conversion factors, HSN and SAC codes, tax templates, and batch or serial tracking where you maintain it.
Alternate units in Tally become defined UOM conversions in ERPNext, so purchase in bags and issue in kilograms stay consistent.
Unpaid invoices, open purchase orders, pending sales orders and material in transit are carried across so day one in ERPNext is a working day, not a rebuild.
Closed history stays in Tally as an archive. Carrying every historical voucher usually costs more than it is worth and slows the new system down.
GST registration structure, HSN mapping, TDS sections and applicable tax templates are configured so the first return filed from ERPNext behaves like the last one filed from Tally.
Cutover is normally timed to a period boundary specifically so no return spans both systems.
The mapping is agreed up front. Anything not on this list is an explicit decision, not an oversight.
| In Tally | In ERPNext | Direction | Notes |
|---|---|---|---|
| Ledger under Sundry Debtors | Customer + Receivable account | One-time | Contact and address details split into their own records |
| Ledger under Sundry Creditors | Supplier + Payable account | One-time | Includes GSTIN and payment terms where maintained |
| Ledger under other groups | Account in the chart of accounts | One-time | Group structure remapped to an ERPNext account tree |
| Stock item | Item + Item Defaults | One-time | UOM conversions, HSN, tax template and tracking method |
| Godown | Warehouse | One-time | Godowns used as departments are redesigned, not copied |
| Closing balances | Opening Entry journal | One-time | Reconciled against the Tally trial balance before sign-off |
| Outstanding bills | Opening Sales / Purchase Invoice | One-time | Preserves bill-wise ageing from the original due dates |
| Stock closing quantity and value | Stock Reconciliation | One-time | Batch and serial detail carried where maintained |
| Cost centres | Cost Center tree | One-time | Mapped to the dimension structure you want to report on |
Five stages. Nothing is loaded into your live instance until the same load has succeeded in a sandbox and reconciled.
Data is exported from Tally and profiled for the things that break migrations: duplicate ledgers, items with no unit, negative stock, entries dated outside the period. You see that report before any mapping decision is made.
Chart of accounts, party classification, item attributes and cost centre structure are agreed in writing. This is the stage where the future shape of your reporting is actually decided.
The full migration runs into a sandbox instance. Errors surface here, against a copy, rather than against the system your team is about to start using.
Trial balance, party outstanding, stock quantity and stock value are compared against Tally for the cutover date. The variance report has to reach zero, with any deliberate difference documented and approved.
The final extract is taken after the last Tally entry, loaded, reconciled once more, and the instance is opened to users. Tally stays available as a read-only archive.
Timeline shown is indicative for a single-company migration and depends on data condition, which the profiling stage establishes before anything is committed.
Stated plainly, because discovering these at cutover is how projects lose trust.
If any of these matter to you, they are worth raising on the first call rather than in week three.
That is the acceptance criterion. Trial balance, party-wise outstanding and stock value are reconciled against Tally's own reports for the cutover date, and the variance report has to resolve to zero before sign-off. Any deliberate difference, such as a corrected misposting, is documented and approved rather than absorbed.
You can keep Tally available as a read-only archive, and most businesses do. Running both as live systems is a different matter: dual entry is where data drifts apart, and it usually creates more reconciliation work than it saves in comfort.
The load itself is fast. The time goes into mapping decisions and reconciliation, which is why the profiling stage comes first. For a single company with reasonably clean books, four weeks alongside the wider implementation is a realistic planning assumption.
Open invoices are loaded as opening invoices carrying their original dates, so ageing buckets in ERPNext reflect the real age of the debt rather than resetting to the migration date. Advance payments and on-account amounts are carried the same way.
Yes, and it is common where branches or divisions were kept separate. The work is mostly master data rather than migration: item, customer and supplier codes are rationalised across companies first, because merging balances before merging masters produces a consolidation nobody can read.
Cutover is normally scheduled at a period boundary and over a weekend or a low-activity window. Tally entry stops, the final extract is taken, the load and reconciliation run, and users start in ERPNext. The pause is measured in hours rather than days.
A short call about what is actually in your books. We will tell you what will migrate cleanly and what will need decisions.
Tally, Tally ERP 9 and TallyPrime are trademarks of Tally Solutions Pvt. Ltd. ERPNext and Frappe are trademarks of Frappe Technologies Pvt. Ltd. These names are used here only to identify the software described. Finstein is not affiliated with or endorsed by Tally Solutions Pvt. Ltd.
