How ERPNext for non-profit organizations fits your operations
ERPNext covers the core finance and project work a charity or NGO needs, but donor, member, grant, chapter and volunteer records come from the separate Non Profit app, which is not part of standard ERPNext. Accounting, projects, purchasing and reporting are standard ERPNext functions, so fund-level books and program delivery can live in one system without license fees. Supporter records are the part that needs a separate decision, and that decision should come first because it sets the data model, the roles and the upgrade path for everything else.
For finance teams, the change is that restricted and unrestricted funds, grant spending and period reporting have to be designed in the ledger from the start, using accounting dimensions and cost centers agreed with your auditors and funders. Program teams gain project records, timesheets and task tracking tied to the same costs finance sees. Fundraising and membership teams depend on the Non Profit app for donors, memberships, grants and volunteers, so they should not begin data entry until someone confirms which Non Profit app version works with your ERPNext version. The official ERPNext non-profit documentation describes the feature set, and the frappe/non_profit repository shows its current state.
Before the build starts, confirm with the Non Profit app maintainers or your implementation partner whether the app supports your target ERPNext release, and plan a fallback if it does not. If the app is incompatible, decide whether supporter records stay in a separate CRM, become custom DocTypes built in your own app, or wait for a compatible release. Ask for that compatibility statement in writing, because it determines the scope, the testing effort and the upgrade plan for the whole project.
What non-profit operations require from ERPNext and what each means for the build
This table maps typical non-profit operating needs to what the ERPNext non-profit documentation and the Non Profit app cover, and what each need means for configuration, custom work or a decision to confirm. Read each row as a question to answer before the build starts. The main takeaway is that most donor, grant and volunteer needs depend on the separate Non Profit app, so its compatibility with your target ERPNext version should be settled first.
| Requirement | Source of capability | What it means for the build |
|---|---|---|
| Restricted and unrestricted funds | ERPNext non-profit documentation; accounting dimensions in ERPNext | Model fund sources as accounting dimensions or cost centers so restricted balances can be reported separately. Confirm the reporting view your auditors expect. |
| Donor and pledge tracking | Non Profit app (frappe/non_profit) for donors | Donor records and donation handling come from the separate app. Confirm the app version works with your ERPNext release before committing to this design. |
| Membership renewals | Non Profit app for members | Renewal invoicing and reminders may need configuration or custom scripts. Confirm which membership events the app supports natively. |
| Grant budgets and reporting | Non Profit app for grants; ERPNext projects and accounts | Grant budgets are often tracked against project and cost center structures. Expect custom reports for funder formats and confirm required report layouts early. |
| Chapter structure | Non Profit app for chapters | Chapters map to organizational units that drive permissions and reporting. Decide whether chapters are companies, cost centers or separate sites before data entry begins. |
| Volunteer hours | Non Profit app for volunteers; ERPNext timesheets as a fallback | Confirm whether the volunteer records in the app meet your hour-tracking needs. If not, plan custom doctypes or a timesheet-based approach. |
| Access for field staff | ERPNext roles and permissions; web forms | Field users usually need restricted roles and limited screens. Plan role permissions and test them with real user profiles before rollout. |
Which modules, apps and settings non-profits configure first
Most non-profit deployments of ERPNext start with the same few settings: how money is tracked by fund, how programs are planned, how donor and member records are kept, and how staff sign in. Each card below names one of these, what it drives, and what to confirm before the build starts.
Chart of accounts and fund tracking
Cost centers or accounting dimensions are the usual way to separate restricted and unrestricted funds in ERPNext. The chart of accounts should reflect how your auditors and funders expect to see income and expenses, not only how the books were kept before. Confirm with your auditor whether a cost center per grant, a dimension per fund, or both will give the reports you need, and test one restricted grant end to end before loading history.
Projects and tasks for programs
ERPNext projects and tasks let you track program activity, milestones and time against each funded program. Link each project to its cost center so program spend can be reported next to the grant budget it draws on. Decide early who owns each project and how program staff record time, because those choices shape the reports funders ask for later.
Non Profit app for donors and members
Donors, members, grants, chapters and volunteers come from the separate Non Profit app, not from standard ERPNext. Before you plan around it, confirm that the app version you need is compatible with the ERPNext and Frappe versions you intend to run, since the documentation notes it may not match the latest releases. Ask for a written compatibility check as part of scope.
Data Import for legacy records
The Data Import tool loads records from CSV or Excel files and supports child table rows, which suits donor lists, grant registers and historical transactions. The documentation advises importing only a few thousand records at a time, so plan batches and reconcile totals after each one. Agree in advance which legacy records move and which stay in the archive.
LDAP or social login for staff and board
ERPNext supports LDAP login against Active Directory or OpenLDAP, and Social Login Keys for providers such as Google or Microsoft or for custom OpenID Connect endpoints. Use one identity source for staff and a separate, limited path for board members who only need reports. Confirm how group-to-role mapping will work at each login, because that mapping decides who sees donor and grant data.
Print formats and reports for funder packs
Funder reporting usually means a fixed set of statements, grant-to-date summaries and narrative attachments generated from the same records. Print formats and custom reports can produce these from ERPNext data without manual rework each quarter. Build a sample pack with a funder's real template early, and confirm which report fields depend on the Non Profit app so you know what breaks if that app is held back.
Deciding whether the Non Profit app fits your ERPNext version
The non-profit features in ERPNext do not ship with the core product. They come from the separate Non Profit app (frappe/non_profit), which covers donors, members, grants, chapters and volunteers, and which is not part of standard ERPNext. The app may not be compatible with the latest ERPNext and Frappe versions, so the version decision is really a decision about the app first and the core second. Before you commit to a target version, open the app's repository and read its compatibility notes, release history and open issues for the exact ERPNext release you plan to run. Then confirm the same pairing with Frappe, not only with the app's maintainers.
The lifecycle dates make the trade-off concrete. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. A non-profit still on version 14 has no upstream support, so it must move. If the Non Profit app only works on an older line that is nearing its own end of support, you face a choice: stay on a supported core and rebuild donor, grant or membership workflows with standard doctypes and custom apps, or accept an older core and plan a later upgrade. Ask the implementation partner to write down which option carries the lower risk for your data, your funders' reporting needs and your staff time.
Write the decision down before build starts. Record the ERPNext and Frappe versions you will run, the Non Profit app version and its tested pairing, who signs off on that pairing, and the date by which you will revisit it. Ask the partner to test a restore of your donor and grant records on a staging site with the same versions, and to confirm that the app's custom fields, scheduled jobs and print formats still work after the core is updated. Treat any gap you find as scope to price in the written plan, not as a surprise at go-live.
Hosting options for a non-profit ERPNext and what each one limits
Frappe Cloud shared hosting places your ERPNext site on a shared bench managed by Frappe. It is the lowest-cost hosted entry point, and Frappe handles the platform underneath your site. The trade-off is that you give up control over the server and the code you can run on it.
- Starting price: the ERPNext pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month. Confirm which plan, storage and user limits that price includes.
- Server Scripts: public shared benches do not allow Server Scripts, so any automation that depends on them will need a different route or a different host.
- Custom apps: you cannot install arbitrary apps on a public shared bench. Confirm whether the Non Profit app is offered on this tier before you plan around it.
- Support coverage: Frappe's warranty applies only when you are on a listed version and subscribed to a matching Frappe Cloud support plan.
- Data location: confirm where the data is hosted and what backup and restore options Frappe provides on your plan.
Before committing, ask for the exact plan terms in writing and test the donor, grant and volunteer workflows on a trial site.
Frappe Cloud dedicated servers give your organization its own server on Frappe Cloud. This removes the shared-bench restriction on Server Scripts, but the server still runs on Frappe's platform. It suits organizations that need more control without managing infrastructure themselves.
- Starting price: the ERPNext pricing page lists Frappe Cloud dedicated servers from 125 US dollars per month. Confirm what this covers, including storage, backups and bandwidth.
- Server Scripts: dedicated capacity is the hosted route where server-side automation is most likely to be available, but confirm the setting on your bench before relying on it.
- Support plan: the warranty depends on a Frappe Cloud support plan that matches your ERPNext version, so price that plan separately.
- Version lifecycle: ERPNext version 14 reached end of life on January 31, 2026, so a new site should target a supported version.
- Non Profit app: confirm with Frappe whether the Non Profit app can be installed on your dedicated server and whether it is compatible with your chosen version.
Ask for a written statement on which apps and settings are allowed on the dedicated tier.
The frappe_docker project provides production Docker images and Compose files for ERPNext and other Frappe apps. You run the stack on servers your organization controls, with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. Licensing is free, but you pay for the servers, storage and the people who run them.
- Software cost: self-hosting ERPNext is free according to the ERPNext pricing page, so the recurring cost is infrastructure, staff time and any support contract you choose.
- Production images: use the production images and Compose files, not the single-file demo setup, which the project marks for short-lived evaluation only.
- Custom apps: building a custom image lets you include the Non Profit app and other apps, but you own the build pipeline and upgrade testing.
- Operations: you are responsible for backups, TLS, patching, monitoring and the background jobs that run the scheduler.
- Support: without a Frappe Cloud plan, confirm which vendor or partner will support the stack, since Frappe's warranty terms are tied to its hosted support plans.
Confirm the Non Profit app's compatibility with the exact ERPNext and Frappe versions in your image before you build it.
A manual install uses the bench command line tool on a Linux server you control. It gives the most control over the Frappe environment, apps and site configuration, and it is the path most suited to heavy customization. It also gives you the most operational work.
- Software cost: self-hosting is free, so costs come from servers, engineering time for setup and upgrades, and any support arrangement.
- Bench control: you can install apps and set configuration keys such as
server_script_enableddirectly, which is useful when Server Scripts are needed. - Upgrades: each major version change requires testing the Non Profit app against the new release, since the app may lag behind the latest ERPNext and Frappe versions.
- Skills: the team must be comfortable with Linux, databases, Redis, process supervision and Frappe's update commands.
- Documentation: follow the official installation steps for your version and record every change so the environment can be rebuilt.
Before choosing this route, confirm the Non Profit app's supported versions with the maintainers and plan a test site for each upgrade.
Moving donor, grant and ledger history into ERPNext without a bulk load
Load history in stages rather than in one bulk import. ERPNext's Data Import tool reads CSV or Excel files, or public Google Sheets, against downloadable templates, and it supports child table rows, so a single document such as a sales invoice with its items can arrive in one file. The ERPNext documentation advises importing only a few thousand records at a time, which means a supporter list of tens of thousands of rows becomes a series of batches, each with its own file, log and sign-off. Start with the chart of accounts, then opening balances, then supporters, then grant agreements and their linked transactions, because later records reference earlier ones. Confirm with your implementation lead which of these your fund accounting will need as live records and which can stay as summary entries.
Validate every batch before the next one starts. Reconcile opening balances per fund and per bank account against the closed statements from your old system, and check that totals by donor and by grant match the source before any further load. Decide what stays out of ERPNext altogether: older donation detail, closed grant correspondence and scanned agreements often belong in an archive with a documented retrieval route. Donor duplicates are the most common defect. Match on a stable key such as a supporter ID, email address or postal address, agree a merge rule with the fundraising team, and keep a record of every merge so a donor can be traced back to the original rows.
Treat the migration files as personal data. Exported supporter lists, bank details and gift histories should be stored on access-controlled storage, shared only through approved channels, and deleted from working folders once each batch is accepted. Limit who can run imports by using ERPNext roles, and check the import log for skipped or updated rows. Plan a retention rule for the source extracts before the first load, since data protection obligations apply to copies made during migration as well as to the live system. Ask your partner to document the batch order, the validation checks and the deletion step in the migration runbook.
How a non-profit ERPNext rollout runs from scope to go-live
This sequence takes a non-profit from a written scope through configuration, data migration, parallel reporting and handover, so finance and program teams close a reporting period on the new system before they rely on it.
Confirm the Non Profit app and version fit
Before any build, confirm which ERPNext and Frappe versions you will run and whether the Non Profit app supports them. The ERPNext non-profit documentation notes that this app is separate from standard ERPNext and may not be compatible with the latest versions, so DeployOpen checks the app's current state against your chosen release and records the result in writing. The non-profit provides the list of donor, member, grant and volunteer functions it needs. The output is a signed compatibility note that decides whether the app is used, replaced by standard ERPNext features, or built as a custom app.
Map funds, programs and grants
Work with finance and program leads to translate fund restrictions, grant terms and program budgets into the accounting structure. This covers which funds are restricted or unrestricted, how grant periods and reporting deadlines are tracked, and which cost centers or dimensions tie spending to a program. The non-profit must supply the signed fund rules, grant agreements and the chart of accounts currently in use, plus a named owner who can decide ambiguous cases. The output is a reviewed fund and program map that the configuration will follow.
Choose the hosting model
Decide where ERPNext runs: self-hosted on your own servers, in a cloud account you control, or on Frappe Cloud. Self-hosting is free as software, but servers, backups, TLS, email delivery and staff time are your costs. Frappe Cloud has published starting prices on the ERPNext pricing page, and that page also notes that warranty coverage depends on a matching support plan. DeployOpen documents the chosen install method, environment separation between test and production, and the backup target. The output is an approved hosting decision and an environment diagram.
Configure accounting and projects
Build the company, chart of accounts, cost centers, dimensions, projects and tax settings from the approved fund map. Each grant or program is set up so that its income and expenses can be reported separately. Configuration is tested with sample transactions that finance signs off, such as a restricted gift, a grant drawdown and a shared staff cost split across two programs. The output is a configuration workbook and a set of test transactions with expected results.
Migrate and reconcile opening balances
Load master data and opening balances from the existing ledger, using the Data Import tool with its templates in batches, because the documentation advises importing only a few thousand records at a time. Opening balances are reconciled account by account against the last closed period in the old system, and open grant balances are matched to the grant agreements. The non-profit provides exports, bank statements and donor and member lists with the consent basis for holding them. The output is a reconciliation report with zero unexplained differences or a list of approved exceptions.
Set roles and sign-in
Define roles and permissions so that staff see only the funds, programs and personal data their job requires. Decide how users sign in: local accounts, LDAP against your directory, or Social Login Key providers such as Google or Microsoft, each with its own setup and testing. Server Scripts are disabled by default from version 15, so any custom logic is reviewed before it is enabled. The output is a role matrix signed by the executive director or finance lead and a sign-in test log for each login path.
Train finance and program staff
Run role-based training sessions using the organization's own fund and grant scenarios rather than generic demos. Finance staff practice month-end entries, restricted fund transfers and grant reports, and program staff practice the records they own, such as volunteer hours or program events. Training materials are written for your configuration and kept in your document store. The non-profit must release staff time for sessions and name super users who will answer day-to-day questions. The output is a training record per role and a short list of open questions.
Run parallel reporting for one period
Keep the old system live for one full reporting period while ERPNext records the same transactions. At period close, the fund balance reports, grant expense reports and statement of activities produced by ERPNext are compared line by line with the legacy reports. Every difference is traced to a cause, corrected in configuration or explained in writing. The non-profit confirms which reports its board and funders require. The output is a parallel-run variance log with each variance resolved, accepted or scheduled for correction.
Go live and hand over
Switch the live ledger to ERPNext on an agreed date, freeze the old system for editing, and run the first live close with DeployOpen on call. Handover includes the configuration record, the runbook for backups, restores and upgrades, the role matrix, the test scripts and the open issue list with owners. Support after handover is a separate agreement, either a retainer or internal ownership. The output is a signed go-live acceptance and a handover pack that your staff can run without DeployOpen present.
Donor privacy, grant reporting and access controls to confirm
Donor records, grant budgets and volunteer details sit in the same system as your accounts, so access and privacy decisions affect every module. The cards below set out the controls to design and the obligations that stay with your organization, its advisers and its regulators.
Login and role mapping
ERPNext can authenticate staff against Active Directory or OpenLDAP through LDAP Settings, and it maps LDAP groups to ERPNext roles at each login. Social Login Key can add providers such as Google or Microsoft for other users. Confirm which group decides who sees donor records and grant ledgers, who removes access when someone leaves, and whether volunteers should ever use a social login. Role changes made in the directory take effect at the next login, so test that path before go-live.
Server script limits on donor automation
Donor-specific automation such as thank-you triggers, retention flags or grant alerts is often written as Server Scripts. From version 15, these are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Decide early whether automation will run as custom apps on your own infrastructure, which the platform does not restrict in the same way, and confirm that hosting choice before you design the workflow.
Where supporter personal data lives
Donor names, contact details, giving history and volunteer records are stored as ordinary ERPNext and Non Profit app records, so they are subject to the same permissions, backups and exports as financial data. Map each personal data field, decide which roles can view or export it, and set retention rules for lapsed supporters. Confirm with your data protection adviser which data you may hold, for how long, and on what legal basis in each country where you raise funds.
Audit trails for restricted grant spending
Grant funds often carry conditions on what can be spent, on which project and in which period. ERPNext records document changes and submissions, but the reports that prove a cost met a grant condition depend on how you set up cost centers, projects and accounting dimensions. Test a sample grant from budget to payment, export the trail, and confirm with the funder what evidence they will accept before you rely on the system for reporting.
Who signs off on compliance
DeployOpen plans, configures and documents access controls, retention settings and audit evidence, and it can prepare systems for an independent assessment. It does not issue audit reports, attestations or certifications, and that decision rests with independent auditors and certification bodies. Your tax advisers, auditors and funders set the obligations that the configuration must meet, so ask each of them to confirm their requirements in writing before the scope is agreed.
Version support before access design
Access design depends on the version you run. Frappe's supported versions page lists version 14 as end of life from January 31, 2026, with version 15 supported until the end of 2027 and version 16 until the end of 2029. The Non Profit app may not be compatible with the latest ERPNext and Frappe versions, so confirm compatibility for your chosen version before you commit the role model, donor fields or grant workflows to it.
What non-profits ask before hiring a partner for ERPNext
What drives the cost and effort of an ERPNext implementation for a non-profit?
Scope drives most of it: how many funds, grants and cost centers you track, how many entities or chapters report separately, and how much custom donor or grant logic you need. Data quality is the next factor, because cleaning donor, contact and grant records before import usually takes more effort than the import itself. Hosting, training for finance and program staff, and whether you need custom reports or print formats also add work. Ask any partner for a written scope that lists these items separately, so you can see what each one adds to the quote.
Does the Non Profit app work with the current ERPNext version?
Not necessarily. The non-profit features in ERPNext's documentation come from the separate Non Profit app (frappe/non_profit) for donors, members, grants, chapters and volunteers. That app is not part of standard ERPNext and may not be compatible with the latest ERPNext and Frappe versions. Before you commit to a design, check the app's repository and release notes against the exact ERPNext and Frappe versions you plan to run, and get a written compatibility check from any partner. If it does not fit, the fallback is usually to model grants and donors with standard ERPNext accounting and projects.
Can a small non-profit team run ERPNext without a partner?
A small team can run ERPNext, but it needs someone who can own the system over time. ERPNext is free and open source under GPL-3.0, so licensing is not the barrier. The work is in configuration, user permissions, backups, upgrades and reporting. Frappe's supported versions page also states that customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe, so check which support route applies to your hosting. Decide early who will handle month-to-month administration and who handles major upgrades.
How long does an ERPNext rollout take for a non-profit?
Duration depends on scope, data readiness and how many approvals the design needs, so no single timeline applies. A rollout limited to accounting and one grant pipeline is much shorter than a multi-entity build with donor, membership and volunteer workflows. Data migration is often the longest phase, because the ERPNext Data Import tool works best with batches of a few thousand records at a time, which means staged loads and repeated checks. Ask for a timeline tied to named phases and deliverables in the written scope rather than a single overall estimate.
What does the non-profit team need to provide for an implementation?
The team needs to provide decisions and data. Finance must confirm the chart of accounts, fund structure, grant reporting rules and approval limits. Program and development staff must describe how donors, members or volunteers are tracked today and which fields matter. Someone must export current spreadsheets or databases, clean duplicates and agree on record ownership. You also need named reviewers with time available for testing, a decision maker for scope changes, and access to your identity provider if you plan to use LDAP or social login through ERPNext's supported options.
What recurring costs remain after go-live?
Expect recurring costs for hosting, support and upgrades, and some internal time for administration. Frappe's pricing page lists self-hosting ERPNext as free, while Frappe Cloud shared site hosting starts at 5 US dollars per month, shared servers at 20 US dollars per month and dedicated servers at 125 US dollars per month. Those are list prices from the pricing page, and your actual cost depends on your choice of hosting, backup needs and support plan. Ongoing services such as upgrades, monitoring and testing can be bought as a retainer, so ask for them as a separate line in the quote.
How is a fixed-scope quote produced for ERPNext work?
A fixed-scope quote follows from a written scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope on that basis. The scope should list the modules, funds or grant workflows, integrations, data sources, migration batches, training sessions and hosting responsibilities. DeployOpen does not publish a price list, so the quote is built from that scope. Ask any partner what is excluded, how scope changes are priced, and which items you must provide, so the quote can be compared on equal terms.
Which parts of the non-profit setup need security review?
Access to donor and beneficiary data needs the most attention. Plan user roles and permissions before data import, because ERPNext controls visibility through roles and user permissions. If you use LDAP through LDAP Settings, check the SSL/TLS options and the mapping of directory groups to ERPNext roles, since that mapping runs at each login. Social Login Key supports Google, Microsoft, GitHub, Facebook or Frappe and custom OAuth or OpenID Connect endpoints, so confirm which providers your staff use. Server Scripts are disabled by default from version 15 and need the server_script_enabled setting, so decide whether you need them before you enable them.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For ERPNext at a non-profit, that means agreeing the accounting, project and donor or member requirements in writing before any build starts, then delivering and documenting them in your environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which modules, fund and project structures, and whether the Non Profit app is in or out.
- We confirm the Non Profit app's compatibility with your chosen ERPNext and Frappe versions before committing to it.
- A quote follows from the written scope, so your team can compare it against doing the work internally.
How we build
- We configure accounting, projects and roles, then customize only through custom fields, scripts and apps where needed.
- Server Scripts are gated by a setting from version 15 onward, so we confirm hosting allows them before design.
- Data migration uses the Data Import tool in batches, since the documentation advises a few thousand records at a time.
- We test donation, grant and volunteer workflows against your own sample records before go-live.
How we hand over
- Deliverables include configuration records, customization code, migration logs and runbooks for your staff.
- We document which app versions are running and the upgrade checks your team should perform.
- Access is set up for your administrators, with role permissions and any LDAP or social login agreed in scope.
- Handover covers backup and restore steps, with restores tested in your environment before sign-off.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Support can cover minor release updates on the version you run, based on the release notes you receive.
- Major version upgrades are scoped separately, including any Non Profit app compatibility work.
- Ask any provider which Frappe Cloud support plan or hosting terms apply to your version and who carries warranty.
