# Donor/Revenue Stream Forecasting

This use case explains how to forecast donations, membership income and other revenue streams for not-for-profit and education organisations in Model Reef.

You will:

* Segment income streams by donor type, product or channel.
* Model donor counts, retention, upgrade and acquisition.
* Forecast memberships, events and earned revenue.
* Connect income streams to programs and group level reporting.

Model Reef is not a donor CRM. It sits above CRM and fundraising tools, using aggregated metrics and imported data to drive financial forecasts.

## When to use this pattern

Use this pattern when:

* You rely on a mix of grants, donations, memberships, events and earned income.
* You want to understand how donor behaviour drives revenue.
* You need to test campaigns, pricing and retention strategies.
* You want fundraising and earned income assumptions integrated with program costs and cash planning.

It is often used alongside:

* Grant Funding Models
* Program Cost Modelling
* Multi Program Consolidated Reporting

## Architecture overview

Donor and revenue stream forecasting uses:

1. Income stream segmentation
   * Individual donors, major donors, corporates, trusts and foundations.
   * Memberships, events, courses or products.
   * Channels such as digital, mail, face to face or corporate partnerships.
2. Donor and customer drivers
   * Donor or member counts by segment.
   * Retention, upgrade and acquisition rates.
   * Average gift or spend per donor, member or transaction.
3. Revenue variables
   * Revenue per segment and channel.
   * One off versus recurring streams.
   * Timing of receipts.
4. Financial outputs
   * Income by source and program.
   * Channel performance metrics.
   * Cashflow and volatility patterns.

{% stepper %}
{% step %}

### Step 1: Define revenue segments and channels

Create a list of income streams that matter for planning, such as:

* Individual regular giving.
* Individual one off donations.
* Major donors.
* Corporate giving and sponsorship.
* Trusts and foundations.
* Memberships or subscriptions.
* Events and campaigns.
* Course fees or tuition.
* Merchandise or other earned income.

For each stream, decide whether it will live in:

* A program branch, where it is directly linked to a program, or
* A central fundraising or revenue branch, where it supports multiple programs.
  {% endstep %}

{% step %}

### Step 2: Create donor and customer drivers

In the Data Library, create time series drivers such as:

* `Number of Regular Givers`.
* `Average Monthly Gift - Regular Givers`.
* `Number of One Off Donors per Campaign`.
* `Average One Off Gift`.
* `Number of Members` and `Average Membership Fee`.
* `Event Attendees` and `Average Ticket Price`.

Where relevant, also define behavioural drivers:

* `Retention Rate - Regular Givers`.
* `Upgrade Rate - Regular Givers`.
* `Acquisition Rate` or new donor counts.
* `Churn Rate - Members`.

You can implement these as direct level drivers (counts and amounts per period) or as transition drivers that change the counts over time.
{% endstep %}

{% step %}

### Step 3: Build revenue variables per stream

For each segment, create Revenue type variables, for example:

* Revenue - Regular Giving.
* Revenue - One Off Giving.
* Revenue - Major Donors.
* Revenue - Membership Fees.
* Revenue - Events.
* Revenue - Course Fees.

Define formulas such as:

* Revenue - Regular Giving\
  \= Number of Regular Givers × Average Monthly Gift × 12 for annual models, or times the number of periods in each period.
* Revenue - Membership Fees\
  \= Number of Members × Average Membership Fee per Period.

For events and campaigns, you can model:

* Number of events.
* Average attendees per event.
* Average revenue per attendee.

These variables will flow into P\&L and cash once timing is configured.
{% endstep %}

{% step %}

### Step 4: Apply timing and payment methods

For each revenue variable, define timing rules that reflect how cash arrives, for example:

* Regular giving debits at the start or end of each month.
* Online donations cleared within a few days.
* Direct debit batches with a small delay.
* Event ticket sales occurring ahead of the event date.
* Course fees collected up front or per term.

Set delays or schedules so that:

* Revenue is recognised when earned in P\&L.
* Receivables or deferred income appear on the Balance Sheet where appropriate.
* Cashflow and Cash Waterfall reflect actual inflows.

This allows you to see the impact of revenue seasonality and the lag between campaign activity and cash received.
{% endstep %}

{% step %}

### Step 5: Map revenue streams to programs and purposes

To understand how revenue supports program activity:

* Use branches to link revenue streams directly to programs where restricted.
* Represent unrestricted or general funds in a central branch and allocate them conceptually to programs in reporting views.
* Tag revenue variables with program or purpose where a single stream supports multiple areas.

Custom reports and dashboards can then show:

* Income by source per program.
* Share of restricted versus unrestricted funding.
* Dependence on particular donor types or channels.

This supports risk assessment and communication with funders and boards.
{% endstep %}

{% step %}

### Step 6: Use scenarios for campaigns and behaviour changes

Clone the base model into scenario models to explore situations such as:

* Increased investment in acquisition campaigns.
* Changes in retention or upgrade rates.
* Loss of a major donor or partner.
* Introduction of new revenue products, memberships or events.
* Macro shocks that reduce giving or course enrolments.

In each scenario, adjust:

* Donor and member counts.
* Behavioural drivers (retention, upgrade, churn).
* Average gift or spend per donor, member or customer.
* Campaign volumes and cost where linked to program or fundraising costs.

Compare scenarios using:

* Total income by stream and in aggregate.
* Volatility and concentration of income.
* Cash runway and reserves.
* Ability to fund program portfolios over time.
  {% endstep %}
  {% endstepper %}

{% hint style="info" %}

### Check your work

* Donor, member and customer counts reflect recent history when the model is calibrated.
* Average gift and behavioural assumptions are realistic, based on internal data or benchmarks.
* Revenue timing assumptions match actual payment patterns.
* The model is segmented enough to be useful but not so granular that it is hard to maintain.
  {% endhint %}

## Troubleshooting

<details>

<summary>Income appears too smooth compared with history</summary>

Introduce seasonality or campaign effects and adjust timing so that peaks align with typical fundraising or enrolment periods.

</details>

<details>

<summary>Scenario results are hard to interpret</summary>

Focus on a limited number of key segments for scenario analysis and keep minor streams grouped for simplicity.

</details>

<details>

<summary>Dependence on a small number of donors is not obvious</summary>

Use dashboards that highlight concentration, such as top ten donor or partner contributions, even if these are modelled at aggregated levels.

</details>

## Related guides

* [Build an Equity Valuation Model (FCFE)](/how-tos/valuation/build-an-equity-valuation-model-fcfe.md)
* [Build an Executive Dashboard](/how-tos/dashboards-and-reporting/build-an-executive-dashboard.md)
* [FCFE Calculation](/help/financial-outputs-and-valuation/fcfe-calculation.md)
* [Subcategory Selection](/syntax/variables-syntax/subcategory-selection.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.modelreef.io/use-cases/not-for-profit-and-education/donor-revenue-stream-forecasting.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.