Standard, configuration or custom: the three words that decide your ERP budget
Every line of every requirements document we write ends in one of three words: standard, configuration or custom. Clients sometimes ask why we insist on it, since the marking adds a column and a little argument to every workshop. The answer is that those three words decide most of the budget, most of the risk and most of what your next upgrade will cost. A requirements document that leaves them out is a list of wishes, and a quote built on it cannot be compared with any other.
What the three words mean
| Marking | What it means | Who does the work | What it costs later |
|---|---|---|---|
| Standard | ERPNext does it as shipped, once masters and settings are in place | Consultant sets up, tests and trains | Almost nothing; upgrades carry it forward |
| Configuration | No code, but the product has to be set up for you: fields, workflows, formats, permissions | Consultant, documented | Little; it needs documenting and checking after upgrades |
| Custom | Code: something ERPNext does not do, built for you | Engineer, reviewed by a second engineer | Testing and maintenance at every upgrade, for as long as it exists |
Standard
Sales order to delivery note to sales invoice. Purchase order to receipt to purchase invoice to payment. The stock ledger, batch and serial tracking, the general ledger, bank reconciliation, GST invoices and e-invoicing through India Compliance. These are things ERPNext does out of the box. The work is real (setting up masters, choosing the right settings, testing with your transactions, training), but it is bounded and it carries forward cleanly to the next version.
Configuration
Things the product does without code once someone sets them up: a custom field on the item master, an approval workflow with conditions on value, a naming series per branch, a print format for your invoice layout, role permissions down to the field, a notification when a document waits too long, a report built with the report builder. Configuration lives in the database rather than in code, so it needs to be written down and, where it matters, exported so it can be rebuilt on a fresh site. It is cheap to change and rarely breaks at upgrade, but it is not free.
Custom
Anything that needs code: a new document type, server-side logic, a custom page or portal, an integration, a calculation ERPNext does not make. In our projects all of it goes into a separate Frappe app in your own repository, never into ERPNext's core code. Custom work has to be designed, built, reviewed by a second engineer, tested, documented, and then tested again whenever ERPNext moves to a new version. That last cost is the one people forget. We explain why we keep it separate in Why we build custom work as a separate Frappe app.
The grey zones, and how we mark them
Some things look like configuration and are really code. We mark them as custom, because that is what they cost to maintain.
- Client and server scripts typed into the browser. Frappe lets you write scripts in the desk without deploying an app. They are code. They break at upgrades like code, and they are harder to review because they are not in version control. We move them into the app.
- Print formats with logic. A layout with your logo and columns is configuration. A print format that calculates, loops over related documents or changes by customer is code in a template, and we mark it custom.
- Reports. A report built in the report builder is configuration. A script or query report is custom.
- "Small" validations. "Stop the user saving if the batch is expired" sounds like a setting. If no setting does it, it is a few lines of code, and it is custom.
How a line is written
Each line has four parts: the current process, the expected process, how the system handles it, and the marking. Two lines side by side show the difference. The first is a typical line, not taken from a particular client. The second is a requirement from the NIDO Group implementation, a machinery maker that kept separate mechanical and electrical BOMs.
| Part | A typical approval line | A NIDO Group manufacturing line |
|---|---|---|
| Current process | Purchase orders above a certain value are approved on WhatsApp by the plant head; nobody can find who approved what | Separate mechanical and electrical BOMs, and no clear view of raw material requirements |
| Expected process | Orders above a value set by finance need the plant head's approval, above a second value the CFO's as well, recorded on the order | One BOM per machine with revisions managed during production, and a raw material planning table for iron, sheet and wire |
| How the system handles it | An ERPNext workflow on the purchase order, with conditions on the order total and a role for each approver | A unified BOM with revision management and a planning table, built in a separate app |
| Marking | Configuration | Custom |
Both are legitimate. Only one of them will need attention at every upgrade.
Why the marking decides the budget
Standard and configuration lines are bounded. An experienced consultant knows roughly what it takes to set up a workflow or a print format, and the risk of surprise is low. Custom lines are open-ended. Each one carries design decisions, edge cases, tests and a maintenance tail. In our experience the number and size of the custom lines is the best single predictor of what an implementation will cost and how long it will take, and the best predictor of what it will cost to keep running.
The marking also changes the conversation in the workshops. When a function head sees "custom" next to a request, the natural next question is whether it is worth it. Often it is. Sometimes the process exists only because the old system could not do something better, and the standard way is fine once people see it.
Four questions for every custom line
- Is there a configuration answer we missed? ERPNext's settings run deep. A second look, sometimes by a second consultant, finds one more often than you would expect.
- Is the process worth keeping? A custom report that rebuilds a spreadsheet the finance team has used for ten years may be replaced by a standard report they will like better.
- Can it wait? Phase two is a real option. Going live on the standard flow and adding the custom piece once people use the system usually produces a better specification.
- Has someone already built it? An existing app, ours or from the Frappe community, may cover it, with its own maintenance already paid for.
Keeping a custom line is fine. Keeping it without asking these questions is how budgets drift.
Who signs, and what the signature means
In our method the requirements documents are written at the second waypoint, Chart. Function heads review them, the CXO approves them, and our implementation lead confirms them. That is Gate 1, the blueprint sign-off, and nothing is built before it. From then on Bizmap is accountable for what is in the document and nothing that is not. Anything new is a change request: explained, priced, approved before work starts, and marked standard, configuration or custom like everything else.
The signature protects both sides. You know exactly what you are getting and what it will cost. We know exactly what we have promised. And because the document is yours, you can take it to another partner and ask them to quote against the same lines, which is the fairest comparison there is. We cover the wider set of cost drivers in What drives the cost of an ERPNext implementation.
What to ask a partner whose document does not mark lines
- Which of these requirements do you expect to need code?
- Where will that code live, and who owns the repository?
- Which of these lines did you assume the standard product covers, and did you check?
- How will you handle a requirement you marked standard that turns out to need code?
If the answers are vague, the gap between your expectations and their quote will be filled later, at your expense.
If this is your situation
If you have a requirements list with no marking, or a quote you cannot compare with another, we can help you sort it. Our ERPNext implementation service starts with exactly this document, and if the custom lines are already built and nobody understands them, ERPNext rescue starts with an audit that marks what you have. Talk to an engineer about the lines you are unsure of.
