Charity CRM for UK Charities: Gift Aid, Consent and When Custom Makes Sense

A charity CRM records supporters, donations, Gift Aid declarations and marketing consent in one place, so a UK charity can claim 25p on every eligible £1 and prove who agreed to hear from it. Most charities should buy a charity-specific product; Beacon's Starter plan is £33.50 a month billed annually. Build custom only when your service delivery, not your fundraising, is what no product models.

This guide is for fundraising and operations leads at UK charities, and for founders building software for the sector. RAITHub has not shipped a charity CRM or any nonprofit product. Everything below is engineering guidance, drawn from payment, permission and audit work on other platforms, and labelled that way. Gift Aid and marketing rules are quoted from HMRC and the ICO, checked on 30 September 2026. This is general information, not tax or legal advice: confirm the current rule with your adviser, and use the linked regulator pages as the source of truth.

What does a UK charity CRM need to do that a generic CRM doesn't?

Four things: Gift Aid, fund accounting, charity-specific marketing rules, and supporters who are also volunteers, members or service users. A sales CRM can be bent to do some of it; the gaps show up at claim time and in a complaint.

Requirement	Sales CRM	Charity CRM
Gift Aid declarations linked to each donation	Custom fields, no audit trail	Built in, with claim files or HMRC submission
Restricted and unrestricted funds	Not modelled	Every gift carries a fund
Consent per channel, with source and date	Usually one "opted in" flag	Per channel, with history
Direct Debit and recurring gifts	Invoices and subscriptions for customers	Regular gifts, with mandate status and lapse reporting
Donor benefits: event tickets, membership perks	Not tracked against the gift	Recorded, because they affect Gift Aid
Volunteers, members, beneficiaries	Contacts with tags	Often modules, sometimes a separate system

How does Gift Aid work, and what must the CRM record?

HMRC says a charity can claim back 25p every time an individual donates £1, provided the donor has made a Gift Aid declaration and has paid at least as much Income Tax or Capital Gains Tax in that tax year as the charity wants to claim (GOV.UK: claim Gift Aid). The software's job is to hold valid declarations, link each donation to one, and produce claims without double-claiming.

A declaration must include, according to HMRC's declaration guidance:

• the name of the charity
• the donor's full name and home address
• whether it covers past, present or future donations, or just a single donation
• a statement that the donor wants Gift Aid to apply
• an explanation that the donor must pay at least as much UK Income Tax and/or Capital Gains Tax as all charities and CASCs will claim on their gifts in a tax year

Four further rules shape the data model:

Rule, as HMRC states it	What the CRM must do
Oral declarations are allowed, but you must send written confirmation with the same information, telling the donor they can cancel within 30 days of that confirmation (HMRC)	Record the method, when confirmation was sent, and any cancellation in that window
A charity must keep records that show "a clear link between an individual's donation and the Gift Aid declaration", called an audit trail (HMRC Chapter 3, 3.6.5)	Every claimed donation points at the declaration it relied on
A charitable company must keep Gift Aid declarations and records until 6 years after the end of the accounting period they relate to; trusts have a slightly different rule (HMRC Chapter 3, 3.30)	No hard deletion of declarations or claim lines inside the retention period; declarations covering ongoing gifts stay while they are relied on
Claims must be made within 4 years of the end of the financial period the donation was received in; claims of over 1,000 donations must use software rather than a spreadsheet (GOV.UK: how to claim)	Warn before gifts age out of the window; know your financial year end

Donor benefits add one more check. HMRC's detailed guidance limits the value of benefits a donor can receive in return, starting at 25% of the donation for gifts up to £100, with an aggregate cap of £2,500 per donor per tax year (HMRC Chapter 3, 3.20 to 3.22). A gala ticket or a membership perk has to be recorded against the gift, and the calculation checked against the full rules, before the gift is claimed.

What does a Gift Aid declaration data model look like?

Keep the declaration as its own record, snapshot the name and address the donor gave, record how it was made and which wording they saw, and make each claim line point at both the donation and the declaration. A minimal PostgreSQL sketch written for this post:

