Migrate from Excel spreadsheets to ERPNext

Migrate from Excel spreadsheets to ERPNext: what the move involves

Moving a finance or operations team from workbooks to ERPNext is mostly a data preparation and ordered loading exercise, not a software installation. The effort depends on three things: how many sheets hold live business data, how inconsistent that data is (duplicate customers, mixed unit codes, item names typed three different ways), and how many ERPNext modules go live at cutover. Accounting, stock and manufacturing each bring their own masters and dependencies, so a team that scopes modules first can size the work before touching a file.

ERPNext's Data Import tool loads records from CSV or Excel files using downloadable templates, and it supports child table rows, so a sales order with its line items can arrive in one file. The tool is built for controlled loads, not bulk dumps: the documentation advises importing only a few thousand records at a time. The documented accounting masters order is what keeps the process manageable. Groups and parent records load before company-independent and company-specific masters, then parties, items and warehouses. Confirm this sequence against the version you run, and download the template for each doctype instead of building one from memory, because column names and mandatory fields change between releases.

Before the full load, test two to five representative records per doctype, check the links they create (such as the item group, default warehouse and linked account), and correct the source sheet rather than patching records in ERPNext. Ask who owns each sheet, who signs off the cleaned version, and how opening balances will be verified against the last workbook closing position. Those decisions, not the import itself, usually determine the schedule and the cost of a quote, so put them in the written scope before work starts.

Which spreadsheet data maps cleanly into ERPNext and which does not

This table compares common contents of an accounting or operations workbook with their ERPNext equivalent and the migration step each one needs. Read it as a sorting guide: rows marked as clean masters can be loaded through Data Import, while formulas, macros and approval history need to be rebuilt or archived rather than carried over.

Spreadsheet content	ERPNext equivalent	Migration note
Chart of accounts	Account tree under each company	Import groups and parent accounts first, then leaf accounts. Confirm account types and root types before loading.
Customer and supplier lists	Customer and Supplier with contacts and addresses	Deduplicate on tax ID or registration number first. Child table rows for contacts and addresses can be loaded through Data Import.
Item lists	Item, with item groups and units of measure	Load item groups before items. Check that codes are unique and that variants or UOM conversions are captured explicitly.
Warehouse lists	Warehouse tree per company	Create parent warehouses before child locations. Stock levels are not loaded with the warehouse list.
Opening balances (receivables, payables, bank, stock)	Opening invoices, journal entries and stock reconciliation at cutover	Not a raw import. Bring verified closing positions in through a deliberate cutover with an opening account, not by pasting totals into masters.
Formulas and calculated cells	Stored values on documents, or report logic in ERPNext reports	Calculated cells do not carry over as logic. Export the resulting values where needed and rebuild any rule in ERPNext configuration.
Macros and VBA	Server Scripts or Client Scripts, if enabled for your deployment	Macros do not migrate. Server Scripts are disabled by default from version 15 and need the server_script_enabled setting, so confirm that policy before planning any rebuild.
Pivot tables and summary reports	Standard ERPNext reports and dashboards	Pivots are views, not data. Recreate the questions as reports and confirm each one against the migrated ledgers.
Child table data (lines, contacts, addresses)	Child table rows on a parent DocType	Data Import supports child table rows. Each row must reference its parent record, so load parents before their rows.
Approval logs and comments	Version history or a separate archive	Approval workflows are not replayed from old sheets. Keep the log as an archived file linked to the record or in a document store.

How to sequence the load from groups and parties to items and warehouses

The sequence makes each record reference a parent that already exists, so the load fails early on small batches instead of halfway through a full import. It ends with a verified set of masters and a cutover that retires the spreadsheets.

