Migrate from Tally to ERPNext

Migrate from Tally to ERPNext: what the move involves and how long it takes

A Tally Prime company moving to ERPNext usually needs to carry over GST registrations, a stock register and years of party balances, and the first question is what the move actually covers. The documented path is Frappe's Tally Migrator app, which brings over masters and opening balances. Historical sales and purchase invoices, payments and journal entries are not migrated, and TDS, TCS, HR and payroll are not supported yet, so each of those is separate work that your team or a partner must plan, build or carry forward manually.

Effort depends far more on the state of your Tally data than on the tool itself. Duplicate ledger names, inconsistent stock item units, unmapped batches, and parties without GSTIN details all have to be fixed before the export, or the validation step will surface them one by one. Scope also drives the work: a single company with a clean chart of accounts is a very different job from a multi-godown business with bills of materials and foreign-currency balances. No duration figure is supplied for this path, so ask for a timeline only after a trial migration on a copy of your company, and confirm with the Tally Migrator repository which masters and balances your version handles.

Which Tally masters and balances come across, and which do not

This table compares Tally objects with their ERPNext equivalents and shows what Tally Migrator carries over, what needs a different route, and what it leaves out entirely. Read each row as a question to settle before the build: what the Masters XML contains, whether the target field exists, and who will rebuild the rest. The main takeaway is that the Migrator moves masters and opening balances, so historical transactions and statutory items need separate handling.

Tally object	ERPNext equivalent and migration note	Migrated by Tally Migrator
Parties (customers and suppliers)	Customer and Supplier masters, with groups; confirm GSTIN and address fields after import	true
Stock items and units of measure	Item and UOM masters; check item groups and unit conversions before loading	true
Price levels	Price Lists; confirm how each Tally level maps to an ERPNext price list	true
Bills of materials	BOM records; verify components and quantities against production samples	true
Batches	Batch records linked to items; confirm batch expiry data is complete	true
Chart of accounts and cost centers	Account and Cost Center trees; review parent groups before cutover	true
Warehouses	Warehouse masters; confirm the warehouse hierarchy matches your stock locations	true
Opening balances, including foreign-currency balances	Opening entries; reconcile against Tally's opening trial balance in the report	true
GST fields on parties and items	Requires the India Compliance app; confirm GSTIN, HSN and tax templates after import	true
Historical sales and purchase invoices	Not migrated; reload open items or keep Tally for history	false
Payments and journal entries	Not migrated; record cutover balances through an opening entry instead	false
TDS and TCS	Not supported by Tally Migrator; configure tax rules and loads separately	false
HR and payroll	Not supported; plan a separate HR data load if needed	false

Which importers and export paths to use for each data set

Tally data does not move through one path. Masters and opening balances go through Tally Migrator, Indian GST fields depend on a companion app, and anything the Migrator leaves out goes through ERPNext's standard importer. Decide the route for each data set before anyone exports, so the reconciliation has a clear owner for every balance.

Tally Migrator for masters and balances

Frappe's Tally Migrator app reads a Masters XML file uploaded from your browser rather than connecting to Tally live. It validates the file before writing anything, produces a reconciliation report against Tally's opening trial balance, and can undo a whole migration if the result is wrong. Plan a test run on a non-production site first, and confirm the app version matches your ERPNext release.

Masters XML export from Tally

Export with All Masters selected and dependent masters included, so parties, items, groups, BOMs, batches and cost centers arrive with the records they reference. Closing balances must be exported as opening balances. Export from the exact Tally Prime company you intend to migrate, and keep the file unchanged so the reconciliation can be repeated.

India Compliance for GST fields

Tally Migrator needs the India Compliance app to populate GST fields on parties, items and invoices. Install and configure it before the migration run, and confirm GSTIN and tax templates are set up as your returns require. GST registration details and tax rules are a finance and tax decision, so have your tax advisor confirm them rather than relying on the import defaults.

ERPNext Data Import for other records

Records outside the Migrator's scope, such as open invoices you choose to recreate, supplier-specific attributes or extra customer contacts, load through ERPNext's Data Import tool from CSV or Excel files built on the downloadable templates. Import a few thousand records at a time, and test a small batch before the full load so child table rows and links resolve correctly.

Manual work for unsupported items

Historical sales and purchase invoices, payments, journal entries, TDS and TCS, and HR and payroll are not migrated by Tally Migrator. Decide early whether these stay in Tally as archived records, are recreated manually, or are loaded through Data Import. Each choice changes what your finance team must reconcile after cutover.

