An ERP for an NGO or nonprofit has to record each transaction against several dimensions at once, usually fund, grant, project, budget line and cost centre, so that restricted money is spent only as the donor allows and each funder gets a report in its own format. Packaged nonprofit finance systems cover this well for standard cases. Custom ERP is justified when donor rules, field operations or reporting formats are unusual enough that configuration cannot keep up.
Most nonprofits start with accounting software and spreadsheets. The pain arrives when a third grant is awarded with different rules, when a country office wants to spend and report in a local currency, or when an auditor asks you to prove that a restricted grant paid only for allowed costs. This guide is for the people who then have to choose a system. It builds on our general guide to ERP for nonprofits, which covers the basic modules and a selection checklist, and goes further into the data model and the decision between packaged and custom. For the larger decision of buying versus building any ERP, see custom ERP development.
How is NGO accounting different from commercial accounting?
A company asks whether it made a profit. A nonprofit asks whether it used each pound or dollar for the purpose it was given for. That changes the shape of the books in three ways.
- Restrictions. Money from a donor can be restricted to a purpose, a place or a period. Frameworks name this differently: US GAAP (ASC 958) reports net assets with and without donor restrictions, and UK charity accounting under the Charities SORP distinguishes restricted and unrestricted funds. Your system must track the restriction at transaction level, not only at the balance sheet.
- Multiple dimensions. One expense, such as a field coordinator's salary, may be shared between three grants and core costs.
- Accountability to funders. Each grant has its own budget, period, eligible costs and report format, and some require receipts, timesheets or procurement evidence to be available on request.
Rules differ by country and funder, so confirm your obligations with your auditor and your grant agreements. The system should be designed to support the rules you have, and it cannot interpret a donor agreement for you.
The dimensions an NGO ERP needs
The common design is a general ledger with extra dimensions attached to every line. A typical set:
| Dimension | What it answers | Example |
|---|
| Fund | Which restriction class does this belong to? | Unrestricted, restricted, endowment |
| Grant or donor award | Which agreement pays for it? | Award reference, donor, start and end dates |
| Project or programme | What work was done? | Clean water, school feeding |
| Budget line | Which approved category does it count against? | Staff, travel, equipment, indirect |
| Cost centre or location | Where was it spent? | Country office, district, head office |
| Activity or output | Which result was it for? | Used in logical frameworks and donor results reporting |
Keep the number of dimensions as low as your reporting needs. Every extra dimension is a field staff must fill in correctly, and mistakes multiply. A useful rule is that each dimension must feed a report someone actually reads.
Two design points matter more than the rest.
- Make the combinations valid or invalid by rule. If a grant ends in March or only allows certain budget lines, the system should refuse a posting outside that, or flag it for approval. Spreadsheet-based control relies on someone noticing.
- Allow a split at entry or by allocation. Splitting one payroll cost across grants by percentage should be a rule applied each month with an audit trail, not a manual journal.
The grant lifecycle in the system
A grant moves through stages, and the ERP should reflect each one.
- Pipeline and proposal. Opportunity, donor contact, amount applied for, probability. This is often held in a CRM rather than in finance; see whether your ERP needs it or can connect to your fundraising tool.
- Award. Agreement terms entered as structured data: amount, currency, period, eligible budget lines, indirect cost rate, reporting dates, restrictions.
- Budget load. The approved budget by line and period, with a version history.
- Spending. Purchase requests, orders, payments and payroll coded to the grant, checked against budget and eligibility as they happen.
- Monitoring. Budget versus actual by line, burn rate, forecasts, and alerts when a line is nearly spent or a period is ending.
- Reporting. Financial reports to the donor in its format, and supporting documents ready on request.
- Closeout. Final report, refund of unspent funds if required, and records kept for the retention period the agreement sets.
If your grants come from governments, some funders apply cost principles and audit requirements set by rule. For example, US federal awards follow the Uniform Guidance in 2 CFR 200. Whether it applies, and how, depends on your awards, so check each agreement.
Allocating shared costs fairly
Shared costs are where nonprofit finance teams spend the most time. Rent, IT, management salaries and vehicles serve several grants. Typical methods:
- Direct charging where the cost clearly belongs to one grant.
- Allocation by a driver, such as staff time, headcount or floor area, applied monthly to a pool of costs.
- Indirect cost rate applied as a percentage to direct costs, as the donor agreement permits. Some donors set a rate, some cap it, some pay none.
The system should store the method as a rule, run it on a schedule, show the working and keep the history. If the rule is in someone's head or in a spreadsheet macro, the allocation cannot be audited. When funders disagree on how to allocate the same cost, the ERP must support more than one allocation basis in parallel, a requirement packaged systems may handle only through workarounds.
Donor and funder reporting
Funders typically want some of the following:
- Budget versus actual by approved line for the reporting period.
- A transaction listing with supporting documents.
- Cash forecasts and requests for the next instalment.
- Results data linked to spending (outputs, beneficiaries).
- Currency conversion at stated rates, with the exchange difference shown.
Ask a vendor to produce two of your real donor reports during a demonstration, not a sample report. Count how many are produced by the system directly, how many by an export plus a spreadsheet, and how many by retyping. A system that still needs retyping for your three largest donors has not solved the main problem.
Field operations, offline work and multiple currencies
Many NGOs work where connectivity is unreliable and staff use phones. Questions to ask:
- Can field staff submit expense claims, requests or stock movements from a phone, and do they work offline and sync later?
- Can the head office see all country offices while each office sees only its own data?
- Can an office hold its books in local currency while reporting to donors in another, with documented exchange rates?
- Can approval limits and segregation of duties be set by role, with an audit trail?
Our guide to offline-first field service apps explains how offline work is designed, and the same patterns apply to field data collection for finance.
When is a custom ERP justified for an NGO?
Be careful here. Many NGOs should buy. A packaged nonprofit finance and grant system is usually the right answer when your donors are few, their rules are common, and your team is small. Custom becomes worth examining when several of the following are true.
| Signal | Why it points to custom |
|---|
| More than a handful of donors, each with its own report format | Report building by configuration becomes a project of its own |
| Field programmes with offline data capture that must feed finance | Packaged systems usually need a separate mobile product |
| Beneficiary, case or programme records must link to spending | The programme data model is yours, not a standard one |
| Complex allocation rules that differ by donor | Packaged allocation tools support one or two methods |
| Per-user licence cost is a constraint for a large field workforce | A custom system's cost does not scale per user |
| You need to own the code, host in a specific place or keep full control of the data | Ownership and hosting terms are set by you |
| Integrations with fundraising, HR, government portals or partner systems | Integration effort dominates the project |
If two or three of these are true and the packaged options need heavy customisation, compare a custom build on total cost over five years. Our guide to ERP total cost of ownership shows how to model that fairly, and the ERP versus custom development page lays out the comparison. If almost none are true, a packaged system is the sensible, lower-risk choice.
Data protection and donor trust
NGOs hold sensitive data: donor details, beneficiary records, sometimes data about vulnerable people. Design access by role, keep an audit trail, and minimise what is collected. We do not claim compliance with any data-protection law or certification for a system in advance: the controls are designed to support the rules that apply to you, and they are confirmed per project with your own advisers. If you work with partners in several countries, decide early where data is stored and who can reach it.
How Timeline Digital approaches NGO systems
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. We build custom ERP systems and can connect to existing finance and fundraising tools. For an NGO, the pilot is often the grant module (award, budget, spending checked against budget) plus one donor report built from your own data. Before you commit to the full project, we build 2 to 3 of your key modules as working software, free of charge, ready in about 2 days. Your team tests the pilot, and the full build starts only after you approve it. Timeline Digital does not publish prices for custom software, because every project is custom. We can sign an NDA before you share donor agreements. Support hours are Monday to Friday, 9:00 to 18:00 Pakistan time (PKT, UTC+5).
Selection summary
- List your donors and their rules before looking at software.
- Choose the smallest set of dimensions that feeds real reports.
- Make grant terms structured data, not attachments.
- Run your two hardest donor reports in every demonstration.
- Check allocation, offline work and multi-currency with real examples.
- Use the table above to decide whether custom is worth comparing; if not, buy.