Nonprofits and Charities

Prove the work without rebuilding it.

Reporting, receipting and donor admin are done by people rebuilding the same information every quarter. We move the assembling into a system that cites the record behind every figure, and leave everything a funder or a donor sees with a person.

  • Funder and grant reporting
  • Donor records and receipting
  • Delivery captured as evidence
  • What goes out stays human

The work is done. Proving it is what takes the fortnight

Every one of these is work somebody on a small team is already doing, in a way that leaves too little behind to be reused. Six patterns turn up in almost every nonprofit we map.

The donor record is a spreadsheet and three inboxes

One list for the mailing, another for the event, a third the fundraiser keeps, and the bank statement that is the only place some gifts appear at all. Nobody can answer how many donors gave twice without opening four files.

A retention question nobody can answer, on the one number that decides next year.

Receipting is a regulated duty done by hand

An official donation receipt is a legal document with mandatory contents, whether the regulator is the CRA or the IRS. Getting one wrong is a compliance exposure, and getting four hundred right is one person's December.

A regulated obligation whose accuracy depends on how tired one person was.

Funder reports get reconstructed rather than assembled

The quarter closes and somebody opens the agreement, then the attendance sheets, then the finance export, then a folder of photographs, and rebuilds from those four things a report the organization could have been holding all along.

A fortnight per report, spent proving work that was already done.

Nobody sees a donor leaving until they have left

The Fundraising Effectiveness Project put overall donor retention at 43.3 percent in 2025, while total dollars raised grew about 5 percent and the number of donors fell. Revenue is concentrating in fewer people, which makes knowing who they are worth more than it has ever been.

More money from fewer donors, and no early sight of the ones going quiet.

Delivery is recorded for staff, not for evidence

The sign-in sheet says who came. The funder asks what changed, for whom, against what baseline. Both are records of the same session, and only one of them was ever collected.

Outcomes you achieved and cannot evidence.

The system is one person and their memory

One coordinator knows which funder wants what by when, which donors expect a call rather than an email, and where the 2023 evidence went. That knowledge is real, it works, and it is not written down anywhere.

An organization one resignation away from starting over.

Give the system the assembling and keep everything that leaves the building

Controlled delegation is the whole design, and everything below this band applies it. Reading, matching and drafting go to the system. What a funder, a donor or a regulator sees goes out under a person, every time.

  • 01

    The same obligations come round again

    Receipts, acknowledgements, quarterly reports, funder claims, board packs, volunteer hours and the annual return. The same shapes on the same cycle, each one measured against a document somebody already signed.

  • 02

    The system assembles the evidence

    It reads the agreement, pulls the delivery and finance records, matches each requirement to the record that supports it, and names the ones with nothing behind them. It does not write an outcome no record supports.

  • 03

    A person decides what leaves the organization

    Anything a funder, a donor or a regulator sees goes out under a named person. That is the whole line, and it is the same line on every one of these pages.

See it run

A reporting period closes and the report assembles itself

Delivery records, participant outcomes, approved budget and actual spend get pulled together against what the funding agreement actually asks for. Gaps get named rather than filled.

Funder Reporting
  1. Input
  2. Context
  3. AI work
  4. Action
  5. Approval
  6. Recorded

Connected systems

  • Program CRM Delivery and participants updated
  • Finance Budget and actual spend updated
  • Participant records Outcomes and attendance updated
  • Documents Evidence and templates updated
  • Funder rules Agreement requirements updated
  • Reporting Submission pack updated

Reporting period Pathways to Work, Q2 Skills and employment grant

  1. Period closed Q2 report due in 14 days
  2. 12 requirements read From the funding agreement, clause by clause
  3. Delivery pulled 38 sessions, 4 delivery partners
  4. 214 participants matched Enrolment, attendance, exit status
  5. Budget and spend pulled Approved lines against actuals
  6. Evidence mapped to requirements 12 requirements, each to its source record
  7. Outcomes counted from records 96 into work, 41 into further training
  8. Variance calculated Spend at 94% of the approved budget
  9. 11 of 12 requirements evidenced One evidence gap named, not filled
  10. Report drafted On the funder template, every figure cited
  11. Program record updated Period marked reported, sources linked
  12. Submission pack assembled Report, evidence index, finance summary
  13. Held for the program manager Nothing goes to a funder unreviewed
  14. Run recorded Every figure traced to the record it came from