Server Scripts for custom logic

If your migration or post-migration logic depends on Server Scripts, note that from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them. Confirm this setting with your hosting plan before you design any custom validation or cleanup step around it.

How the Tally Migrator flow runs from export to reconciliation

The finance lead owns the source of truth. Before anything is loaded, this person confirms which Tally Prime company is the migration source, which financial period is the cutover point, and what the opening trial balance in Tally shows at that date. The Tally Migrator README describes an export of Masters XML with All Masters selected, dependent masters included, and closing balances exported as opening balances. The finance lead should confirm the exact export menu steps in the app's README, because they depend on the Tally Prime release in use.

Fix the cutover date: Agree the period end whose closing balances become ERPNext opening balances.
Export the masters file: Produce the Masters XML export described in the README, with dependent masters and closing balances included.
Record the Tally trial balance: Keep a signed copy of the opening trial balance as the comparison baseline.
Review the reconciliation report: The app produces a report comparing Tally's opening trial balance with ERPNext, and finance should review every difference.
Own the sign-off: Decide which residual differences are acceptable and document why.

Confirm with the app's README which history is excluded, since transactions such as invoices and payments are not migrated.

The sequence from inventory to parallel run and cutover

This sequence moves Tally Prime books into ERPNext in a controlled order, so that each stage produces evidence the next stage depends on. The end state is a verified opening position, a tested pilot, a reconciled parallel run and a dated cutover after which Tally is no longer used for live work.

Inventory companies, masters and stock
Your team lists every Tally company in scope, along with its ledgers, groups, stock items, units of measure, price levels, bills of materials, batches, cost centers, warehouses and godowns. Confirm which companies move, which masters are duplicated or obsolete, and which features (such as TDS, TCS or payroll) sit outside what Tally Migrator covers. The output is a signed-off inventory that decides what goes into the Masters XML export and what is handled by hand or by Data Import.
Clean masters before the export
Fix duplicate parties, inconsistent item names, missing GSTIN and state details, and ledgers placed under the wrong groups while the data is still in Tally. Cleaning at this stage is cheaper than correcting ERPNext records after import. The output is a Tally company whose masters have been reviewed by the people who own customers, suppliers and stock.
Export the Masters XML and archive it
Export the masters from Tally with All Masters selected, with dependent masters included and closing balances exported as opening balances, as the Tally Migrator README describes. Keep the file and a dated copy of the Tally company as the reference for every later comparison. The output is an archived export file and a record of the Tally version and company used.
Run a pilot import on a test site
Install the Tally Migrator app and, for GST fields, the India Compliance app on a non-production ERPNext site running a version the app supports. Upload the export, let the validation run, and review every error before writing. Confirm that parties, items, BOMs, batches, the chart of accounts, warehouses and opening balances land where the inventory expected. The output is a pilot log with each validation issue, its fix and its re-test, and a decision on whether the export is accepted.
Reconcile the opening trial balance
Compare the reconciliation report that Tally Migrator produces, which sets Tally's opening trial balance against the ERPNext result, and investigate every difference. Typical causes include ledger mapping choices, foreign-currency balances, and items that the app does not carry across. Your finance team decides on each difference and records the reason. The output is a reconciled opening trial balance on the test site with no unexplained differences. Layered validation and finance sign-off are covered in the linked page on validating an ERPNext data migration before go-live.
Run a parallel period in both systems
Keep Tally as the system of record for live transactions while the same closing position is loaded into ERPNext and checked against it. Post a sample of real sales, purchases, receipts and payments in both systems during this period to test the processes, and reconcile stock and receivables at the end of it. Remember that Tally Migrator brings masters and opening balances only, so historical invoices and payments are not in ERPNext unless you load them separately. The output is a set of matched closing positions and a list of process gaps closed before cutover.
Cut over at a period end
Freeze Tally at an agreed period end, run the final export and import on the production ERPNext site, and repeat the reconciliation against the frozen Tally position. Confirm that users can post in ERPNext and that the GST returns and reports they depend on are available. Use the linked page on ERPNext opening balances and go-live cutover for the opening invoice, bank and stock steps. The output is a production site whose opening position matches the frozen Tally closing position and a signed cutover record.
Decommission Tally access
Once the cutover record is signed, make Tally read-only for the migrated companies, keep an archived backup that your auditors and tax advisers can access, and remove user access and licenses that are no longer needed. Confirm the retention arrangements for the archive with your finance and compliance leads, because they set how long the export and data must remain available. The output is a closed Tally environment with a documented archive location and a list of access removed.

