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
Bulk import and update, without a developer on standby. Every ERP has a moment where someone needs to load four thousand items, revise a price list, or correct a field across a year of documents. If that requires a support ticket every time, the system slows the business down. ERPNext ships a proper import tool; the work is in making it safe to hand over.
ERPNext's Data Import creates and updates records through the same validation as the user interface, so a bad import fails loudly instead of quietly corrupting data.
Through the built-in Data Import tool. You download a template for the target document type, fill it in CSV or XLSX, and upload it. ERPNext validates every row against the same rules the screen enforces, links related records by name or ID, reports failures row by row, and can update existing records as well as create new ones.
The tool is reliable. The failures come from how it gets used, and all four of these are preventable with setup rather than supervision.
A file with a few malformed rows imports partially, and nobody notices which rows failed. The result is a dataset that looks complete and is not, which surfaces weeks later as a stock discrepancy nobody can trace.
Items reference item groups, customers reference territories, invoices reference both. Loading in the wrong order produces cascading failures that look like a broken tool rather than a sequencing mistake.
An import that partially failed gets re-run in full, creating duplicates of everything that succeeded the first time. Without a defined idempotency key, cleaning that up costs more than the original load.
The single most common cause of a bad day. A file that has never been tested against a copy goes straight into the live system, and the undo is manual.
The objective is that your finance or stores team can run a routine import on a Tuesday without asking anyone.
Rather than the generic export template, you get trimmed templates for the imports you actually repeat — new items, price list revisions, opening stock, employee master updates — with only the relevant columns.
A template with twelve columns instead of ninety removes most of the failure modes before anyone opens the file.
Data Import can update existing records as well as insert new ones. Which document types are allowed to be updated in bulk, and by whom, is set through permissions rather than convention.
Bulk update is powerful and correspondingly dangerous. Restricting it to specific roles and document types is the difference between a tool and a liability.
Common failures — missing mandatory fields, unknown item groups, invalid UOM, dates in the wrong format, GSTIN that fails checksum — are caught in the template itself rather than at row 3,400 of the upload log.
Where a check cannot live in the spreadsheet, it becomes a server-side validation so the rule holds no matter how the record is created.
Every repeatable import gets a defined key so a re-run updates rather than duplicates, plus a documented order of operations for imports with dependencies.
This is what makes a partially failed import a minor inconvenience instead of an incident.
A staging instance that mirrors production, so any unfamiliar import is proved against a copy before it touches live data.
Combined with a pre-import backup on the live instance, this makes the worst case a restore rather than a reconstruction.
Most ERPNext document types support import. These are the ones businesses actually use in bulk, and what to watch for on each.
| Spreadsheet contains | Creates or updates | Direction | Notes |
|---|---|---|---|
| Item list with UOM and HSN | Item + Item Defaults | Insert / Update | Item groups and UOMs must exist first |
| Customer or supplier list | Customer / Supplier + Contact + Address | Insert / Update | Contacts and addresses import as separate linked files |
| Price list rows | Item Price | Insert / Update | Most common repeat import; needs a key to avoid duplicates |
| Physical count sheet | Stock Reconciliation | Insert | Batch and serial columns required where tracking is on |
| Opening balances | Journal Entry | Insert | Debits and credits must balance or the whole file rejects |
| Employee master | Employee | Insert / Update | Reporting hierarchy imports after the employees exist |
| BOM lines | BOM + BOM Item | Insert | Child rows import with the parent in one structured file |
| Attendance or check-in log | Employee Checkin | Insert | Usually automated instead — see biometric attendance |
| Chart of accounts | Account | Insert | Parent accounts must precede children in the file |
The deliverable is capability in your team, not a dependency on ours.
We work out which bulk operations you actually perform more than once — price revisions, new item batches, seasonal employee loads — because those are the ones worth templating.
A template per use case, carrying only the columns that matter, with allowed values and formats built into the sheet so errors surface before upload.
Which roles may import, which document types may be updated in bulk, and which are insert-only. Restrictions are enforced by permissions, not by asking people to be careful.
Your team runs a real import on the staging instance, including a deliberately broken file, so they have seen what a failure looks like and know how to read the log.
A one-page runbook stating what must exist before what, where the templates live, and the re-run key for each. Short enough that people actually use it.
Timeline shown is indicative and assumes this runs alongside a wider implementation rather than as an isolated engagement.
Knowing the boundary is what stops people trying to solve the wrong problem with a spreadsheet.
Where a genuine recurring feed is needed rather than a manual import, that is API work and is scoped separately.
Yes. Data Import runs in insert or update mode, matching on the record ID or on a field you nominate. Update mode is restricted by role and by document type during setup, because bulk update is the operation with the most potential to cause damage.
Valid rows import and failed rows are listed with the reason against each, so you correct only the failures and re-upload. Where a repeatable import has a defined key, re-running the corrected file updates the successful rows rather than duplicating them.
Both. XLSX and CSV are supported, and templates can be downloaded in either format. Most teams prefer Excel because dropdown validation on the sheet catches errors before upload rather than after.
Your team, and that is the point of the handover. The templates, permissions and runbook exist so routine imports are a Tuesday task rather than a support ticket. We stay involved for unfamiliar document types or unusually large loads.
Batch and serial columns are included in the template, and the batch or serial records need to exist or be created as part of the same load. Sequencing matters here more than anywhere else, which is why it goes into the runbook explicitly.
There is a practical limit rather than a hard one, and very long files are better split into batches. If you are regularly importing tens of thousands of rows, the REST API is the more appropriate route and avoids the timeout risk entirely.
Import templates and runbooks are part of go-live handover, not an extra.
Explore →Backup, restore and help with unfamiliar or unusually large loads.
Explore →Server-side validation and API feeds where a manual import is the wrong tool.
Explore →A short call about what you load and update in bulk today, and how often it goes wrong.
Excel is a trademark of Microsoft Corporation. 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 Microsoft Corporation.
