Validating an ERPNext data migration before go-live

How do you prove an ERPNext data migration is complete before go-live?

Validation is a layered reconciliation that starts with counts and mappings and ends with control accounts and the trial balance, and a migration is only complete once the finance owner has reviewed the results and approved them in writing. If your finance and IT team has loaded, or is about to load, masters, open items and balances into ERPNext, the question is not whether the totals look right but whether each layer agrees with the old system and every difference has a named cause. ERPNext's own validation guide works in this order: master counts and mappings, imported document counts and totals, subledger schedules, control accounts, then the Trial Balance, Balance Sheet and Profit and Loss, with operational testing after that. Keep the layers separate, because a match at the top does not prove the layers beneath it.

Effort depends mainly on how many parties, items, warehouses, cost centers and open documents you are moving, and on how cleanly the source system exports them. No effort figure is given here. Ask any partner for a quote that lists the reconciliation layers, the number of source reports to be matched, who prepares each schedule, and who signs off. The accounting migration overview recommends at least one test migration before the final cutover, so budget for a full rehearsal that runs the same reconciliation on a copy of the load, then repeat it on the production load. Confirm with your finance owner which differences are acceptable, which must be zero, and how they will be documented, before the first load begins.

Be aware that an exact Trial Balance can still hide errors. A party, warehouse or cost center may be mapped to the wrong target while the totals still agree, so the subledger and dimension checks matter as much as the headline numbers. Plan for a difference log that records each variance, its cause, its fix and the test run in which it was cleared, and treat any unexplained difference as a blocker. Once the rehearsal reconciles and the finance owner approves the results, the same checks become the acceptance evidence for cutover. Read the ERPNext validation guide alongside your own chart of accounts, since the checks you need depend on how your books are structured.

Which source reports reconcile to which ERPNext reports

This table pairs each check a reviewer runs on the old books with the ERPNext report or document that should produce the same figure. Read each row as a comparison: take the total from the source system, take the matching total from ERPNext on the same cut-off date, and investigate any gap before sign-off. Exact report names and filters depend on the source system and your chart of accounts, so confirm them in a test migration.

Check	Source system evidence	ERPNext report or document	Typical migration note
Master record counts	Customer, supplier, item and account lists exported at cut-off	Data Import log and list views for Customer, Supplier, Item and Account	Duplicates merged in the source can appear as extra records if the cleanup was not carried into the import file.
Open receivables	Open customer invoices aged by customer at cut-off	Accounts Receivable report and Sales Invoice list filtered to opening entries	Differences often come from customer mapping, where one source customer was split into several ERPNext parties.
Open payables	Open supplier bills aged by supplier at cut-off	Accounts Payable report and Purchase Invoice list filtered to opening entries	Supplier currency or tax template differences can change totals even when the invoice count matches.
Bank balances	Bank statement closing balance and reconciled items at cut-off	Bank Reconciliation tool and the bank account ledger in General Ledger	Unmatched opening transactions usually point to a bank account mapped to the wrong ledger account.
Stock valuation	Item quantities and values by warehouse at cut-off	Stock Balance report and Stock Ledger, compared by warehouse	Warehouse mapping errors move value between locations while the total still agrees.
Fixed assets	Asset register with cost, accumulated depreciation and net book value	Asset list and Fixed Asset Register report	Assets split or merged during import can change counts while cost totals still match, so compare both.
Trial balance and statements	Trial balance, balance sheet and profit and loss at cut-off	Trial Balance, Balance Sheet and Profit and Loss reports with the same period and company filter	An exact trial balance can still hide party, warehouse or cost center mapping errors, so check the subledgers first.

The validation sequence from master counts to finance sign-off

The sequence moves from simple checks on masters to full financial statements, so each difference is found at the layer where it first appears. It ends with a finance owner approving the results, which is the point where the migration counts as complete.