Inventory the spreadsheets and assign owners
List every workbook that holds masters or balances, such as the chart of accounts, customer and supplier lists, item lists and warehouse lists. Assign a named owner from finance and operations to each file and record which system or person is the source of truth for it. The step is done when every master has one owner and one authoritative file.
Clean and deduplicate each master
Remove duplicate parties and items, standardize codes, names and units of measure, and fill mandatory columns such as parent groups and default accounts. Agree the naming convention before any load, because the codes entered here become the keys that transaction records refer to later. The output is a cleaned sheet per master with a short log of merged or rejected rows, signed off by the data owner.
Load groups and parent records first
Import account groups, item groups, customer and supplier groups, and other parent records before any record that points to them. ERPNext's guidance on importing accounting masters says parent records must exist first, so a child row cannot be linked to a group that is not yet in the system. The check is that each group appears in the list view with the expected parent and no import errors remain.
Load company-independent and company-specific masters
Import masters that apply across companies, then those tied to a specific company, such as company-level accounts and cost centers. Download the Data Import template from ERPNext for each DocType rather than building the header row from memory, because template columns follow the version in use. The check is that the company-specific records are attached to the correct company in a sample review.
Load parties, items and warehouses in that order
Import customers and suppliers, then items, then warehouses, since items and transactions reference parties and warehouses. Keep the Data Import tool within the documented guidance of importing only a few thousand records at a time, and split larger sheets into batches. The check is that every item's default warehouse and every party's group resolves to an existing record.
Test with two to five representative records first
Before any bulk load, import two to five representative records per DocType, covering a simple case and the awkward cases such as multiple units of measure or child table rows. ERPNext's guidance recommends this test size. Open each imported record and compare every field with the source sheet. The step is done when the test records match the source exactly, and any mapping fix has been applied to the template.
Run test batches, then the full load
Run a few test batches of increasing size, fixing errors and re-running only the failed rows, then import the full cleaned set in the same order. Keep a record of each batch with counts of created, updated and failed rows. The full load is complete when the master counts in ERPNext match the cleaned sheets and the error log is empty or explained.
Reconcile, run in parallel and cut over
Reconcile master counts and key balances against the spreadsheets, then run the spreadsheet and ERPNext side by side for a period agreed with finance and operations. Once differences are explained and signed off, switch transactions to ERPNext and freeze the workbooks as read-only archives. The cutover is complete when the business has a signed reconciliation, and the spreadsheets are decommissioned with a documented retention location.

Documented import paths: Data Import, templates and what to use when

The Data Import tool in ERPNext imports and updates records from CSV or Excel files using templates that ERPNext generates for each DocType. It creates new records and can update existing ones, and it handles child table rows, such as item lines on an invoice or addresses on a party, as part of the same file. Use it as the main route for most spreadsheet records, but treat the file as a controlled input rather than a raw export.

Download the template: Generate the template for the target DocType from ERPNext so column headers match the current version's field names.
Keep one DocType per file: Separate parties, items and warehouses into their own files so each load can be checked and rolled back on its own.
Split large sheets: The documentation advises importing only a few thousand records at a time, so divide large sheets into batches and load them in sequence.
Use update mode deliberately: Updates match existing records, so confirm the identifier column before running a load that modifies data.
Check child rows: Confirm that each child row links to its parent row in the same file.

Before loading, ask your implementation partner which DocTypes you will import and in what order, and confirm the exact batch size they recommend for your server.

Server Scripts in Frappe run Python on document events or as API endpoints, and 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. Any cleanup or transformation that a script might have done therefore has to happen in the spreadsheet or your own tooling before the file reaches ERPNext.

Clean in the source: Trim spaces, normalize codes, and remove duplicate rows in the sheet before exporting.
Map values beforehand: Convert legacy unit names, tax labels and account names to the values ERPNext expects.
Check the setting: Confirm whether server_script_enabled is available on your deployment before planning any script-based step.
Keep transformations documented: Record every rule applied so auditors and finance can trace each loaded value to its source.
Verify after load: Compare counts and totals against the cleaned file, not the original export.

Ask your partner whether your hosting model permits Server Scripts, since the answer determines where transformation work can run.

Cleaning and deduplicating spreadsheets before the first import

Most of the migration effort from Excel happens before anything is imported. The spreadsheets that run a business were built by different people for different purposes, so the same customer may appear as "Acme Ltd", "ACME Limited" and "Acme (Accounts)", and the same item may carry three codes. Each duplicate you leave in place becomes a second party or item in ERPNext, and every invoice, payment and stock movement then has to be split or merged later. Before the first Data Import run, work through each master sheet for customers, suppliers and items and remove duplicates by agreed rules: matching tax IDs or bank details for parties, and matching description, unit and supplier part number for items. Standardize names, codes, units of measure (for example, one spelling of "each" and "pcs" rather than both), currencies and tax templates, and split any merged cells so that every row carries a complete record. Where a single item is referenced by several names across quotes, invoices and stock counts, pick one canonical item and record the alternates as aliases in your mapping file rather than keeping them as separate items.

Each master needs one accountable owner, usually someone in finance for parties and accounts and someone in operations for items and warehouses. That person approves every change to the cleaned sheet and signs off the final version before import. Keep an ID mapping table alongside the cleaned files with at least the old code, the source system or file, the new ERPNext name and the owner who approved it. Transactional history, such as open invoices, open purchase orders or opening stock, refers to parties and items by their old codes, so this mapping is what lets those documents link to the right ERPNext records when you load them later. Ask your implementation partner and your finance lead to agree on how the mapping will be versioned, since a correction to one customer name can affect several downstream files. Confirm with the ERPNext documentation for your version how the Data Import tool treats the name field for each DocType, because the name you choose at this stage becomes the identifier that other records reference.