Result

Q2 report drafted Eleven requirements evidenced. One gap named for a person to close.
  • Requirements 12
  • Evidenced 11
  • Evidence gaps 1
  • Participants 214
  • Spend against budget 94%
  • Figures invented None

Completed automatically

  • Delivery and outcomes assembled
  • Budget variance calculated
  • Report drafted on the funder template
  • Evidence index built
  • Program record updated
  • Review task created

Requires a person

The evidence gap, and whether this goes to the funder.

Program manager

Review and submitClose the gap firstSend back
View audit trail
  • 08:02 Period closed. 12 requirements read from the agreement, version 3.
  • 08:03 214 participant records matched. 38 delivery sessions attached.
  • 08:04 Requirement 9 unevidenced. Reason: no exit survey on file for 18 participants.
  • 08:04 Budget variance calculated from finance actuals as at period close.
  • 08:05 Held for the program manager. Nothing submitted.
6 actions completed 3 systems updated 2 exceptions 1 approval

This demo uses fictional data. The workflow gets configured around your systems. Build a workflow like this

Four workflows, and the order they usually go in

Funder reporting usually goes first because it is the obligation with a deadline and a consequence attached. Each card names what the system handles and where a person stays in control.

Operations

Funder and grant reporting

The report assembled from records rather than rebuilt from memory

Reads the funding agreement, pulls delivery, participants and spend, maps each requirement to the record that evidences it, calculates variance against the approved budget, and drafts the report on the funder template with every figure cited. Gaps get named. Nothing gets estimated to cover one.

  • Built against your agreement the clauses and schedules you signed, not a generic template
  • Every figure traced to a record so a funder question is a retrieval, not a reconstruction
  • Gaps named, never filled an unevidenced outcome is a collection problem and gets treated as one
How a workflow gets built

Data: your delivery, participant and finance records. Human: a program manager reviews before anything reaches a funder.

Revenue

The donor record and the receipt

One record per donor, and receipting that holds up

Gifts from every channel land on one donor record: the form, the event, the bank feed, the cheque somebody entered by hand. Receipting runs off that record against the rules your regulator sets, and the acknowledgement goes out as a draft rather than as a send.

  • One donor, one record across channels, households and organizations, with duplicates surfaced not merged silently
  • Receipting built to the rule the mandatory contents your regulator requires, applied the same way every time
  • Acknowledgements drafted, not sent a first gift and a fifteenth are different letters and a person should choose
How the record gets built

Data: your donations, donors and receipts. Human: finance signs the receipting run, fundraising signs the letters.

Operations

Delivery captured as evidence

Recorded once, in a form a funder will accept

Attendance, activity, referrals and outcomes captured at the point of delivery in a shape that satisfies the reporting requirement, so the record is made once by the person who was there rather than twice by somebody who was not.

  • Capture that fits the work a phone in a community hall, not a form designed for a desk
  • Consent and baseline handled at capture because retrofitting either one is usually impossible
  • One record, several reporting formats the same delivery satisfying three funders who ask differently
How a workflow gets built

Data: your program and participant records. Human: delivery staff confirm what the record says happened.

Insight, later

Retention and giving patterns while they can still change

The donor going quiet, found in month four rather than at the appeal

Lapsing patterns, second-gift conversion, channel by channel retention, and the difference between a donor who gave less and a donor who stopped. Visible during the year, which is the only time any of it can still be acted on.

  • Second gift tracked separately first-time retention is the number that moves everything else
  • Lapsing surfaced early with the giving history that explains it attached
  • Restricted and unrestricted split because the two are different organizations financially