CREATE TABLE gift_aid_declaration (
  id                    uuid PRIMARY KEY,
  supporter_id          uuid NOT NULL REFERENCES supporter(id),
  full_name             text NOT NULL,          -- as declared, not as later edited
  home_address          text NOT NULL,
  postcode              text,
  scope                 text NOT NULL CHECK (scope IN ('single', 'past_present_future')),
  single_donation_id    uuid REFERENCES donation(id),
  covers_from           date,                   -- earliest gift covered; check HMRC's limit
  method                text NOT NULL CHECK (method IN ('online', 'paper', 'oral')),
  wording_version       text NOT NULL,          -- the exact statement the donor saw or heard
  made_at               timestamptz NOT NULL,
  confirmation_sent_at  timestamptz,            -- written confirmation, for oral declarations
  cancelled_at          timestamptz,
  CHECK (scope <> 'single' OR single_donation_id IS NOT NULL)
);

CREATE TABLE gift_aid_claim (
  id            uuid PRIMARY KEY,
  submitted_at  timestamptz,
  status        text NOT NULL CHECK (status IN ('draft', 'submitted', 'paid', 'rejected'))
);

CREATE TABLE gift_aid_claim_line (
  claim_id        uuid NOT NULL REFERENCES gift_aid_claim(id),
  donation_id     uuid NOT NULL UNIQUE REFERENCES donation(id),   -- a gift is claimed once
  declaration_id  uuid NOT NULL REFERENCES gift_aid_declaration(id), -- the audit trail
  amount_pence    bigint NOT NULL CHECK (amount_pence > 0)
);

The eligibility check belongs in one function that every claim run calls. This TypeScript version is deliberately conservative: it refuses anything it cannot prove, and sends donor-benefit cases to a person.

type Declaration = {
  id: string
  scope: 'single' | 'past_present_future'
  singleDonationId?: string
  coversFrom?: Date
  method: 'online' | 'paper' | 'oral'
  confirmationSentAt?: Date
  cancelledAt?: Date
}

type Donation = {
  id: string
  byIndividual: boolean
  receivedAt: Date
  financialPeriodEnd: Date   // end of the charity's financial period it was received in
  benefitValuePence: number
  alreadyClaimed: boolean
}

const DAY = 86_400_000

export function giftAidCheck(d: Donation, decls: Declaration[], now: Date):
  { ok: true; declarationId: string } | { ok: false; reason: string } {
  if (!d.byIndividual) return { ok: false, reason: 'not from an individual' }
  if (d.alreadyClaimed) return { ok: false, reason: 'already claimed' }
  if (d.benefitValuePence > 0) return { ok: false, reason: 'donor benefit: review by hand' }

  const deadline = new Date(d.financialPeriodEnd)
  deadline.setUTCFullYear(deadline.getUTCFullYear() + 4)
  if (now > deadline) return { ok: false, reason: 'outside the 4-year claim window' }

  const match = decls.find((x) => {
    const covers = x.scope === 'single'
      ? x.singleDonationId === d.id
      : !x.coversFrom || d.receivedAt >= x.coversFrom
    if (!covers) return false
    if (x.cancelledAt && x.cancelledAt <= d.receivedAt) return false
    if (x.method === 'oral') {
      // Needs written confirmation, and the 30-day cancellation window must have closed.
      if (!x.confirmationSentAt) return false
      const windowEnd = x.confirmationSentAt.getTime() + 30 * DAY
      if (now.getTime() < windowEnd) return false
      if (x.cancelledAt && x.cancelledAt.getTime() <= windowEnd) return false
    }
    return true
  })
  return match ? { ok: true, declarationId: match.id } : { ok: false, reason: 'no valid declaration' }
}

This is an illustration, not a rules engine. How far back a declaration may reach, how a cancellation affects earlier gifts, and how benefits are valued all come from HMRC's guidance; have your adviser confirm the rules, then turn each one into a test case. The test suite is the real specification.

How are Gift Aid claims submitted from a charity CRM?

HMRC says you can claim through Charities Online "with eligible software, like a database" or with "a spreadsheet of your donations", that claims of over 1,000 donations must use software, and that payment should arrive within 5 weeks of an online claim (GOV.UK: how to claim, GOV.UK: claim Gift Aid). HMRC links a list of eligible commercial software suppliers from the same page. For a custom system, that leaves two practical routes: generate HMRC's spreadsheet for smaller claims, or hand claims to eligible software. Building direct submission yourself means working to HMRC's own technical requirements; treat that as a separate project, and check HMRC's current guidance before you scope it.

How should a charity CRM record marketing consent under UK GDPR and PECR?

Record consent per channel, with the date, the source, the wording shown and the lawful basis you rely on, and keep the history rather than overwriting a flag. PECR (the Privacy and Electronic Communications Regulations) sets the rules for electronic marketing; UK GDPR governs the personal data behind it.

