E-MYTH

Business systems

Donation management: pledges, collections and memberships

Inspect actual demo contribution and membership screens, distinguish pledges from confirmed receipts, and define donor reporting and sponsorship boundaries.

Hayat Fund demo — Donation management: pledges, collections and memberships

A donor's promise, an active membership and money actually received are different facts. Adding them into one “donations” total makes it difficult to know what the institution can reconcile or responsibly plan around.

This walkthrough uses fictional contribution and membership records in Hayat Fund's presentation version. The Arabic screenshots illustrate operational records, not actual fundraising results or accounting advice.

Separate pending pledges from collection

The contribution workspace shows pledges awaiting receipt confirmation separately from collection totals. In the captured demo it displays 2,025 JOD pending and zero collected. The right lesson is the separation of states, not the apparent size of either amount.

01 — A pledge is not a receipt
Hayat Fund — Demo screen: A pledge is not a receiptView the full-size screen ↗
Actual synthetic contribution workspace. Pending commitments and collection indicators are separate. A description written on a contribution is not a substitute for its confirmed receipt state.

For a real setup, agree who confirms receipt, the supporting reference, the date used for reporting and the procedure for correction. Include financial and in-kind contributions in the requirements without assuming they share identical quantity or valuation fields.

Give recurring commitments their own context

The funding area includes campaigns, membership programmes and user subscriptions. These answer questions about participation and recurring commitment that a one-time contribution record cannot answer by itself.

02 — Membership has its own dates and status
Hayat Fund — Demo screen: Membership has its own dates and statusView the full-size screen ↗
Actual fictional donor membership, with programme, start date, end date and status. Active membership does not prove that every related payment has been collected.

Test renewal, cancellation and an unpaid commitment. Specify whether cancelling membership affects future reminders, existing pledges or both. Do not derive that policy merely from the presence of a Cancel button.

Connect the donor account without exposing beneficiary files

A donor can follow relevant contributions, membership and messages. That does not require broad access to student applications, social research or internal eligibility notes. The institutional role model should distinguish donor participation from staff funding administration.

Where a sponsor is allocated to a beneficiary's semester, preserve the relationship and the permitted allocation amount. That link is not evidence of donor collection, bank transfer or a student payment. See the semester support guide for the separate approval and disbursement steps.

Keep the limits of the implementation explicit

The system records contributions and support payments, but this review does not establish automatic bank execution or complete matching of every incoming donation to every outgoing payment. Those requirements need dedicated reconciliation rules and verified integrations if they are part of your scope.

Similarly, a loan-type support decision does not by itself provide graduate repayment scheduling and debt collection. Define any needed repayment module separately rather than discovering the gap after launch.

Make reports reconcile to records

Ask staff to open a collection figure, identify its underlying confirmed receipts and export the same filtered population. Then compare it with a pending-pledge view. A difference is expected when the populations differ; an unexplained difference is a problem to resolve.

Use operational reports with explicit date ranges and metric definitions. A contribution's creation date, intended date and confirmed receipt date may answer different questions. Choose the one that matches the report's stated purpose.

What should the first pilot include?

Create a fictional donor, a pledge, a confirmed receipt and a membership. Add one correction and one cancellation under authorised roles. Inspect their effects on the donor's account, staff queue and reports. Keep the pilot small enough that the finance team can explain every line before migrating the complete funding history.

Continue with the workflow you need

How this walkthrough was prepared

We reviewed the Hayat Fund implementation and opened its local demo on November 4, 2026. Screens show actual interfaces with synthetic fixtures, cropped to the relevant area without changing their content. Interface states alone do not establish customer outcomes or successful external delivery.

More perspectives