ERPNext is open source. There is no per-user licence to buy, so almost all of the money in an implementation pays for time: consultants mapping your processes, engineers configuring and building, your own people in workshops and testing, and the support that follows go-live.
That is why we do not publish a price list, and why we are wary of anyone who quotes a number before they have seen how your business runs. Every proposal you receive is a sum of time spread across a small number of drivers. Once you can see the drivers, you can read any quote, ours included, and work out whether two of them describe the same project.
The seven things that set the cost
1. Modules, and how many companies
Each module is its own set of workshops, its own section of the requirements document, its own configuration, test scripts and training. Accounts, buying, selling and stock is one kind of project. Add manufacturing with BOMs and production planning, HR and payroll, projects or CRM and it becomes a larger one.
The number of companies matters as much as the number of modules. Two legal entities mean inter-company transactions, consolidated reporting and, in India, GST registrations and invoicing that must stay correct for each of them. Groups rarely go live in one step. For a single company with four to six modules we plan on three to six months, including a month of hypercare. Sonotech Medical Center, a hospital group, rolled out over about two years, in phases, without stopping the OPD.
2. Process fit: configuration or custom code
This is the largest single driver, and the one quotes are least honest about. ERPNext covers a great deal through configuration: approval workflows, custom fields, naming series, print formats, role permissions, notifications. None of that needs code.
Where your process does not fit, there are two choices. Change the process to match the product, or build what is missing. Custom code has to be designed, written, reviewed, tested and documented, and then checked again at every upgrade. It is not wrong to build: when NIDO Group needed a unified mechanical and electrical BOM with revision control during production, a raw material planning table and rental billing, those were real requirements of a machinery maker, and we built them as a separate app. But every custom line is a cost now and a cost later, and you should be able to see how many of them a quote assumes.
3. Data migration
What moves, how clean it is and who cleans it. We follow a cutover-date principle: migrate what you need to operate and report from day one (masters, opening balances, open documents), not years of history. History usually stays in the old system, read-only.
Migration costs rise with the number of source systems, with messy masters (the same item under five names, customers without GSTINs), with batch- or serial-tracked stock, and with any demand to bring transaction history across. They also rise when nobody owns cleansing. In our projects the client owns the cleansing, with validators we provide, and we run two dry runs reconciled on the trial balance, stock, open receivables and payables, and bank before the real cutover.
4. Integrations
An integration is a small project between two systems and often two vendors. Each one needs a defined direction, frequency, error handling, a way to reconcile the two sides, and someone who notices when it stops. GST e-invoicing and e-way bills through the India Compliance app are close to standard. A marketplace connector, a bank feed, a payment gateway, a legacy application or an institutional system such as SAP FI is work of its own, priced and tested on its own line.
5. Users, roles and sites
With no licence fee, adding a user does not add cost the way it does with proprietary ERPs. Roles do. Each role needs permissions set, test scenarios written and training delivered. Users spread across plants, stores or shifts need training where they work. We train by role, with a competency sign-off per role, and later waves of users get the same training time as the first, never a compressed version.
6. Change management, and your own time
The cost nobody puts in a quote is the time of your own people. Our plans assume function heads in workshops (two sessions of three hours per module), reviews of documents within three working days, a champion at around six hours a week during the build, and a user acceptance team available for two test cycles of about two days each. When those people are not available, the project waits, and a waiting team still costs money. A named sponsor who attends steering meetings is cheaper than any amount of rework.
7. Hosting and support after go-live
Frappe Cloud or your own server, backups, monitoring, upgrades and an annual maintenance contract. These costs recur, so compare them over several years rather than at signature. Some choices add infrastructure work: IIT Bombay's ESTEM platform runs entirely inside the institute's own network, which is a different job from a managed cloud site.
Why quotes for the same scope differ so widely
Two partners can read the same requirements and return numbers that look unrelated. Usually neither is lying. They are pricing different projects.
- Different assumptions about fit. One quote assumes the standard product fits and leaves the gaps to be discovered later as change requests. Another prices the gaps now.
- "Data migration included" means different things. Masters only, or masters plus opening balances plus open documents plus two years of vouchers. One dry run or two. Reconciled or not.
- Testing, training and hypercare are in or out. A quote that stops at go-live is cheaper and leaves you alone in the first month-end.
- Where custom code goes. Editing ERPNext's core code is quicker on day one and expensive at every upgrade after. A separate app costs a little more to set up and keeps upgrades possible.
- Team mix. Senior consultants in the workshops and juniors on configuration is a different cost from juniors throughout.
- Package pricing. Some proposals list modules as line items with a figure against each and say nothing about your processes. That is a price for software you already get free, plus an unknown.
The lowest quote is often not the cheapest project. It moves cost out of the proposal and into change requests after you have signed.
How to compare two proposals
Ask every bidder the same questions and put the answers side by side.
| Ask | A weak answer | A useful answer |
|---|---|---|
| What requirement list is this priced on? | "As per the discussion" | A numbered list, each line marked standard, configuration or custom |
| What migrates? | "Data migration included" | Which masters, which open documents, opening balances as at which date, how many dry runs, which reconciliations |
| Which integrations? | "Integrations as required" | Each system named, with direction, frequency and failure handling |
| What do you need from our team? | Not mentioned | Named roles and the time each is expected to give |
| What happens to anything not listed? | "Minor changes absorbed" | A written change-request process: explained, priced, approved before work |
| Where does custom code live? | Not mentioned | A separate app in your own repository |
| What do we pay against? | Calendar dates | Milestones you have signed off |
| What happens after go-live? | "Support available" | Hypercare length, support terms, how upgrades are handled |
If a bidder cannot answer the first question, they have not scoped the project. Their number is a guess, and you will pay for the difference later.
How a requirements document controls cost
In our method the second waypoint, Chart, produces a business requirements document (BRD) per module before anything is built. Every line states the current process, the expected process and how the system will handle it, and every line is marked standard, configuration or custom. Function heads review it, the CXO approves it and our implementation lead confirms it. Bizmap is accountable for what is in the BRD and nothing that is not. Anything outside it is a change request, explained and approved before any work starts.
That marking is the most effective cost control we know, because it puts the expensive lines in front of the people who can decide about them. For each custom line you can ask four questions. Is there a configuration answer we missed? Is the process worth keeping, or does it exist because of the old system's limits? Can it wait for a later phase? Does an existing app already do it? Taking out or deferring custom lines reduces cost more reliably than negotiating day by day.
Phases are contracted separately, and payment follows milestones you sign. You can stop after discovery with the BRD in hand and take it to any partner. A good BRD should make quotes comparable whoever writes them. We explain the three words in more detail in Standard, configuration or custom, and the full route, with the time each stage takes and what it needs from you, is on How we implement.
If this is your situation
If you are comparing ERPNext proposals, or about to ask for them, start with the requirements rather than the price. Our ERPNext implementation page describes the discovery and BRD stage, and if you are moving from Tally, Tally to ERPNext covers what migrates. When you are ready, tell us what you run today and which modules you need, and an engineer will reply with questions.
