ERPNext Customisation: Configure, Script or Build a Custom App?

Frappe gives ERPNext one of the most capable sets of customisation tools of any ERP. Almost anything can be changed, much of it without code. The challenge is choosing the right layer for each change, so the system stays understandable and upgradeable.

Here is the ladder we use, from lightest to heaviest. Climb only as high as you need to.

1. Settings

Before customising anything, check the settings DocTypes: Selling Settings, Buying Settings, Stock Settings, Accounts Settings, Manufacturing Settings and others. Many "we need a customisation" requests turn out to be a checkbox — allowing negative stock, making a field mandatory on submission, or changing how items are named.

2. Customize Form and custom fields

Customize Form changes how a standard DocType behaves without touching its code: labels, mandatory and read-only flags, default values, field order and section layout. Changes are stored as property setters.

Custom fields add new fields to standard DocTypes — a customer's credit rating, a vehicle number on delivery notes, an internal reference on purchase orders. They behave like native fields in forms, lists, reports and the API.

Both are upgrade-safe. Keep a list of what you added and why.

3. Workflows, notifications and assignment rules

• Workflows add approval states and role-based transitions — for example, purchase orders above a threshold need a manager's approval before submission.
• Notifications send email or system alerts on events, values or dates.
• Assignment rules route documents to the right person automatically.

These replace a surprising amount of custom code.

4. Print formats

Invoices, quotations and delivery notes can be designed with the drag-and-drop Print Format Builder or written in Jinja HTML for full control. Always create a new format rather than editing a standard one, so upgrades do not overwrite your work. Pair print formats with Letter Heads for branding.

5. Reports

The Report Builder saves filtered, grouped list views. Query Reports use SQL for joined data. Script Reports use Python for complex logic. Dashboards and number cards surface the figures managers check daily.

6. Client and server scripts

Client scripts run JavaScript in the browser: setting values when a field changes, filtering link fields, showing warnings.

Server scripts run restricted Python on the server: validations on save, scheduled jobs, simple API endpoints.

They are powerful and convenient, and that is the risk. Scripts typed into the browser have no version history, no code review and no tests. A system with dozens of them becomes hard to debug and risky to upgrade. Use scripts for small, low-risk rules, keep them few, name them clearly, and export them to Git.

7. Custom Frappe apps

When logic is complex, performance-sensitive, integration-heavy or business-critical, it belongs in a custom app: a Python and JavaScript package installed alongside ERPNext.

A custom app can:

• Define new DocTypes with their own logic
• Hook into document events on standard DocTypes through hooks.py
• Override standard classes in a controlled way
• Expose whitelisted API methods
• Run background and scheduled jobs
• Ship customisations — custom fields, property setters, print formats, workflows, roles — as fixtures

Fixtures are important: they let you rebuild a site's customisations from Git rather than from memory. We recommend every ERPNext implementation has a custom app for this reason, even if it contains little code.

The one rule: never modify ERPNext or Frappe core code. Changes to core files are overwritten on update and make upgrades a guessing game.

A quick decision guide

Cleaning up

If your system already has years of undocumented customisation, the fix is an inventory: list every custom field, property setter, script and print format, decide what stays, and move what remains into a custom app. Our ERPNext customisation services and ERPNext development services cover both new work and clean-ups.