How the data layer gets built

Data: your own giving records. Human: fundraising decides who gets a call and what it says.

Six decisions taken before anything is built

These get agreed with the executive director, whoever owns finance and whoever answers to the board. Between them they decide what the workflow is allowed to be, and the first one is not negotiable.

What reaches a funder or a donor Kept human
Reports, claims, receipts, acknowledgements and appeals are drafted by the system and sent by a person. There is no volume at which this becomes automatic. A funder relationship and a donor relationship are both relationships, and neither survives an organization that let a system speak for it.
Participant data boundary
What the workflow may see, what stays masked, how long it is kept and under which regime. Nonprofits often hold information about people in difficulty, and that information carries duties a donor record does not.
Receipting accuracy
Which regulator, which mandatory contents, which fiscal year, and what happens to a receipt that has to be replaced. Receipting is the one workflow here with a statutory consequence attached, so it gets specified rather than assumed.
Evidence and consent
Which outcomes may be reported against which participants, and what consent was given at the point the record was made. An outcome that cannot be reported without breaching a consent is not an outcome you have.
Audit trail
What was pulled, which requirement it evidenced, which rule version applied, what was drafted, who reviewed it and what they changed. Built from the first workflow rather than added when a funder audit is announced.
Escalation path
What happens when a requirement is ambiguous, evidence is partial, or the agreement did not anticipate what actually happened in delivery. Every multi-year agreement has all three, and a workflow that resolves them quietly is making decisions the board should be making.

What counts as working. Accepted output against your own baseline is the proof. The first build is usually tested against reports your team already submitted, so you can see where the system and the team disagree before anything reaches a funder, and so a disagreement is a finding rather than an incident. How we measure AI work sets out the method.

One funder, proved against reports you already sent

The first build runs on one funding agreement and gets tested against reports your team completed, which is the only way to find out whether the requirements as written match the requirements as answered.

Map the work
Two to three weeks. Where the reporting, receipting and donor admin time actually goes, which obligations carry the most exposure, and the candidates scored by value and readiness. This is FusionMap.
Fix the record first
Two to four weeks, and usually unavoidable. A reporting workflow built on four donor lists reports four different numbers. This stage is worth doing on its own merits and several organizations have stopped here, which is a legitimate outcome.
Build one workflow
Four to six weeks. Usually funder reporting, on one funder rather than across the portfolio, tested against reports your team already submitted so you can see where the system and the team disagree.
Train and operate
Ongoing. Into use with staff trained to read what the system produces and to override it on the record, reviewed against the baseline, then the next funder.

Where this has already been built

The approach on this page comes out of these engagements. Two sit inside mission-led organizations and funded programs, and two are the design patterns the workflows above are built on.

Marketing operations for a safety association

A mission-led membership organization with a small team and a province to reach. We ran the whole marketing function and built AI into course creation, which is the closest thing we publish to the nonprofit problem: more output from the same people, without the quality dropping.

200% increase in award nominations 100%+ increase in survey response
Read the case study

A 3M EV charging grant program taken to market

Restricted funding with a deadline attached and an audience that had to be reached before it expired. Useful here because the constraint is the one every restricted grant carries: the money is only yours if you can evidence you spent it on what you said.

4.1M+ impressions across the program 80% budget efficiency against plan
Read the case study

A client profiling engine with the approval kept human

Fixed rules produce the classification so the same inputs always give the same answer, and every output waits in an approval queue before anybody sees it. Those are the same two design decisions the reporting workflow above is built on.

Under 5 min form to a review ready file 8 weeks concept to a deployed platform
Read the case study

A digital adoption plan accepted by a funding body

A plan written to a funder standard, assessed and accepted. What it shows is what a submission looks like when the evidence was assembled rather than reconstructed, which is the difference this page is about.

Every department mapped, not just the obvious ones Accepted by ISED as a funded plan
Read the case study