What drives the effort and cost of a Tally to ERPNext move

This table lists the factors that change the effort and cost of moving Tally Prime books into ERPNext, and whether each one is paid once or recurs. Read each row as a question to answer before you ask for a quote, because the Migrator covers masters and opening balances only and everything else is scoped separately.

Driver	Why it changes cost or effort	One-time or recurring, and what to ask for in a quote
Companies and financial years carried	Each Tally company is a separate load with its own masters and opening position, so more companies multiply reconciliation and sign-off work.	One-time. Ask the quote to list each company, the cutover date and whether any prior years are carried or only closing balances.
Party and item master quality	Duplicate ledgers, inconsistent names and missing GSTINs or units slow validation and manual correction before any file is loaded.	One-time. Ask who cleans the masters, the cleanup checklist and how many validation rounds are included.
Batch and BOM complexity	Batch-tracked stock and multi-level bills of materials need checking against warehouses and manufacturing setup in ERPNext after the import.	One-time. Ask whether batches and BOMs are in scope for verification and which items are sampled.
Foreign-currency balances	Foreign-currency opening balances need the right currency and exchange setup in ERPNext before they can be reconciled with Tally's trial balance.	One-time. Ask how currency balances are reconciled and who signs off the revaluation position.
GST configuration with India Compliance	The India Compliance app must be installed and configured for GST fields, and tax templates and registrations must match the Tally setup.	One-time setup, with recurring upkeep when GST rules change. Ask who configures GST and who maintains it after go-live.
Custom Tally reports and voucher types	Custom voucher types or reports in Tally have no direct equivalent in the Migrator, so each one needs mapping or a rebuild in ERPNext.	One-time for mapping, plus ongoing work if reports must be recreated. Ask for an inventory of custom reports and a mapping list.
TDS and TCS handling outside the Migrator	The Migrator does not yet support TDS and TCS, so balances and rules for these must be set up and verified separately.	One-time setup, with recurring compliance work each filing period. Ask who owns TDS and TCS configuration and testing.
Payroll and HR data	Tally payroll and HR records are not covered by the Migrator, so they need a separate source, import and HR setup.	One-time for migration, with recurring payroll runs. Ask whether HR is in scope and which tool carries it.
Historical transactions	Sales and purchase invoices, payments and journal entries are not migrated, so any history you need must be exported and loaded or kept in archive.	One-time. Ask which transactions are carried, whether they are imported through Data Import, and how they are verified.
Integrations and users to train	Bank feeds, e-invoicing, ecommerce or other connectors and user training add build and change work beyond the data load.	Integration build is one-time, but licenses, hosting and support recur. Ask for each integration, the owner and the training plan.

What usually goes wrong with a Tally migration and how to prevent it

Most Tally migrations that stall do so for predictable reasons: the scope was misunderstood, the masters were not clean, or the books kept changing during the parallel run. The cards below pair each risk with a check you can run using Tally Migrator, the India Compliance app and ERPNext's standard import tools.

Assuming history comes across

Tally Migrator moves masters and opening balances, not historical transactions such as sales and purchase invoices, payments or journal entries. Teams that expect years of vouchers to appear in ERPNext often discover the gap during audit or GST review. Decide early which history stays in Tally as a read-only reference and which open items must be recreated in ERPNext as opening documents before cutover.

GST masters not set up before import

Tally Migrator needs the India Compliance app for GST fields, so party GSTINs, tax categories and item tax details should be configured in ERPNext before the masters load. Missing or malformed GSTINs on parties are easy to miss in a large list. Check each GST-registered party and item against the source records, and confirm the India Compliance setup with your tax adviser before the first full run.

Duplicate or inconsistent names

Tally often holds the same customer or stock item under several spellings, and ERPNext will create each as a separate record. Clean and deduplicate party and item names in Tally before exporting the Masters XML, then review the imported list against the source. Where a late correction is needed, use the Data Import tool with updates rather than re-keying records by hand.

Opening balances not matching Tally

The reconciliation report compares Tally's opening trial balance with ERPNext, and it is the control that proves the load is correct. Balances that differ by a small amount often trace to a foreign-currency rounding issue or a missing group. Do not sign off until the trial balance matches line by line, and keep the report as evidence for finance review.

TDS and TCS gaps