Confirm master counts and mappings
Before any transactions are compared, the team checks that the migrated masters match the source: companies, charts of accounts, customers and suppliers, items, warehouses, cost centers and tax templates. Each source record should map to exactly one ERPNext record, and the mapping table should be signed off by the data owner. The step closes when every master has a count match and an agreed mapping, with any gaps logged as open items.
Compare imported document counts and totals
Next, the team compares the number and value of imported documents such as opening invoices, payments, journal entries and stock entries against the source extract. Counts and totals are checked per document type and per period, and rejected rows from the Data Import tool are reviewed and either corrected or recorded as exceptions. The step closes when every document type reconciles or each remaining difference has a logged cause and owner.
Reconcile subledger schedules
The accounts receivable, accounts payable, stock and asset schedules are compared with their source aging and valuation reports. Party-level balances are checked customer by customer and supplier by supplier, so that a total can be traced to individual parties. The step closes when each subledger total agrees with its schedule at the party or item level, and every difference is isolated to a named record.
Tie out control accounts to subledgers
Each control account in the general ledger, such as receivables, payables, inventory and fixed assets, is compared with the total of its matching subledger. This layer separates posting problems from data problems, because a control account that differs from its subledger points to an import or mapping error rather than a difference in the books themselves. The step closes when every control account ties to its subledger or the gap is traced to a specific document batch.
Compare the trial balance, balance sheet and profit and loss
The trial balance is compared account by account with the source, then the balance sheet and profit and loss statement are compared for the same period and company. ERPNext's guidance warns that an exact trial balance can still hide party, warehouse or cost center mapping errors, so the team also spot-checks dimension splits in the statements. The step closes when the three statements agree with the source and the dimension-level spot checks show no unexplained mapping errors.
Run operational tests on migrated data
The team runs real business processes on the migrated data, such as paying an open invoice, receiving stock against an opening balance, closing a period, and running the standard financial reports. This shows whether the migrated records behave correctly in workflows, not only in totals. The step closes when the agreed scenarios complete without errors and each result is recorded against the test script.
Log and resolve differences across each layer
Throughout the sequence, every difference is recorded in a single log with the layer where it appeared, the source and ERPNext values, the suspected cause, the owner and the resolution. Fixes are applied in the source mapping or import file and the affected layers are rerun, so that results from a test migration can be compared with the next run. The step closes when the log holds no unexplained differences, and the team can show which fixes changed which results.
Obtain finance owner approval
Before the final load, the migration is repeated at least once as a test, as ERPNext's accounting migration overview recommends. The finance owner then reviews the reconciliation results and the difference log, and signs off the migrated position. The migration is treated as complete only when that approval is recorded. Read the full method in the ERPNext validation guide before setting the sign-off criteria.

Which ERPNext tools and reports support each validation layer

The data team owns the layers that come before any balance is compared: master counts, mappings and imported document counts. ERPNext's Data Import tool is the main instrument here. It loads and updates records from CSV or Excel files or public Google Sheets, using downloadable templates for each DocType. It also supports child table rows, such as the items on an invoice, so parent and child data must be prepared together in the file. The documentation advises importing only a few thousand records at a time, so large sets should be split into batches that can be counted and re-run independently.

Templates first: Download the template for each DocType and build the source file from it so column headers match what the importer expects.
Child rows: Keep the parent identifier identical across all child rows of a document, or lines will attach to the wrong parent or fail.
Batch size: Import in chunks of a few thousand records and log the count of each batch against the source extract.
Re-runs: Because the tool can update existing records, use stable identifiers so a corrected batch overwrites rather than duplicates.
Count checks: Compare the number of records created per DocType with the source count after each batch.

Before finance reviews anything, confirm that every batch reconciles to its source count and that the template version matches the ERPNext version you are migrating into.

Standard reports answer most comparison questions, but some checks are specific to your chart, such as confirming that every imported invoice maps to a valid party group, warehouse or cost center, or flagging documents whose totals differ from the source line sums. Where these checks cannot be expressed through reports or filters, teams may consider a custom script. Server Scripts run Python on document events or as API endpoints. 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, so a script-based check requires a bench where the setting can be turned on.

Availability: Confirm that server_script_enabled is set on the bench where checks run, and record that setting in the migration plan.
Scope: Use scripts for read-only verification queries where possible, and keep them separate from production data logic.
Change control: Store the script text in version control and record who approved its use during the migration window.
Removal: Decide whether checks are disabled or deleted after cutover, so temporary logic does not remain in production.
Alternatives: Where a script is not permitted, export both sides to spreadsheets and run the comparison outside ERPNext, with the outcome recorded.