One change matters for every charity database. The ICO says a charitable purposes soft opt-in, introduced by the Data (Use and Access) Act 2025, commenced on 5 February 2026. Under it, only charities may send electronic mail marketing without prior consent where they obtained the contact details directly from the person, the person expressed interest in or offered support for the charity's purposes, the sole purpose of the marketing is to further those purposes, and the person was given a simple way to opt out at collection and in every message. It may only be used for contact details obtained on or after 5 February 2026 (ICO: electronic mail marketing rules).

What to store	Why
Channel: email, SMS, phone, post	The rules differ by channel; an email opt-out is not a postal one
Basis: consent, or charitable purposes soft opt-in	You must be able to say which rule you relied on
Collected at, and collected how	The soft opt-in depends on the details being collected directly, on or after 5 February 2026
Wording and opt-out offered at collection	Proves the person had a simple way to refuse
Opt-outs, with date and channel	Every later message must offer one, and every system must honour it

Phone and postal marketing follow different rules; check the ICO's direct marketing guidance for each channel you use. The engineering rule is simpler: a supporter's opt-out must reach every system that can message them, including your email tool, within the same day.

How do Direct Debit and recurring gifts fit in?

Treat a regular gift as a mandate plus a schedule, and record each payment only when the payment provider confirms it. With Stripe's Bacs Direct Debit, for example, the documentation says confirmation typically takes 4 business days with an existing mandate and up to 7 when collecting a new one, Bacs requires the payer to be notified when details are collected and each time they are debited (Stripe sends these emails by default), and customers can dispute a Bacs payment through their bank with no set time limit (Stripe: Bacs Direct Debit).

That last point matters for Gift Aid. A gift claimed and then reversed by the bank has to be corrected in the next claim, so the CRM should listen for disputes as well as payments. Beacon, for instance, lists Stripe, GoCardless and PayPal as payment processors it works with (Beacon pricing). The Stripe billing guide covers subscriptions, and the payments and webhooks testing guide shows how to rehearse failures and disputes before a real supporter meets them.

What do UK charity CRMs cost?

Charity CRMs in the UK are mostly priced by the number of contacts or supporters you hold. The figures below are what each vendor's pricing page said when checked on 30 September 2026. It is not a ranking, and other products exist.

Product	What the pricing page says	Gift Aid
Beacon	Starter £33.50 a month billed annually (£37 monthly) for 500 to 2,000 contacts and 3 users; Standard £114; Premium £292; Ultimate by quote	"Gift Aid processing does not incur any fees"
Donorfy	Starter, Professional and Enterprise; "pricing is based on your supporter count", banded on the month's peak; 2% off for annual billing	"The Gift Aid HMRC integration is included" in all three editions
Salesforce Nonprofit Cloud	Eligible nonprofits receive 10 Nonprofit Cloud Core licences at no cost through Power of Us; paid editions listed from $70 per user a month billed annually on the US page	Configured per organisation; check with Salesforce or a partner

Sources: Beacon pricing, Donorfy pricing and Salesforce Nonprofit Cloud pricing. Salesforce's free licences are real, but a configurable platform needs someone who knows it; budget for that before you accept them. Whatever you choose, ask each vendor how it records declarations, oral confirmations and consent history, using the tables above as your checklist.

When does a custom charity CRM make sense?

Rarely for fundraising alone, and more often when fundraising data has to live alongside services no product models. The honest split:

Your situation	Usually the right move	Why
A small or mid-sized charity raising money from individuals, with Gift Aid and Direct Debits	Buy	Charity CRMs already do Gift Aid claims and consent; a custom version repeats years of their work
A good CRM, plus a service you deliver: casework, bookings, a helpline, a grants programme	Buy the CRM, build the service system, sync the two	Keep Gift Aid in a product built for it; build only what is yours
Supporters, members, event attendees and shop customers in four disconnected tools	Integrate first	A clean sync through each tool's API is cheaper than a replacement
A federation of local branches with shared supporters and separate funds	Buy a configurable platform, or build	Branch-level permissions and funds are where standard products strain
You run a giving platform for many charities	Build	The software is the product, and multi-charity Gift Aid and consent become your responsibility

If you are considering a no-code build for any of this, the no-code vs custom development guide sets out where that approach stops working. Records that underpin tax claims are a poor fit for a tool you cannot test.

What should a charity ask any software supplier about data protection?

Where the data is hosted, who can reach it, how you get it back, and what the contract says. These questions apply to a SaaS vendor and to a development agency alike:

