A live NGO ERP demonstration should show whether a workflow produces the expected result, including when a user makes a request that should not succeed. Slides and prefilled dashboards can explain a product, but they do not establish how controls behave with your records and responsibilities.
Prepare a small test dataset and a written sequence before the session. Use it consistently across suppliers. Record what was observed, what required assistance and what was not demonstrated. Use the results to identify purchase conditions and unresolved gaps. Final acceptance testing follows against the delivered configuration.
The dataset makes a demo comparable
For broader context, see ERP testing and UAT. Procurement demonstrations establish what a supplier can show. Acceptance testing establishes whether the delivered configuration meets agreed requirements; a successful demo does not replace it.
Create an example donor, award, project, budget, supplier and several user roles. Include an ordinary approver, a user from another country scope and a user whose access will be revoked. Use test participant records to protect personal data.
Define expected balances and permissions in advance. An example award with 20,000 units of budget, 5,000 of actuals and 3,000 of outstanding commitments has 12,000 available under that operational definition. State the currency and reporting period so the result is unambiguous.
Ask the supplier to identify the environment, configuration and any prepared custom work. If a step cannot be completed, retain the gap rather than substituting a screen from another product version without explanation.
Follow an award into a purchase and expense
Use the restricted-fund control sequence to move a request through approval, commitment, partial receipt and invoice. Verify both the new balances and the relationships between records.
| Test | Action | Expected Evidence |
|---|---|---|
| DEM-01 | Create the award and approved budget | Conditions, dimensions and version |
| DEM-02 | Approve an eligible order for 2,000 units | Commitment increases by 2,000 |
| DEM-03 | Invoice 800 of that order | Actuals rise by 800; commitment falls by 800 |
| DEM-04 | Cancel 500 of the remaining order | Only that remaining commitment is released |
| DEM-05 | Attempt an ineligible cost | Configured rejection or authorised escalation |
The example begins with the stated opening balances and assumes no other activity. After DEM-02, available budget is 10,000. DEM-03 leaves it unchanged. DEM-04 increases it to 10,500. Check these results rather than relying on the demonstrator's interpretation.
Currency and reporting results must be reproducible
Where relevant, add a foreign-currency invoice with an example rate and agreed conversion method. Ask the supplier to show the source amount, rate units, date and resulting amounts. A converted total without its basis is incomplete evidence.
Produce a donor report using the selected period and budget mapping. Trace a figure back to the invoice and its approval. Change a reporting assumption through the permitted process and confirm that the previous version remains understandable.
Include an unmapped transaction or missing rate. Observe whether it is visible as an exception or silently omitted. A report that looks complete while excluding problematic records can be more dangerous than a report that refuses to run.
Try rejected and revoked actions
Test security boundaries through direct access, search and export. Attempt to retrieve another country's restricted records and repeat an action after the user's role has been removed. Confirm that audit evidence identifies the actor and result.
Try a request exceeding available budget and a changed order outside the original approval. Ask the supplier to show how authority is reassessed. If an override exists, establish who can use it and what evidence is required.
For integrations, simulate a failed or uncertain request where practical. Ask how an operator determines whether it succeeded before retrying. Do not substitute a promise of “automatic sync” for the required recovery behaviour.
Add scenarios for your delivery model
Choose additional scenarios based on the NGO's actual work. A fundraising organisation should follow a gift into a batched payout, refund it and reconcile the resulting adjustment. The donor record and bank balance must remain explainable without duplicate income.
A partner-funded programme should create a sub-award, release an advance, receive incomplete expenditure support and attempt the next release. Inspect the hold and authorised exception path. A field team should save a visit offline on two devices, synchronise both and resolve the duplicate while retaining the original evidence.
During each test, identify which application and supplier performs the action. A payment-provider screen is valid evidence of that provider's behaviour, but it does not prove the ERP reconciliation works. Follow the record across the interface using the integration test requirements and record any step that remains manual.
A partial result needs an exact explanation
Use four result states: pass, partial, fail and not demonstrated. Record the observed behaviour, evidence reference, limitation and follow-up owner. A partial result should explain exactly which part worked.
Connect the observations to the vendor scorecard. Mandatory gates should retain their status independently of attractive features shown elsewhere. Keep a future delivery commitment separate from evidence observed in the session.
Ask a reviewer who did not operate the system to reconstruct one scenario from the retained records. If the evidence cannot explain the sequence, auditability may be weaker than the demonstration initially suggested.
When is a proof of concept necessary?
A proof of concept is appropriate when a material uncertainty needs deeper testing, such as a complex interface, performance requirement or country-specific output. Define a narrow question, dataset, expected evidence and stopping condition.
Use the RFP structure to carry unresolved requirements into procurement and scope. Do not let a successful demonstration erase dependencies that were excluded from its environment.
Final user acceptance testing happens against the delivered configuration and agreed scope. A pre-purchase demo informs selection; it does not prove that data conversion, production permissions, integrations and operating procedures are ready for go-live.
Record expected and observed results side by side in the NGO ERP Demo / POC Workbook.
Specify starting records, actions and expected results using the NGO ERP UAT Library.
Six additional scenarios with explicit results
| Test | Action | Expected Result | Evidence To Capture |
|---|---|---|---|
| DEM-06 | Post EUR 2,000 at 0.85 GBP/EUR | GBP 1,700 with source amount and rate date | Entry and rate reference |
| DEM-07 | Run the report with one unmapped transaction | Exception visible; omission is not silently accepted | Report and exception record |
| DEM-08 | Revoke award access, then use screen and export | Both deny access under the agreed policy | User, time and test result |
| DEM-09 | Replay an accepted payment event | One gift and posting remain | Original and repeated event references |
| DEM-10 | Submit the same offline observation twice | One accepted observation with delivery history | Device and central record references |
| DEM-11 | Ask AI about a grant with a missing partner report | Output exposes missing evidence and stays reviewable | Question, sources, draft and review |
A Causeway workflow implementation example can inform the reference questions alongside your demonstration. Ask which parts of that delivery match the proposed scope and which differences need their own observed proof; a published case narrative does not replace your acceptance results.
Turn any unobserved result into one of the vendor follow-up questions, with a due date and required evidence.
Causeway reports programme reporting moving from quarterly to weekly among its implementation outcomes. A procurement demo can show how the reporting workflow works, but one session cannot prove a sustained operating cadence. Capture the demonstrated steps and agree the later measurement period separately.
Conclusion
Test a coherent transaction sequence and its exceptions, then compare observed results with expectations calculated beforehand. Record incomplete evidence honestly. A useful demo makes gaps visible and helps define the next decision; it should not be confused with final acceptance of the implemented service.
Arrange a workflow based Causeway demo
Scope ERP implementation services around the agreed rollout, responsibilities and acceptance evidence.
Arrange a requirements-led evaluation of Causeway. Share the test dataset, expected balances and exception tests before the session so the demonstration can address your actual questions.
Ask that each result be recorded with its configuration assumptions and any remaining work. Where a critical uncertainty cannot be resolved in a standard demonstration, discuss a bounded proof of concept with clear acceptance evidence and responsibilities.
Frequently asked questions
Can slides count as a passed demonstration?
Slides can explain architecture or intended behaviour, but they do not demonstrate live execution. Record them as documentation rather than a passed workflow test. Request observable evidence for the requirement being evaluated.
Should a demo use real beneficiary records?
Use test records wherever possible. They can represent the required structures and edge cases without exposing personal information. Ensure the dataset includes overlap, missing values or restricted fields needed to test the workflow.
How is a demo different from UAT?
A demo helps evaluate a product before selection. User acceptance testing, or UAT, checks the delivered configuration against the agreed requirements and expected results. The latter also needs relevant data, permissions, interfaces and operating procedures in scope.