Before relying on a custom check, have finance and the data team agree in writing what the check tests and what result counts as a pass.

Why an exact trial balance can still hide mapping errors

A matching trial balance proves that the totals by account agree with the old system. It does not prove that each amount landed on the right party, warehouse or cost center. An exact trial balance can still hide mapping errors, because a receivable posted to the wrong customer, or stock valued in the wrong warehouse, still sits in the correct control account. ERPNext's migration validation guide places the trial balance near the top of the reconciliation layers for this reason, so the checks beneath it need to be run before finance signs anything off. Work down the layers in order: master counts and mappings, imported document counts and totals, subledger schedules for receivables, payables and stock, control accounts, and then the financial statements. Each lower layer should explain the layer above it.

When a difference appears, isolate it instead of adjusting around it. Start with the layer where the variance first shows up, then narrow it by document and by mapping table. Export the source balances by party, item, warehouse and cost center, compare them against the ERPNext subledger reports for the same date, and list only the mismatched keys. Check the mapping tables you built for parties, accounts, warehouses and cost centers, because one wrong row can move many documents at once. Confirm the test migration you ran earlier shows the same pattern, since a repeat in a trial run points to a mapping issue rather than a one-off data error. Ask the finance owner to confirm which differences are material before you investigate further, so effort goes to the amounts that matter.

Once a difference is isolated, decide among three outcomes. A data fix applies when the source record is wrong or incomplete and should be corrected in the old system or in the import file, then reloaded in a controlled batch. A mapping fix applies when the logic that links old values to ERPNext masters is wrong, and the fix should change the mapping table and rerun the affected load, not a manual journal entry. An accepted, documented variance applies when the difference is understood, immaterial or caused by a known rounding or timing gap. Record each accepted variance with its cause, amount, owner and the finance owner's approval, because the migration only counts as complete once that approval is in place. Confirm with your finance owner which variances they will accept before cutover, not after.

What makes ERPNext migration validation take longer

Validation effort is set less by the software than by the state of the source data and the number of people who must agree the result. The drivers below push time and cost in different directions, and most of them compound when they appear together in one migration.

Volume of source entities and open items

Every party, item, account and open invoice must be counted and matched on both sides before any balance comparison means anything. A larger master set and more unpaid documents at cutover multiply the number of counts, sample checks and exception lists. Ask the implementer how each count will be produced, and whether the source export is itself reconciled to the source ledger before import.

Number of companies and currencies

Each company has its own chart of accounts, ledgers and period close, so each one needs its own trial balance and control account checks. Multi-currency books add revaluation and exchange difference questions that a single-currency comparison does not raise. Effort grows roughly with the number of company and currency combinations, so confirm which pairs must be reconciled separately.

Quality of source data and duplicates

Duplicate parties, inconsistent item codes and free-text tax IDs in the source system tend to surface as mapping errors after import. Each one forces a decision: merge, keep separate or correct at source. Cleanup before import is usually cheaper than investigating differences afterward, so ask how many duplicate candidates were found and who approves each merge.

Number of test migrations

The accounting migration guidance recommends at least one test migration before the final cutover. Each additional trial run repeats the full reconciliation, and differences found in one trial often require changes to mappings, import order or opening balance treatment. Ask how many trial loads are in scope, what each one must prove, and whether the fixed scope includes re-running the reconciliation for each.

Stock and asset complexity

Warehouses, serial numbers, batches, valuation methods and fixed asset depreciation schedules each need their own reconciliation against the source records. Stock value is often the hardest balance to tie out, because quantities, valuation rates and warehouse mapping must agree at the same time. Ask whether stock and asset balances are validated item by item or only at total value.

Number of reviewers who must sign off

A migration is complete only after the finance owner approves the results, and many organizations also require sign-off from operations, tax and internal audit. Each reviewer adds a round of questions, evidence requests and rework. Agree the list of approvers, the evidence each one expects and the format of the sign-off record before testing begins.

Questions buyers ask about validating an ERPNext migration

How much effort does validating an ERPNext migration take?