Begine Fusion is a Zoho Authorized Partner working across Canada, the United States, the United Kingdom and Nigeria, with a team on the ground in Nigeria since 2013. Every engagement is published in full, including what was measured and what was a design target. The full set is on our work.

Whether this is the right conversation yet

The work pays back when the reporting cycle is real, the donor base is big enough that individual memory has stopped working, and somebody can own the record. If that is not where you are, the right column says what to do instead.

This fits if

  • You report to at least one funder on a cycle, against an agreement with requirements in it
  • Preparing a report means opening four systems and a folder
  • Nobody can say how many donors gave twice last year without building a spreadsheet
  • Receipting is a manual run that one person owns and dreads
  • Somebody can own the donor record, because the workflows all stand on it

Start somewhere else if

  • You do not yet know where the admin time goes. Go to FusionMap and find out before commissioning a build.
  • You are pre-revenue or entirely volunteer run. Get the donor record into one place first. That is worth doing and it does not need us.
  • What the board actually wants is a written position on AI and participant data. That is FusionGuard.
  • You are looking for someone to write grant applications. We build the systems that evidence delivery. We do not write bids.

Start where the problem is

The same five offers every other client buys, scoped to an organization that has to evidence what it did with somebody else's money. Find the line that sounds like your week.

The admin is eating the week and nobody can say which part of it costs the most

FusionMap

The board wants a written position on where AI may be used with participant and donor data

FusionGuard

Donors, gifts, participants and grants live in four systems and a shared drive

Systems Build

One workflow is defined, agreed, and ready to be built properly

FusionBuild

The systems went in, they work, and nobody has looked after them since

Managed Operations

Your team has to supervise what a system produces, not just operate it

AI Systems Mastery

Asked on every call with a nonprofit

The seven that decide whether a build is worth starting, answered before the proposal rather than inside it.

We are four people. Is this not built for organizations much bigger than us?

The opposite. A large organization can absorb a fortnight of report preparation because it has the headcount to lose. A four person organization cannot, which is why the return is usually higher here. What changes at small scale is the sequencing: one workflow, on the obligation that costs the most, before anything else is touched.

Does the system write our funder reports?

It assembles them. It reads the agreement, pulls the records, maps evidence to requirements, calculates the variance and drafts the narrative on your funder template with every figure cited to its source. A program manager reads it, changes it and sends it. Where a requirement has no record behind it the system says so and leaves the field empty, because a number invented to fill a gap is the one thing that would end a funding relationship.

Our donor data is a mess. Do we have to fix that first?

Mostly yes, and it is better to hear that now than in month three. A reporting workflow built on four donor lists produces four different numbers, so the record gets consolidated before anything is built on top of it. That stage stands on its own: several organizations have done it and stopped there, and they were right to.

What about the Zoho nonprofit program?

Zoho offers a credit to registered nonprofits, and in Canada it is claimed directly rather than through TechSoup. It changes what the software costs and it does not change any of the work on this page, because the work is the record, the rules and the reporting rather than the licences. We have written up what the program covers and what it excludes.

Is there a donor management module we should be buying?

Zoho has no donor module, so donor management is built rather than bought, and the shape of what gets built is decided by your receipting rules more than by anything else. That is a real design decision with three viable answers, and it is worth understanding before you choose a platform rather than after.

How do we explain AI use to our board and our participants?

By being specific. What it reads, what it drafts, what it never sends, and who is accountable for every output. A written position is more useful than a policy statement, and it is what FusionGuard produces. Vague reassurance is what makes a board nervous, because a board can tell the difference.

How do we know it worked?

A baseline is taken before anything is built: hours per reporting cycle, receipting turnaround, the rework rate on submitted reports, and how often a funder comes back with a question. Afterwards the same work is measured against it, with the review time counted openly rather than left out.

Bring the report that took a fortnight and the donor list nobody trusts

Thirty minutes with whoever writes the funder reports, whoever owns finance and whoever answers to the board is enough to name the first workflow, the record it stands on, and the baseline it gets measured against.