What ERPNext customization involves
Customization fits ERPNext to the way your company runs accounting, stock and production. Most of it is done in two places. The first is configuration in the user interface: custom fields, custom DocTypes, print formats, workflows, and client scripts that change how a form behaves in the browser. The second is code, usually Server Scripts or a custom Frappe app, which runs logic on the server during document events or through API endpoints. Changes in the second group are the ones that need version control, testing and an upgrade plan.
Four triggers usually start the work. A business process that the standard setup does not model, such as a consignment stock flow or a multi-step production approval. A print layout that a customer, tax authority or auditor requires. An approval step that must block a document until a named role signs off. A report that finance needs and that the standard reports cannot produce. Before you start, write down which trigger applies and which document, role or company it touches, because that decides whether the change stays in configuration or moves to code.
In-house or partner is a question of risk, not only skill. A trained administrator can often make small UI changes such as a new field, a label or a print format adjustment. Changes that touch Server Scripts, custom apps, upgrades or integrations are usually scoped to a partner. Server Scripts are disabled by default from version 15 and must be enabled, and Frappe Cloud public shared benches do not allow them, so confirm your hosting model first. Ask your internal team which custom changes they can maintain after go-live.
What the work includes
ERPNext customization ranges from a single configured field to a versioned Frappe app. Each card below names what we deliver and the evidence you receive, and every engagement closes with a written list of changes, test records and handover notes.
Custom fields and DocTypes
Custom fields add data points to existing forms, while new DocTypes model records ERPNext does not cover, such as inspection logs or contract terms. You receive the field and DocType definitions with their options, permissions and link relationships, plus a test record for each. Check which reports, print formats and imports depend on each field before you add it.
Customize Form changes
Customize Form adjusts standard DocTypes without new code: field order, mandatory flags, read-only rules, default values and visibility by role. You receive a list of each property changed on each DocType, with the before and after values and a screenshot-based check per role. Confirm that changes to standard forms survive the upgrade path you plan to follow.
Print formats
Print formats control how invoices, delivery notes, purchase orders and other documents look when printed or emailed. You receive templates for the documents you name, tested against sample records with your tax, currency and address data. Check the paper size, letterhead and language settings with your accounting team before sign-off.
Workflows and approval states
Workflows define document states, transitions and the roles allowed to move a document between them, such as purchase approval above a set amount. You receive the workflow diagram, the role matrix and test runs for approve, reject and cancel paths. Confirm the approval thresholds and escalation rules with the business owner, since they are a control, not just a convenience.
Client and server scripts
Client Scripts run JavaScript in the browser to react to form events, while Server Scripts run Python on document events or as API endpoints. You receive each script with its trigger, its owner and a documented test case. Server Scripts are disabled by default from version 15 onward and need the server_script_enabled setting, so confirm that your hosting setup allows them before design starts.
Reports
Reports cover standard report builder views, script reports and query reports built on your data. You receive each report with its filters, permission checks and a reconciliation against a known total from the source system. Check that report figures match the ledger, since reports read the same data but can apply different filters and date ranges.
Custom Frappe app packaging
When changes grow beyond UI settings, we package them into a custom Frappe app that lives in your repository and installs with bench. You receive the versioned app code, install and migrate hooks, a changelog and tests that run before each upgrade. Ask who owns the repository and the release process, because the app must be retested whenever ERPNext or Frappe changes.
What drives cost and duration
Each row names one factor that moves ERPNext customization effort, explains why it does so, and lists what the client can do to keep it under control.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Number of changed DocTypes and forms | Every new or altered DocType adds fields, permissions, list and form views, naming rules and testing. Changes to standard forms also need to be re-checked after every upgrade. | Agree the list of forms in writing before build starts. Prefer custom fields and standard print settings over new DocTypes where the data fits. |
| Process complexity (approvals, multi-company, multi-currency) | Approval chains, branching rules and exchange or intercompany logic multiply the paths each test must cover. Errors in these paths tend to show up only in month-end or cross-company transactions. | Write the approval matrix and currency rules as a decision table before design. Use ERPNext's standard workflow features where they cover the rule, and limit exceptions. |
| Reports and print formats | Each custom report needs its own query logic, filters, permission checks and output tests. Print formats need layout approval from finance or legal and must be re-verified with real documents. | Reuse standard reports and filters, and ask for one owner to sign off each report's columns and totals. Limit print formats to documents that legally or commercially need them. |
| Integrations that trigger custom logic | Scripts that run on document events or call external systems add failure modes, retry handling and credentials to manage. Each trigger needs tests for success, failure and duplicate calls. | List every event that should trigger logic and every external system involved. Confirm early whether Server Scripts are allowed in your environment, since they are disabled by default from version 15. |
| UI changes versus a custom Frappe app | Changes made in the UI are quick to start but are harder to version, review and move between environments. A custom app needs a repository, code review, packaging and an install step on every server. | Decide the packaging rule before build starts. Keep small field-level changes in the UI, and move logic, new DocTypes and anything reused across sites into a version-controlled custom app. |
| Number of environments and test cycles | Each environment (development, staging, production) needs the same changes applied and verified. Each test cycle repeats the scripts, reports and print checks, so effort grows with every round of fixes. | Ask for a clear environment plan and a written test scope per cycle. Freeze requirements for each release so retests cover only changed areas. |
| ERPNext version and upgrade path | Customizations depend on internal APIs and standard DOM or form behavior that can change between major versions. Custom apps and scripts must be checked against the target version before any upgrade. | Confirm the version you start on is supported, as listed on Frappe's supported versions page. Plan the upgrade path with the custom code in scope so compatibility checks are included in the build estimate. |
| Data volume affecting report and script testing | Large volumes of transactions make report queries, scripts and imports slower to test and can hide performance problems that appear only on realistic data. The Data Import documentation advises importing a few thousand records at a time. | Use a representative copy of production data in staging with agreed anonymization. Ask for the expected record counts for the heaviest reports and scripts so performance tests are scoped up front. |
Project phases and outputs
The sequence moves from agreed requirements to a tested, deployed and documented set of changes, with each phase closing on a named output.
Review requirements against current forms and reports
DeployOpen walks through the current process for each module in scope, with the people who run it, and compares it against the forms, print formats, reports and scripts already in use. The output is a signed-off requirements list that names the process owner for each item and the outcome each change must deliver.
Classify each change in an inventory
Each requirement becomes a line in a change inventory. The team classifies it as UI configuration (custom fields, property setters, workflows, print formats), a script (client or server script, after confirming whether server scripts are enabled in your environment), or a custom app, and records the reason for each choice. The client receives the inventory as a working document with the decisions recorded.
Design and prototype on a staging site
Changes that touch forms, workflows, reports or print formats are built first on a staging site that mirrors your ERPNext version and installed apps. You review screens and printed documents with the process owner. The output is an approved prototype and a list of accepted design decisions, so the build starts from settled choices and fewer open questions.
Build and test on a development bench
Approved items are built on a development bench, with custom apps kept in version control. Each DocType, script and report is checked with unit-style tests where the app structure allows them, covering field validations, permissions, workflow transitions and calculated values. The output is a build with a test record that lists what passed and what remains open.
Run user acceptance testing with your records
Client users test the build with copies of their own records, such as open sales orders, purchase invoices and stock entries, on a staging site refreshed from recent data. Testers follow scenarios written from the requirements list, and personal data is masked where your test policy requires it. The output is an acceptance log with each defect logged, fixed and retested, and any accepted exceptions recorded by the process owner.
Deploy through the agreed release path
Approved changes reach production through the release path agreed at the start, such as a tagged custom app version, a bench migrate run and a documented rollback plan. The team checks the changed screens and reports on the production site with a short smoke test. The output is a deployment record showing app versions, migration results and the rollback steps that were verified.
Hand over documentation and named owners
DeployOpen hands over the change inventory, configuration notes, script and app documentation, test records and an upgrade runbook. Each change is assigned a named owner on your side who approves future edits. The output is a handover pack and a signed owner register, which becomes the reference for the next upgrade or change request.
What usually goes wrong
Most ERPNext customization problems are not coding problems. They come from hosting choices made too late, changes that live only in production, and knowledge held by one person. The cards below name the risks and the check that prevents each one.
Script-dependent designs on the wrong hosting
Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all. If a design depends on Server Scripts, confirm the hosting type and script settings before any build starts, so the choice of platform does not force a redesign later.
Changes made directly in production
Custom fields, scripts and print formats edited in the live UI cannot be reproduced on a test site or rebuilt after a failure. Keep customizations in a versioned custom app and treat production as a deployment target only. Ask any partner or internal team how each change is captured and restored.
Custom apps that break on major upgrades
Scripts and apps written against one major version can fail during bench migrate on the next. Test every custom app against the target major version on a staging copy of production data before the upgrade window. Plan this check early, because it determines whether the upgrade is a routine task or a project.
Conflicts after minor releases
ERPNext ships frequent minor releases on both supported major versions, and a field name, hook or standard behavior that a customization relies on can change. Run each minor release through staging with your custom fields and scripts enabled, and record which customizations were tested against which release.
Undocumented changes held by one administrator
When a single administrator understands why a custom field, workflow or script exists, the system stalls the day that person leaves or is unavailable. Record each customization with its business purpose, owner, dependent documents and reports. Assign a named backup owner for every custom app and script.
Reports that slow down on large tables
Report logic written as unindexed queries or loops over full document tables performs acceptably on test data and poorly on years of transactions. Test report runtimes on a copy of production volumes, and review queries with the team that owns the accounting or stock data before users depend on them.
In-house or partner: who does what
This table shows the usual owner of each ERPNext customization task and the skills it needs, so you can see which parts your team can carry and which to hand to a partner.
| Task | Usual owner and skills needed | What to confirm before deciding |
|---|---|---|
| Process mapping | Usually a business analyst with ERPNext functional knowledge, working with finance, stock and production leads who own the rules. Accounting knowledge is needed to judge how posting and approvals should behave. | Who signs off each process map, and whether the team can document exceptions for accounts, stock and production. |
| UI configuration (custom fields, print formats, workflow states) | Usually an in-house ERPNext administrator with functional knowledge. Print formats need Jinja and HTML familiarity, and workflow states need an understanding of role permissions. | Whether the admin team has capacity to maintain these changes across upgrades and who approves changes to accounting documents. |
| Client Script development | Usually a developer with JavaScript skills for client-side forms, plus ERPNext functional knowledge to decide what each form should do. | Who reviews form behavior changes and how they are tested in a staging site before release. |
| Server Script development | Usually a developer with Python and the Frappe framework. Server Scripts are disabled by default from version 15, so the team must also confirm the setting is enabled on its own server. | Whether the target environment allows Server Scripts, since Frappe Cloud public shared benches do not allow them. |
| Custom Frappe app development and Git workflow | Usually a developer or partner with Python, the Frappe framework, Git and Linux and bench operations. This work needs a repository, code review and a build pipeline. | Who owns the repository, release tags and deployment steps after the project ends. |
| Report building | Usually a finance or operations analyst with ERPNext functional knowledge for query and report design, with a developer for complex Python reports. Accounting knowledge is needed for report sign-off. | Which named accountant signs off financial reports and how report figures are reconciled to ledgers. |
| Testing and acceptance | Usually shared between business users who run scenarios and a tester who records results. Accounting knowledge is needed to check postings, taxes and balances. | Written acceptance criteria per process, and who has authority to accept the release. |
| Upgrade testing for custom code | Usually a developer with Python, the Frappe framework and bench operations, running migrations on a staging copy. Developers must also review custom app compatibility with the target version. | Which staging environment is used, who runs bench migrate there, and who records the results before production. |
| Release management | Usually a Linux and bench operator who deploys tagged code and runs database migrations, with a functional owner approving the release. Rollback steps must be documented before go-live. | Who holds deployment rights, the backup and rollback plan, and the change approval process. |
How the work differs by starting point
A new site starts with stock ERPNext, so the work is configuration first and code only where the standard tools cannot meet a process. Scope usually follows the process map for accounting, stock and production.
- Scope: company, item and workflow setup, plus custom fields, print formats and reports built in the UI before any app is written.
- Client provides: named process owners, sample documents, approval rules and the reports people need each week.
- Risks: logic added early in scripts that later has to move into a custom app, and unclear ownership of change approval.
- Decision point: whether Server Scripts are needed, which depends on the hosting model you choose.
- Confirm: the version you will start on and its support window on the supported versions page.
Work starts with discovery, not build. Undocumented changes often sit in custom fields, scripts, print formats and occasional direct database edits, so the first task is finding them all.
- Scope: inventory every customization, including DocTypes, client and server scripts, workflows and reports, then classify each as keep, move to a custom app or retire.
- Client provides: admin access to a copy of production, staff who made past changes, and any change logs or tickets.
- Risks: database edits and scripts that never appear in the UI, and changes that break on the next bench update.
- Version control: agreed changes move into a Git-tracked custom app so deployments are repeatable.
- Ask: how the inventory will be checked against the live site before anything is moved.
On Frappe Cloud public shared benches, Server Scripts are not available, so any logic that depends on them must be redesigned or hosted elsewhere before the design is final.
- Scope: review every Server Script and API endpoint, then decide between client-side logic, a custom app on a plan that permits it, or a dedicated server.
- Client provides: a list of current scripts with their triggers, and the hosting plan each site runs on.
- Risks: a go-live that depends on a script the shared bench cannot run, and plan changes that alter the design after build.
- Support: Frappe warranty coverage depends on running a listed version with a matching Frappe Cloud support plan, so confirm the plan first.
- Confirm: with Frappe Cloud, which features and apps your plan allows, since this constraint shapes the whole design.
On a self-hosted bench or frappe_docker deployment, custom apps can be built into images or bench installs, which moves customization into your release pipeline.
- Scope: a Git repository for each custom app, a build definition for frappe_docker images or bench installs, and a repeatable deploy process.
- Client provides: the container or server platform, Git hosting, secrets handling and a staging environment that mirrors production.
- Risks: images built from unpinned app versions, Server Scripts enabled without review, and the single-file demo setup used in production, which is meant only for short-lived evaluation.
- Production setup: the full set of services, including workers, scheduler and Socket.io, must be planned, not just the web container.
- Ask: how images are rebuilt after each minor release and who signs off on each rebuild.
Customizations built on version 15 must be retested on version 16 before cutover, because custom apps, scripts and print formats depend on core behavior that can change between major versions.
- Scope: test every custom app and script on a staging copy, run bench migrate, then check reports, print formats and integrations.
- Client provides: a recent production copy for staging, test cases for key transactions and named sign-off owners.
- Risks: custom apps that do not run on version 16, data checks failing after migrate, and no tested rollback path.
- Timing: version 15 support is planned until the end of 2027, so set the migration window with that date in view.
- Confirm: whether each third-party app has a version 16 release, and the rollback steps tied to the backup taken before migrate.
What you need to provide
The fastest customization projects start with inputs the client already holds. Each item below removes a source of rework, and each one has a clear cost when it is missing. Ask for all of them in writing before the scope is fixed, because most delays trace back to a missing answer rather than to the build itself.
Name one business owner for every process that will change, such as sales order approval, purchase receipts or job card completion. This person decides field labels, validation rules and workflow states, and signs off each change. Without them, developers guess at business rules, and changes are reopened after users test them. Also supply a staging site with a copy of recent production data, so custom fields, scripts and print formats are tested against real records. A staging copy that is months old hides problems that appear only with current data.
Provide a current inventory of existing customizations: custom fields, Client Scripts and Server Scripts, print formats, workflows, custom reports and any custom app already installed. Confirm whether Server Scripts are enabled on the hosting model in use. On Frappe Cloud public shared benches they are not available, and on self-hosted installs they are disabled by default from version 15 and need the server_script_enabled setting. If the hosting model does not allow them, the design must use a custom app instead, which changes effort and maintenance.
Grant Git repository access for custom apps, and name who approves merges. Also supply sample documents, such as a real sales invoice, purchase order and printed quotation, with the layout and fields users expect. Define sign-off criteria in advance: which test cases must pass, who runs user acceptance, and who decides on handover. Finally, decide who maintains the changes after go-live, whether internal developers or a partner under a retainer. Changes that nobody owns tend to break at the next minor release, and a decision made now avoids that gap.
Frequently asked questions
Can our own team customize ERPNext without a partner?
Yes, many teams do small changes themselves. Custom fields, print formats, and simple client scripts can be built through the ERPNext interface by a user with the right permissions. The question is less about capability and more about who will own the change after go-live. Changes that touch accounting logic, stock valuation, or several DocTypes at once need someone who can test them against upgrades, review them, and document them. Ask your team to list the changes they expect, then decide which ones they can maintain for the next major version.
When should customizations be packaged as a custom app instead of UI changes?
Package changes in a custom Frappe app when they contain Python code, multiple DocTypes, reusable logic, or integrations that must move cleanly between environments. UI changes such as custom fields and print formats are stored in the site database, so they are harder to version, review, and deploy consistently. A custom app lives in source control, can be tested in staging, and is deployed with the same bench commands each time. Teams often start in the UI for speed, then move stable logic into an app before the first major upgrade.
Are Server Scripts available on our ERPNext hosting?
It depends on where ERPNext runs. From version 15, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, according to the Frappe Framework documentation. Frappe Cloud public shared benches do not allow them. On self-hosted or dedicated environments you control the setting, but enabling it means reviewing who can write scripts and how they are tested. Confirm the hosting type and the setting before designing any script-based change, because the answer changes the build approach.
How do customizations affect ERPNext upgrades and version support?
Customizations are the main source of upgrade effort. Frappe's supported versions page lists version 15 as planned for support until the end of 2027 and version 16 until the end of 2029, and both receive frequent minor releases. Each major upgrade needs custom apps, scripts, and custom fields checked against the new version, followed by a staging run of bench migrate. Keep customizations small and documented so the upgrade test covers them completely. Ask any partner how they will version and regression-test your custom code.
What drives the cost and timeline of an ERPNext customization?
The main drivers are the number of processes changed, whether changes are UI-only or require custom apps, how many integrations are involved, and how much testing your business users need. Print formats and custom fields are usually quicker than workflows that span stock, accounting, and production. Approvals, data quality, and the number of stakeholders also affect the schedule. Ask for a quote built from a written scope with each customization listed separately, including design, build, testing, documentation, and handover. DeployOpen does not publish prices; quotes follow from the agreed scope.
What does the work need from our staff during a customization project?
Your staff must provide decisions and access, not just requirements. Expect to name a process owner for each area, such as accounting, stock, or sales, who can approve how a workflow should behave. You will need a non-production environment for testing, accounts with the right roles, and sample data that reflects real transactions. An internal technical contact should review code, approve deployments, and learn how to run bench commands. Plan time for business users to test in staging, since most rework comes from unclear acceptance criteria.
How do we keep customizations working after the partner hands over?
Handover should include source code in your own repository, a written list of every custom field, script, print format, and app with its purpose, and a runbook for deploying and rolling back changes. Your team should practice a deployment in staging and run one restore test before go-live. Confirm who will handle upgrades and bug fixes, whether internal staff or a support retainer. DeployOpen offers ongoing support and upgrades as retainers, which can be scoped separately from the build.
How DeployOpen delivers ERPNext customization
DeployOpen scopes ERPNext customization against your written process map, then builds changes as configuration or packaged code, tests them on a staging copy, and hands over documentation and a supported runbook. Work is delivered inside infrastructure you control, whether that is your own servers or a Frappe Cloud account you hold.
How we scope
- Engagements are fixed-scope, with customizations, deliverables and timelines agreed in writing before build starts.
- The written scope lists each DocType, field, print format, script, report and workflow touched, with the business rule it supports.
- We confirm which changes stay as UI configuration and which need a custom Frappe app, so upgrade impact is known in advance.
How we build
- Custom fields, workflows and print formats are built in a development bench and kept under version control where practical.
- Server Scripts are used only if the target environment allows them, since Frappe Cloud public shared benches do not.
- Each change is tested on a staging copy with realistic data, including role and user permission checks before release.
How we hand over
- You receive the source for any custom app, with install, update and migrate steps written for your own team.
- Documentation covers each customization, its owner, its permissions and the test cases used to verify it.
- Knowledge transfer sessions walk your administrators through configuration changes they will own after go-live.
How we support
- Ongoing support, upgrades and testing of custom apps are available as a retainer, scoped separately from the build.
- Before each ERPNext minor or major upgrade, customizations are retested on staging so breakage is found early.
- Ask any provider to confirm how custom apps are versioned against the ERPNext release you run, and who fixes breaks.