Validation effort depends mainly on how many books, parties, items, warehouses and open documents you are moving, and how many test loads you run before cutover. The ERPNext migration guidance reconciles in layers, starting with master counts and mappings, then imported document totals, subledger schedules, control accounts and the three core financial statements, before operational testing. Each layer adds work, and a mismatch found late usually means repeating earlier layers. Ask a partner to break the effort into those layers in the written scope, and to state how many test migrations are included. The Accounting migration overview recommends at least one test migration before the final cutover.

How long does validation take compared with the data load itself?

Validation usually takes longer than the load, because each load produces results that finance must check against the source system. The load can be scripted or repeated, but reconciliation needs people to compare totals, explain each difference and confirm the fix. The ERPNext Data Import documentation advises importing only a few thousand records at a time, which means large books are loaded in batches and checked batch by batch. Ask for the number of test cycles and the time reserved for finance review in the plan, and confirm that the schedule accounts for at least one full dress rehearsal before the cutover period.

What does validation need from finance and IT?

Finance owns the decision that the migration is complete, and IT owns the environment, the import runs and the evidence. Under the ERPNext accounting migration guidance, a migration is only complete after the finance owner validates and approves the results. Finance should provide the source reports, the chart of accounts mapping, the expected control account balances and named reviewers for each difference. IT should provide a clean test environment with matching ERPNext versions, access to source exports, and a record of every import run. Agree these responsibilities in writing before the first test load, so sign-off is not left to chance.

Can our internal team validate an ERPNext migration without a partner?

An internal team can validate a migration if it has people who understand both the source books and ERPNext accounting, and enough time for repeated test loads. The work is methodical: reconcile masters, documents, subledgers, control accounts and statements, then isolate differences. The main risk is independence, because the people who built the mapping are often the people checking it. An exact trial balance can still hide party, warehouse or cost center mapping errors, so someone outside the build should test those dimensions. Confirm your team has capacity for several cycles and a documented sign-off path. A partner can add an independent reviewer and a written scope.

Why can a matching trial balance still hide errors?

A matching trial balance proves the totals agree at the account level, not that each transaction landed in the right place. Parties can be mapped to the wrong customer or supplier, stock can be assigned to the wrong warehouse, and costs can be posted to the wrong cost center while the account totals still balance. For that reason, the validation guidance continues past the trial balance into subledger schedules and dimension-level checks. Ask your team to test receivable and payable ageing by party, stock valuation by warehouse, and profit and loss by cost center. Those checks catch errors that a single summary report will never show.

What should we ask a partner to include in a written validation scope?

Ask for a scope that names each reconciliation layer, the test migrations included, the source and target versions, and the evidence each layer will produce. Request the list of reports that will be compared, the tolerance for differences, the process for isolating and fixing each difference, and who signs off. Also ask how the partner handles difference logs, re-runs after fixes, and the finance owner's approval record. Confirm what is excluded, such as operational testing or post-cutover support, and whether any work recurs after go-live. Ask for the quote to follow directly from this written scope.

Does DeployOpen issue an audit report or attestation on the migrated books?

No. DeployOpen plans and performs the validation work and prepares the reconciliation evidence, but it does not issue audit reports, attestations or certifications. Your finance owner approves the migrated books, and your external auditors or certification bodies decide what assurance they give. Ask any partner to show you exactly which reports, logs and sign-off records the engagement produces, so your auditors receive a clear trail. Confirm that the scope states this boundary in writing.

What usually goes wrong in ERPNext reconciliation and how to prevent it

Most failed migration reconciliations do not fail loudly. They pass a headline check while errors sit underneath, or they stall because nobody owns the differences. The cards below cover the failure patterns we see most often and the controls that catch them before go-live.

Validating only the trial balance

A matching Trial Balance feels like proof, but it only shows that debits equal credits in total for each account. Party, warehouse and cost center errors can move balances between dimensions without changing the account totals. Before sign-off, reconcile receivables and payables to their subledger schedules, and check stock and asset values against their own reports, not just the control accounts.

Unmapped parties hidden by equal totals