Tally Migrator does not yet support TDS and TCS, so withholding and collection positions must be carried over another way. Ask your finance team to list open TDS and TCS balances and parties, then decide whether they enter as manual opening entries or are rebuilt in ERPNext's configuration. Confirm the approach with your auditor before cutover, since the gap affects tax returns.

Uncontrolled edits during parallel run

If users keep posting in Tally while the migrated ERPNext site is tested, the two books diverge and the reconciliation no longer means anything. Set a freeze date, restrict voucher entry in Tally to an agreed owner, and log any change made after the export. Re-export and rerun the reconciliation when the freeze is lifted, so the final opening position reflects the agreed cutover date.

How much effort does a Tally to ERPNext migration take, and what do we need to do ourselves?

Does Tally Migrator move our sales and purchase invoices into ERPNext?

No. Tally Migrator moves masters and opening balances, not historical transactions. Sales and purchase invoices, payments and journal entries stay in Tally unless you load them separately. Most teams therefore decide early how much history to keep in ERPNext, usually just enough to support open items, outstanding receivables and payables, and the period comparisons they need. Anything older stays in an archived Tally file or a read-only export that finance can consult. Settle this scope with finance before any data is prepared, because it determines how much cleanup and reconciliation the project carries.

Can our own finance and IT team run a Tally to ERPNext migration alone?

Often yes for a small, clean company with one entity, a simple chart of accounts and a single warehouse, provided someone on the team is comfortable with ERPNext administration and with the Frappe bench or hosting environment. The work is still a project: exporting the Masters XML, reviewing the output, running the migration, checking the reconciliation report and fixing differences. Teams with multiple companies, complex batch or BOM structures, foreign-currency balances or limited ERPNext experience usually find the validation and cutover steps take more time than expected. Ask yourself whether the people who will sign off the books have the hours to do it in the cutover window.

What does the GST setup need, and is India Compliance required?

Tally Migrator needs the India Compliance app to populate GST fields, so the GST configuration must be in place before the import is run. The work includes confirming GSTIN and tax registration details for each company and party, mapping Tax Templates to the rates used in Tally, and checking that HSN or SAC codes on items are complete and correct. Finance should review the GST ledgers in the reconciliation output against the last filed returns. The effort rises with the number of registrations, states and tax rates in use. Confirm the India Compliance version that matches your ERPNext release with the app's documentation before you plan the build.

What do finance and IT each need to provide during the migration?

Finance owns the decisions and the sign-off. They need to confirm the chart of accounts and cost centers to keep, the closing date and opening balances, which parties and items are active, and which foreign-currency balances must be preserved. They also review the reconciliation report comparing Tally's opening trial balance with ERPNext. IT owns the environment and the export. They need to provide a Tally Prime machine with access to the company data, a clean Masters XML export with All Masters and dependent masters included, a ERPNext site with the right app versions installed, backups before each run, and a named person for user access and permissions. Agree on these roles in writing before the first test run.

What drives the cost of a Tally to ERPNext migration up or down?

The main drivers are scope and data quality. Cost rises with the number of companies, the size of the item and party masters, how many BOMs and batches need to carry over, how many foreign-currency balances exist, and how many duplicates, misspelled names or unused ledgers must be cleaned before the export. Work also grows with the number of test runs needed to reach a clean reconciliation, and with any custom reports, print formats or integrations you want rebuilt. Cost falls when the chart of accounts is already tidy and the opening position is verified early. Ask any partner for a fixed-scope quote that lists each of these items, and state which data cleanup is included and which remains with your team.

Do TDS, TCS and payroll need separate work after the masters are loaded?

Yes. Tally Migrator does not yet support TDS and TCS or HR and payroll, so those areas need their own plan. For TDS and TCS, decide how withholding and collection will be configured in ERPNext, how opening deductions and certificates are handled, and how the next return will be produced. For payroll, decide whether employee records, salary structures, leave balances and statutory liabilities move into ERPNext's HR tooling or stay in a separate system, and who loads them. Each of these areas adds configuration, testing and sign-off effort, so raise them early in scoping rather than discovering them at cutover.

When is outside help worth paying for in a Tally migration?

Outside help tends to pay off when the chart of accounts, batch or BOM structure, foreign-currency balances or GST setup are complex, when the cutover date is fixed and cannot slip, or when the internal team lacks ERPNext and Frappe experience. A partner is also useful for validating the reconciliation layers and documenting the process so the next period close can be repeated. Ask for a written scope that names the deliverables, the reconciliation evidence, the rollback plan and what remains with your team. DeployOpen plans and runs these engagements as fixed-scope work agreed in writing before the work starts, with a quote following from that scope.