What usually goes wrong in spreadsheet-to-ERPNext loads

Most failed spreadsheet loads trace back to a few predictable mistakes: records loaded in the wrong order, messy source data, and balances keyed in more than once. Each risk below has a prevention step you can check before the full load begins.

Transactions loaded before masters

Invoices, stock entries and journal rows reference parties, items, warehouses and accounts that do not exist yet, so the import fails or links to the wrong record. Load groups and parent records first, then company-independent masters, then parties, items and warehouses, and only then open transactions. Confirm the order against your own sheet tabs before any import runs.

Duplicate parties from inconsistent names

The same customer appears as "Acme Ltd", "ACME Limited" and "Acme, Ltd." across sheets, and each variant becomes a separate party with its own receivable history. Before import, sort each master by tax ID or bank details rather than by name alone, merge obvious duplicates, and assign one unique code per party. Check the party count in ERPNext against the deduplicated list.

Lost formula logic

Spreadsheet totals, unit conversions and margin calculations often live in formulas that the import file drops, leaving only pasted values. Decide which figures ERPNext should calculate (line totals, taxes, stock valuation) and import only the inputs. Compare a sample of totals from the old workbook with the values ERPNext computes for the same records.

Currency and tax mismatches

A sheet that mixes currencies or stores tax as a rounded percentage can post balances that do not match the source ledger. Confirm the company currency, the tax templates and the decimal precision before import, and convert foreign amounts with a documented exchange rate. Test one invoice per currency and tax rate in a non-production site first.

Opening balances keyed in twice

Teams often enter opening stock or receivables manually in ERPNext after already importing them from a sheet, which doubles the balance. Assign one owner for each opening figure, record which method loaded it, and keep the closing sheet as the single source. Reconcile the ERPNext totals to that sheet before the cutover date.

Oversized batches timing out

Very large files can stall, time out or leave half-imported records that are hard to clean up. The Data Import documentation advises importing only a few thousand records at a time, so split large tabs into batches and run a test batch of two to five representative records first. Keep each batch's row count and any errors so a failed batch can be rerun without duplicates.

What drives the effort and cost of a spreadsheet migration

This table compares the factors that change the effort of moving spreadsheets into ERPNext, and the cost components they affect. Read each row as a question to answer before you ask for a quote, because the same spreadsheet can take very different effort depending on the data behind it. No figures are given here, so use the rows to scope the work in writing.

Driver	Why it changes effort or cost	How to keep it down or what to confirm
Number of sheets and records	Each master and transaction sheet needs its own mapping, template and test batch, so effort grows with sheet count and row volume.	Keep only sheets that feed live processes. Confirm the record count per sheet in the written scope.
Data quality	Duplicate parties, inconsistent item codes and blank required fields often take more time than the import itself.	Run deduplication and validation before mapping starts. Ask who cleans the data and who approves exceptions.
Number of companies and currencies	Each company needs its own accounts, and each currency needs exchange rate and account setup before balances can load.	List companies, currencies and intercompany flows in the scope so opening balances can be planned per company.
Stock, serial and batch tracking	Items with serial or batch numbers need those identifiers mapped and tied to warehouse balances, which adds reconciliation work.	Confirm which items are tracked and whether historical serial or batch detail must carry over.
Custom fields required	Fields that ERPNext does not hold by default need a customization decision, testing and documentation for later users.	Limit custom fields to those the business needs for reporting or approvals. Ask for them to be listed before build.
Approval rules and workflows	Approval paths on imported documents must be configured and tested so migrated data behaves like live data.	Document the approval matrix first. Ask whether approvals apply to migrated records or only to new ones.
Users to train	Each role needs training on the new screens, permissions and data entry rules, and training effort scales with headcount.	Group users by role. Ask for training to be priced per role group in the quote.
Historical transactions kept	Carrying years of invoices and payments adds volume, linking logic and validation, while opening balances alone are lighter.	Decide the history cut-off early. Ask the partner to separate history from opening balances in the quote.
One-time costs	Preparation, mapping, test batches, reconciliation and training are paid once, usually as part of the fixed scope.	Ask each item to be shown as a separate line with its deliverable and acceptance test.
Recurring costs	Data hygiene after go-live, support, upgrades and any retained service continue after the migration ends.	Ask whether support is a separate retainer, and what the vendor and partner each cover.

Questions buyers ask before moving from Excel to ERPNext

How much does an Excel to ERPNext migration cost?

No single price applies, because cost follows the written scope. The main components are the time spent cleaning and deduplicating sheets, mapping columns to ERPNext fields, building and testing import batches, reconciling opening balances and training users. Costs recur mainly if you need ongoing support or later data loads. Ask any partner for a quote that lists each sheet, the record counts per master, which history is in scope and who signs off each stage. ERPNext itself is free to self-host under GPL-3.0, according to the ERPNext pricing page, so your budget is driven by people, hosting and services rather than licence fees.