When two customers or suppliers are mapped to the wrong master, or a warehouse receives stock that belongs elsewhere, the totals can still match. Compare party and warehouse level balances against the old system's aging and stock reports line by line. Investigate any party whose balance differs even when the grand total ties out.

Skipping the test migration

Running the load once, for the first time, on cutover weekend leaves no room to find mapping or import errors. ERPNext's accounting migration guidance recommends at least one test migration before the final cutover. Use each test run to log every difference, fix the import files and rerun, so the final load repeats a process that has already been checked.

Differences with no named owner

Reconciliation differences tend to sit in a shared log that nobody closes. Assign each difference a single owner, a root cause category such as import, mapping or source data, and a resolution or accepted-variance decision. Review open items in a fixed meeting until the log is empty or every remaining item has a signed explanation.

Sign-off by IT instead of finance

IT can confirm that data loaded, but only the finance owner can accept that the books are right. Make the finance owner accountable for approving the trial balance, subledger schedules and opening positions in writing. Migration is complete only after that approval, so record who approved which reports and against which test run.

Server scripts assumed to be enabled

Reconciliation checks often rely on custom server scripts to flag mismatches or fill mapping gaps. From version 15, Server Scripts are disabled by default and need the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Confirm the setting on the target environment during the test migration, or move the checks into a reviewed custom app.

What to confirm with your ERPNext version and source system

Before you build the reconciliation pack, confirm which ERPNext version your environment runs, because the report names, Data Import template fields and validation steps described in this guide can change between releases. Check version status on Frappe's supported versions page rather than relying on a copy of the guide you saved earlier. The page lists which major versions are supported and until when, so you can tell whether a go-live date falls inside a supported window. Also record the exact minor version you tested with. Validate the migration on the same version you will run in production, and rerun the test reconciliation if you upgrade between the test migration and cutover. Frappe's release notes show frequent minor releases on both supported major versions, so a patch applied after your test can change behavior you have already signed off.

Confirm the export format with your source vendor, not from memory or a forum thread. The layers in your reconciliation depend on what the old system can actually export: party and item masters, open invoices with due dates, bank and control account balances, stock valuation by warehouse, and fixed asset registers. Ask the vendor for a written description of each export, including the field names, date formats, decimal and currency handling, whether the export includes cancelled or reversed documents, and how it treats multi-currency or multi-company data. Run a small export on a copy of the source and compare its totals with the source screens before you rely on it. A file that looks correct in a spreadsheet can still drop rows or round amounts, and those gaps will surface later as reconciliation differences that are hard to trace.

Document these confirmations in the validation plan as dated, versioned records: the ERPNext version and app versions, the source system version, the export procedure and the person who approved it. Finance and the implementation team should both sign the plan before the test migration starts. If the source vendor changes its export layout or the ERPNext release changes an import template, the affected checks go back into review. Treat that re-review as a planned step with an owner, so that the last reconciliation before cutover is run against a known, documented combination of versions and exports.

How DeployOpen scopes and delivers ERPNext migration validation

DeployOpen plans, runs and documents the validation of an ERPNext data migration as part of a written scope, from master counts through the trial balance to finance sign-off. Each layer is agreed, tested against your source system and handed over as evidence your finance owner can review.

How we scope

Agree in writing which source system, periods, accounts and modules the validation covers before work starts.
Confirm the reconciliation layers, owners and the finance sign-off criteria that close the migration.
Engagements are fixed-scope, so deliverables and timelines are set in the written scope and quoted from it.

How we build

Prepare reconciliation workbooks that compare master counts, document totals and subledger schedules against the source.
Test the migration in trial runs, then compare control accounts, trial balance and statements to the source.
Isolate each difference to a party, warehouse, cost center or mapping rule before accepting any residual variance.

How we hand over

Deliver reconciliation results, difference logs and the mapping decisions behind each correction.
Document the test migrations and the final run so the same checks can be repeated at cutover.
Walk the finance owner through the evidence so approval is recorded against specific layers and totals.

How we support

Offer ongoing support and upgrades as a retainer when the validation extends past go-live.
Re-run the reconciliation pack after post-cutover corrections or late data loads, if the scope includes them.
Confirm with your team which checks belong in your own change control and which stay with the validation record.