What still needs Data Import or manual work after the Migrator runs

The Migrator's scope ends at masters and opening balances, so a migrated Tally company is not yet a working ERPNext company. Historical sales and purchase invoices, payments and journal entries are not carried across, and TDS and TCS are not supported yet. HR and payroll are also outside the Migrator. Before cutover, list every area where your books depend on something the Migrator does not move, and assign an owner and a decision for each: rebuild, import, or keep in archive. Confirm the current limits against the Tally Migrator repository for the version you run, since the README is the authoritative scope statement.

Data Import fills the gaps that the Masters XML does not contain, such as contacts, addresses, customer or supplier details your Tally ledgers did not hold, or records you choose to load from a controlled CSV or Excel file. Use the downloadable templates, load small test batches first, and check child table rows (for example, addresses or item rows) separately from parent records. Load in dependency order so that parties, items and accounts exist before any document refers to them. Keep each source file under version control so a failed batch can be explained and repeated.

Decide early whether open items need rebuilding in ERPNext. Open receivables and payables are usually entered as opening balances, but a partly paid invoice or an advance may need a specific document so that collections can be matched later. Historical invoices needed for returns, GST filing or audit queries are often better kept in a read-only archive with a reference from the migrated party, instead of being recreated by hand. Tally reports and voucher logic also need a plan: when your finance team relies on a specific report, confirm which ERPNext report or custom report replaces it before go-live.

How DeployOpen scopes and delivers a Tally to ERPNext migration

The sequence turns Tally Prime masters and closing balances into a reconciled ERPNext opening position, with scope agreed in writing before any data moves and the finance team signing off each stage.

Agree the migration scope in writing
DeployOpen reviews your Tally Prime company files, the ERPNext environment you plan to use, and the GST and reporting needs of your finance team. The written scope lists which masters, opening balances and reports move, which history stays in Tally, and what is out of scope, such as TDS and TCS or payroll, which the Tally Migrator does not yet support. The fixed scope, deliverables and timeline are confirmed in writing before work starts. Done when your finance lead has approved the scope document.
Confirm the target environment and app versions
DeployOpen checks that the ERPNext version, Frappe Framework version and the India Compliance app are compatible with the Tally Migrator, which is built and tested for ERPNext v16 and Tally Prime. Where the environment is new, the team installs ERPNext on your infrastructure, confirms backups and access controls, and records the exact app versions. Done when a test site runs the planned versions and a restore has been rehearsed.
Export and review the Tally masters
Your team exports a Masters XML file from Tally Prime with All Masters selected and dependent masters included, with closing balances exported as opening balances. DeployOpen reviews the file for duplicate parties, inconsistent item units, missing GSTIN values and accounts that need renaming before import. Done when the cleaned export is saved, the review list is agreed, and your finance team has signed off the open items.
Run a pilot import on a test site
DeployOpen uploads the Masters XML to a test ERPNext site with the Tally Migrator, which validates the file before writing. The team checks the imported parties, items, BOMs, batches, chart of accounts, cost centers, warehouses and opening balances against the source, and records any items that need manual work or a Data Import run afterwards. Done when the pilot completes, the migration can be undone and repeated cleanly, and the exception list is agreed.
Reconcile against Tally with finance
The Tally Migrator produces a reconciliation report comparing Tally's opening trial balance with ERPNext. DeployOpen and your finance team work through each difference, isolating causes such as foreign-currency rounding, accounts mapped to different groups or balances that need correction in Tally before a final load. The output is a signed reconciliation that shows the opening position matches. Done when the difference list is zero or each residual item has a documented reason and owner.
Load the final data and handle remaining records
DeployOpen runs the full migration on the production site at an agreed cutover point, then loads anything the Tally Migrator does not cover, such as open records or templates handled by ERPNext's Data Import tool, in batches. Historical sales and purchase invoices, payments and journal entries are not migrated by the Tally Migrator, so the agreed approach for them is confirmed during scoping. Done when the final reconciliation passes on the production site.
Hand over, document and offer support
DeployOpen documents the migration run, the reconciliation evidence, the mapping decisions, the remaining manual steps and the recovery procedure, then trains the users who will operate ERPNext. Ongoing support, upgrades and testing are available as a retainer that is agreed separately from the fixed-scope migration. Done when your team has the handover pack, the finance sign-off is recorded, and the support option is either accepted or declined in writing.

Migrate from Tally to ERPNext