An NGO ERP requirements checklist should describe what the organisation needs to do and how it will know the result is correct. A list containing “finance, grants, reporting and security” is a set of topics, not a specification. Vendors can agree to those labels while proposing very different implementations.
Start with the operating model, then write requirements around records, decisions and exceptions. Give each requirement an identifier, priority, owner and acceptance evidence. This makes it possible to compare responses, connect demonstrations to actual needs and preserve decisions when the scope changes.
The operating model determines the requirements
Start with the legal entities and offices. Record their users, currencies, programmes, funding arrangements and existing systems. Then trace shared work across those boundaries, including procurement, group reporting, partner activity and central approval. Distinguish current operations from a future expansion assumption.
Use representative volumes where they affect design. State whether a number refers to active users, concurrent users, annual transactions or retained records. Avoid choosing a large round number without explaining the workload or growth assumption behind it.
List the workflows that cause the most friction today and the consequences of failure. A requirement protecting restricted expenditure may be mandatory, while a preferred dashboard layout may be negotiable. That distinction should be visible before vendors respond.
Start with what an NGO ERP connects, then use the NGO ERP capability framework to identify the workflows your requirements must cover.
Finance and grant controls define the first gates
The fund accounting structure should establish the dimensions needed to connect donors, awards, projects and transactions. Define the control behaviour as well as the data fields. Being able to tag a purchase with a grant code is different from preventing an ineligible purchase.
| ID | Requirement To Adapt | Evidence To Request |
|---|---|---|
| FIN-01 | Report an award's approved budget, actuals and outstanding commitments | Reconciled worked example |
| FIN-02 | Reduce the commitment when its invoice is posted | Partial-invoice demonstration |
| GRT-01 | Retain approved award conditions and amendments | Version and approval history |
| GRT-02 | Identify expenditure outside an eligibility period | Rejected or escalated transaction |
| FX-01 | Preserve source amount, currencies, rate units and date | Reproducible conversion trail |
| ENT-01 | Separate entity records and controlled group adjustments | Multi-entity close scenario |
Assign a policy owner to confirm each expected result, particularly where accounting treatment or donor interpretation is involved.
Specify programme, procurement and people workflows
Programme requirements should connect activities to indicators and show how distinct participants are counted. Keep the source evidence behind each reported result. Procurement requirements should follow a request through approval, receipt and invoice, including partial delivery. People requirements should identify assignments, expenses and approval authority. State which system owns payroll calculations.
| ID | Requirement To Adapt | Evidence To Request |
|---|---|---|
| PRG-01 | Distinguish participants from repeated attendances | Dataset containing overlap |
| PRC-01 | Preserve the remaining obligation after a partial receipt | Order, receipt and invoice trail |
| PRC-02 | Reapprove changes outside the original authority | Changed-order scenario |
| PPL-01 | Apply delegated authority only within its scope and dates | Expired-delegation test |
| EXP-01 | Prevent the same expense from being claimed twice under the defined policy | Duplicate-review scenario |
Do not require every possible module simply because it appears in a catalogue. If payroll remains in another system, specify the necessary data exchange and ownership rather than assuming ERP must replace it.
Security and integrations need observable results
Start security requirements with the data classes and permitted roles. Add the rules for privileged access and audit evidence. Specify retention and recovery expectations separately. Define what an unauthorised user must be unable to do through screens, exports and interfaces.
For integration requirements, name the authoritative system and permitted reads and writes. Define the data contract and timing. State how records reconcile and who recovers a failed transfer. An application programming interface, or API, is only one technical component of that arrangement.
| ID | Requirement To Adapt | Evidence To Request |
|---|---|---|
| SEC-01 | Prevent a country user accessing another restricted country's records | Direct-record and export tests |
| SEC-02 | Remove access after a role is revoked | Existing-session and new-login tests |
| INT-01 | Avoid duplicate business transactions after a retry | Simulated timeout and replay |
| INT-02 | Reconcile source and destination record totals | Controlled exception report |
| REC-01 | Restore an agreed workload within approved recovery objectives | Recorded recovery exercise |
What would count as an accepted result?
A useful requirement identifies the starting state, action and expected result. With 10,000 units of approved budget and 9,000 of actuals plus open commitments, a proposed 2,000-unit request exceeds availability. Specify whether the configured response is rejection or authorised escalation, then retain the decision evidence.
Include negative tests and changes after approval. State who will provide the data, who observes the test and what evidence is retained. A screenshot may document a result, but it does not show every step that produced it. Keep the scenario and observed sequence together.
Separate demonstration from final acceptance. A vendor can show a capability during selection while the configured implementation still requires user acceptance testing. The evidence should record the environment, version and limitations of what was observed.
Ten requirements with observable acceptance results
The following numbers define a test dataset, not a claim about a particular product. Assign a vendor evidence link, environment/version, tester and observed result to every row.
| ID / Priority | Starting State And Action | Acceptance Result |
|---|---|---|
| FIN-01 / Mandatory | Budget 10,000; actuals 6,000; commitments 2,000; request 3,000 | Reject under the test policy; availability remains 2,000; rejection is logged |
| FIN-02 / Mandatory | Invoice 500 against the existing commitment | Actuals become 6,500; commitment 1,500; availability stays 2,000 |
| GRT-01 / Mandatory | Change award end date through an approved amendment | New requests use the effective version; previous approvals retain their version |
| FX-01 / Important | Post EUR 2,000 at 0.85 GBP/EUR | GBP 1,700 is reproducible with source amount, rate and date |
| PRG-01 / Mandatory | Two activities have 80 and 60 participants with 20 shared | Report 140 participations and 120 distinct people with correct labels |
| DON-01 / Mandatory | Set donor preference to no fundraising email | Next authorised campaign export suppresses that donor |
| INT-01 / Mandatory | Replay the same accepted payment event | One gift and one posting remain; retry outcome is traceable |
| SEC-01 / Mandatory | Revoke a user's award access, then request its direct URL and export | Both are denied under the agreed session-revocation policy |
| AI-01 / Important | Ask a permitted question whose source pack omits a partner report | Output exposes the missing evidence and remains a draft for human review |
| REC-01 / Mandatory | Restore an agreed test backup to an isolated environment | Reconciled records and measured recovery satisfy the organisation's stated RTO/RPO |
RTO means recovery time objective; RPO means recovery point objective. Set their values from operational requirements before testing. Set mandatory and important requirements before adding preferences. A preferred chart colour must not outweigh a failed payment replay test.
Mandatory needs and preferences carry different weight
Use mandatory gates for requirements that must be satisfied before proceeding. Weight other criteria according to their importance, with a documented rationale. The NGO ERP vendor scoring methodology should not allow a high score in presentation or convenience to cancel a failed essential control.
Attach the reviewed requirements to an NGO ERP request for proposal. Require vendors to distinguish standard capability, configuration, third-party dependency, custom development and unsupported needs. Ask for assumptions, effort and evidence, not only a yes-or-no answer.
Version the checklist after clarification. Record why priorities changed and who approved the change. Otherwise a difficult requirement may disappear during negotiation without the people relying on it realising that the scope has changed.
Extend requirements beyond finance headquarters
Requirements often become incomplete because only finance and IT attend discovery. Add fundraising, treasury, partner management, field staff and the people responsible for privacy and safeguarding. They see failures that a ledger-only workshop will miss.
| Area | Testable Requirement Example | Evidence Needed |
|---|---|---|
| Donor operations | A communication preference change reaches the approved campaign system | Changed record and confirmed suppression |
| Payments | A returned settlement reopens the exception without creating a second gift | Processor reference and ledger reconciliation |
| Sub-awards | An overdue partner report affects the next release under the agreement | Hold, authorised exception and decision history |
| Field capture | Two devices submit the same visit while offline | Duplicate review with both originals retained |
| Vendor assurance | Offered hosting and support services fall inside supplied evidence | Scope, period, exclusions and contractual mapping |
Develop payment tests with the owners of donation reconciliation and field tests with the people using offline workflows. Keep assurance requests separate from product behaviour tests: a successful demo does not establish a vendor's audit scope.
If requirements are still disputed across teams, ERP consulting can help define the assessment scope. Retain organisational ownership of priorities and acceptance decisions.
Turn the operating needs above into testable requirements with Global NGO ERP Requirements Builder. Keep mandatory requirements separate from preferences.
Specify starting records, actions and expected results using the NGO ERP UAT Library.
Conclusion
A requirements register is usable when each mandatory need has an owner, a realistic test and an observable result. Start with the operating model, then follow the records across finance, programmes, people and external services. Separate the first release from future scope. A requirement that only says a module is available will not reveal a broken handoff; an accepted transaction and its exceptions will.
Test your requirements with Causeway
Scope ERP implementation services around the agreed rollout, responsibilities and acceptance evidence.
Contact SDLC Corp to review your requirements against Causeway. Bring a prioritised register and several acceptance scenarios. Use them to separate demonstrated capability from configuration, integration and proposed development.
Ask for a response against the same requirement identifiers, including gaps, dependencies and evidence. This gives your team a practical basis for comparing scope and deciding which questions need further testing before commitment. Keep policy and applicability decisions with the responsible people in your organisation.
Frequently asked questions
How detailed should a requirement be?
Detailed enough for two reviewers to recognise the same expected result. Include relevant records, conditions, actions and evidence, but avoid prescribing unnecessary implementation details. Add examples where a broad term could hide different interpretations.
Should every requirement be mandatory?
No. Reserve mandatory status for genuine conditions of proceeding. Distinguish preferences and phased needs so vendors can propose realistic options. Too many unexamined mandatory items can obscure the few controls that truly cannot be compromised.
How can vendors prove a requirement is met?
Use appropriate evidence: documentation, a live scenario, an integration test or a measured recovery exercise. Record the environment and limitations. A contractual commitment to deliver later is different from a capability demonstrated today.