1. Hosting region and sub-processors. Where does supporter data live, and which other companies process it?
2. Contract. Will they sign a data processing agreement, and, for transfers outside the UK, the transfer terms your adviser requires?
3. Access. Who at the supplier can see supporter records, and is that access logged? The audit log design guide covers what a useful log records.
4. Roles. Can a volunteer enter donations without seeing major-donor notes or safeguarding records? The RBAC design guide shows how to specify that.
5. Exit. Can you export every supporter, gift, declaration and consent record in a format you can open without them?

A supplier without certifications can still answer these well; the security questionnaire guide shows what good answers look like.

How does working with a Dhaka team fit UK charity hours?

RAITHub works from Dhaka, UTC+6, with no daylight saving. On a 9:00 to 18:00 day at both ends, UK teams get about 3 hours of overlap in winter and 4 in summer, in the UK morning. The working week is agreed per client, and everything outside the overlap runs on written daily handoffs, which suits charity teams where the person who approves a change may only be free after work.

Why RAITHub for this

• Money and audit trails, tested. PropDesk, a property platform RAITHub built, collects recurring rent with Stripe and has 1,024 automated tests. Recurring gifts, reversals and claim lines need the same discipline. RAITHub has not built a charity CRM; Gift Aid logic would be new work, specified with your adviser and quoted as such.
• Detailed permissions. Sundor Skin has 88 permission codes, 12 staff roles and 146 PostgreSQL tables with row-level security, the level of control that keeps casework, safeguarding notes and fundraising data apart.
• Integration first. Most charities need a service system that syncs with the CRM they already pay for. See API and backend development for what that work involves.
• Clear terms. A free 15-minute technical audit, then a fixed written quote, fixed scope or a dedicated monthly team. You own the IP, and an NDA is standard. RAITHub is not SOC 2 or ISO 27001 certified; it signs DPAs and SCCs and follows your controls.

When you don't need us

• You fundraise from individuals and claim Gift Aid. Buy a charity CRM. It already does the hard part, and its vendor keeps up with HMRC.
• Your CRM works but is badly set up. You need a consultant for that product, not new software.
• You need advice on Gift Aid, charity law or PECR. Ask an accountant or adviser; RAITHub builds the rules they give you into software.
• You need a native iOS or Android app. RAITHub builds web apps and PWAs only.
• You want a developer placed in your team by the hour. RAITHub does not offer staff augmentation.

If a custom donation form or supporter database is losing gifts or duplicating supporters, start with a fix rather than a rebuild. For a first cost range on a service system, try the MVP cost estimator.

Sources checked on 30 September 2026. Gift Aid, PECR and UK GDPR points are general information only; confirm the current rule with your adviser and the linked HMRC and ICO guidance.

If your charity needs a service system that talks to its CRM, or you are building a giving platform, book the free 15-minute technical audit. Bring your current CRM, your supporter count and the workflow no product handles.

Frequently asked questions

What is a charity CRM?

A charity CRM is a supporter database built for charities. It records supporters, donations, funds, Gift Aid declarations, Direct Debits and marketing consent, and produces Gift Aid claims and fundraising reports, which general sales CRMs do not handle without heavy customisation.

What does a Gift Aid declaration need to include?

HMRC says it must include the charity's name, the donor's full name and home address, whether it covers past, present or future donations or a single one, a statement that the donor wants Gift Aid to apply, and an explanation of the tax the donor must have paid.

How long do charities have to claim Gift Aid?

HMRC says you need to claim for a donation within 4 years of the end of the financial period you received it in. Claims of over 1,000 donations must be made with software rather than a spreadsheet. Confirm the current rules on GOV.UK.

Can UK charities email supporters without consent?

Since 5 February 2026, the ICO says charities can use a charitable purposes soft opt-in for electronic mail marketing, if they collected the details directly from a supporter or interested person on or after that date, offered a simple opt-out then, and offer one in every message.

Should a UK charity build its own CRM?

Usually not. Charity CRMs such as Beacon, from £33.50 a month billed annually, already handle Gift Aid and consent. Custom software makes sense for service delivery systems that sync with the CRM, federated charities with unusual structures, or companies building a giving platform.

Has RAITHub built a charity CRM?

No. RAITHub has not shipped a nonprofit product. It has built Stripe recurring payments in PropDesk, with 1,024 tests, and detailed permissions in Sundor Skin. For charities, it offers engineering guidance, integrations and custom builds quoted as new work.