How long does moving from spreadsheets to ERPNext take?

Duration depends on how many sheets exist, how clean they are, how many companies, warehouses and currencies you run, and how quickly sheet owners answer questions. Most of the time goes to cleaning data and agreeing the import order, not to the import itself. The ERPNext guidance on importing accounting masters asks you to test two to five representative records before loading anything, so plan at least one test cycle per master type. Ask for a timeline that names the test batches, the sign-off points and the cutover date, rather than a single overall estimate.

What must our team provide for the migration?

Three roles matter most. Sheet owners must explain what each spreadsheet means, which rows are current and which columns are formulas or notes. A finance approver must confirm the chart of accounts, opening balances and the cutover position. A decision-maker must choose how much history to bring in, for example only open invoices and balances, or several years of transactions. Your team also needs access to the source files and a named person who can answer questions during test batches. Without these inputs, the import order and record counts cannot be fixed, so ask any partner to list them in the statement of work.

Can our finance staff migrate from Excel to ERPNext without a partner?

Yes, many organizations do this in-house, provided someone understands both the spreadsheets and ERPNext's data model. ERPNext's Data Import tool loads CSV or Excel files using downloadable templates, supports child table rows, and the documentation advises importing only a few thousand records at a time. Staff should download the template rather than build one from memory, import groups and parents before dependent masters, and reconcile totals after each batch. A partner adds value when data quality is poor, when multiple companies or currencies are involved, or when the team lacks time to run test cycles. Set a clear test plan either way.

Can ERPNext import all of our historical transactions from spreadsheets?

ERPNext can import records that its Data Import tool supports, but importing every historical transaction is usually neither necessary nor practical. Masters such as parties, items, warehouses and accounts load through templates, and opening balances are typically entered as opening entries at cutover. Full transaction history from years of spreadsheets raises volume, validation and reconciliation effort, and the documentation's advice to import a few thousand records at a time makes large histories slow to load. Decide which history matters for audit, tax and operations, then confirm with your finance and compliance owners before any import begins.

Does choosing cloud or self-hosted ERPNext change the import work?

The import steps stay the same, because the Data Import tool and the import order are part of ERPNext itself. What changes is where the work runs and who operates it. ERPNext can be installed on Frappe Cloud, with Docker Compose, or manually with the bench command line tool, according to the ERPNext README. On Frappe Cloud, shared public benches do not allow Server Scripts, which can matter if your import relies on custom logic. Self-hosting also means you own backups before each test batch and the full load. Confirm the hosting model and any scripting needs early, because they affect test environments and rollback plans.

Which accounting masters should be imported first into ERPNext?

Start with groups and parent records, then company-independent masters, then company-specific masters, parties, items and warehouses. ERPNext's guidance on importing accounting masters sets this order, which prevents child records from failing because their parent does not yet exist. Keep each sheet clean before it enters the process, with unique codes for parties and items and no merged cells. Validate each step against the source totals, so that a later error does not hide an earlier one. The ERPNext import accounting masters guide lists the recommended sequence in full.

How DeployOpen scopes and delivers an Excel to ERPNext migration

DeployOpen plans and implements ERPNext inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network, and it agrees the migration scope in writing before any spreadsheet is touched. The written scope names the sheets in play, the masters and opening balances each one feeds, the ERPNext site and Frappe version it targets, and who signs off each stage. Most engagements are fixed-scope, so the deliverables and timelines are settled up front and the quote follows from that document. Ask for the scope to list which spreadsheets are retired, which are kept as read-only history, and which data is deliberately left out.

Delivery then follows the sequence in the topic: DeployOpen prepares cleaned Data Import templates for groups, parties, items and warehouses, downloaded from the ERPNext instance rather than rebuilt from memory, and runs small test batches with your finance and operations staff before any full load. Each batch is checked against the source sheet, and the findings feed back into the cleaning rules. Your team should confirm who owns the decisions on duplicate parties and item codes, since those choices are hard to undo once transactions reference them. DeployOpen also supports the parallel run and the cutover, and it prepares the documentation and evidence that your auditors may ask for. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do that work.

After go-live, ongoing support is available as a retainer, covering upgrades, fixes and continued testing of the ERPNext configuration. Retainer scope, response expectations and any recurring fees should be written into the agreement alongside the migration scope, so that the one-time migration effort and the recurring support cost are visible separately in the quote. DeployOpen is not an official partner, reseller or certified provider of ERPNext or Frappe, and this page makes no claims about client results. Ask any provider, including DeployOpen, for named references you can verify and for the written scope that the quote is based on.

Migrate from Excel spreadsheets to ERPNext