Fundraising is where a nonprofit Salesforce implementation earns trust or loses it. If the year-end total is wrong, or a monthly donor lapses silently, or restricted money gets reported as unrestricted, no amount of good design elsewhere will save the project. This guide covers the fundraising decisions that actually determine whether your numbers hold up, using the Agentforce Nonprofit objects.

The one distinction that prevents double counting

Start here, because almost every fundraising reporting problem traces back to this.

  • A GiftCommitment is a promise. A pledge, a monthly recurring gift, a three year major gift commitment.
  • A GiftCommitmentSchedule describes how the promise gets fulfilled: amount, frequency, dates.
  • A GiftTransaction is money that arrived. One record per payment received.

A donor pledging 12,000 dollars over three years has one commitment, a schedule, and up to 36 transactions as payments come in. A one-off 50 dollar online gift has a single transaction and no commitment at all.

The trap. Build a report that sums commitments and transactions together and your revenue doubles. Build a dashboard on commitments only and you are reporting promises as income, which no auditor will accept. Decide explicitly, for every fundraising report, whether it measures cash received or commitments made, and put that word in the report name.

Practically, you need at least three named report groups from day one: cash received in a period, new commitments made in a period, and outstanding pledge balance at a point in time. Finance uses the first, the development director uses the second, and the third is what tells you which pledges have quietly stopped being paid.

Designations and restricted funds

A GiftDesignation is a fund or purpose. A gift is connected to designations through GiftTransactionDesignation, which is a junction, so one gift can be split across several funds.

The technical part is simple. The governance is where implementations fail.

  1. Give the list one owner, and make it finance. If development can create designations freely, you will have 200 within two years, including four spellings of the same program. Reporting then becomes guesswork.
  2. Model restriction explicitly. At minimum mark each designation unrestricted, temporarily restricted, or permanently restricted. Your audit needs it and it is not something to infer from a name.
  3. Set a default and mean it. Use GiftDefaultDesignation so gifts from a campaign, an opportunity, or a commitment land in the correct fund automatically. Manual allocation is how gifts end up unallocated.
  4. Decide the split rule. Percentage splits are convenient but produce rounding differences that finance will find. Fixed amounts reconcile cleanly. Pick one and apply it consistently.
  5. Never allow an unallocated gift. Make the designation required at entry, with a General Fund default. An unallocated gift is a reconciliation problem that gets harder to solve as memory fades.

If you are coming from NPSP, this replaces General Accounting Units and Allocations. The mapping is direct, which makes it a good early migration workstream. See the migration guide.

Recurring giving that survives a declined card

Monthly giving is usually the healthiest revenue a nonprofit has, and it is the most fragile part of the build, because it depends on a card that will eventually expire.

The structure: one GiftCommitment per donor arrangement, one GiftCommitmentSchedule defining amount and frequency, a GiftDefaultDesignation so generated gifts land in the right fund, and a GiftTransaction for each successful charge.

Design the failure path first

Most implementations design the happy path and treat failure as an exception. Reverse that. Failure is routine at scale.

  • Define what a failed payment creates. A failed transaction record, a task, an email to the donor, or all three. Decide it, do not let the payment processor decide silently.
  • Set a retry policy. How many attempts, how many days apart, and what happens after the last one.
  • Define lapsed. A specific rule, for example three consecutive failures or 60 days with no successful payment. Without a definition, lapsed donors sit in your active count and inflate your monthly revenue forecast.
  • Alert a human. Somebody must own the list of failing recurring gifts and work it weekly. This is the highest return per hour in most development shops, because a lapsed monthly donor is far cheaper to recover than a new one is to acquire.
  • Handle card expiry before it happens. Report on cards expiring in the next 60 days and contact those donors proactively.

Decide who owns the schedule

Both Salesforce and your payment processor can hold a recurring schedule. If both do, they drift, and you get double charges or missed months. Pick one system of record, write it down, and make the other one follow. This single decision prevents the worst class of recurring giving bug.

Upgrades and pauses

Donors change amounts and ask to pause. Decide whether an amount change edits the existing commitment or ends it and creates a new one. Editing keeps history simple but loses the record of what changed. In more recent API versions, GiftCmtChangeAttrLog records the history of commitment changes with attribution to the campaign or source code that drove them, which is worth using if upgrade attribution matters to you.

Soft credits without inflating revenue

A soft credit recognises influence without moving money. The board member who secured a corporate gift, the spouse in a joint household gift, a donor advised fund where the cheque comes from the sponsor but the donor should get credit.

Use GiftSoftCredit for these, and GiftDefaultSoftCredit to apply a standing soft credit to transactions generated from a recurring commitment.

Two rules keep you out of trouble:

  1. Soft credits never appear in revenue reports. Every financial total must be hard credit only. If soft credits reach the year-end figure, you report money you did not receive.
  2. Soft credits do appear in relationship reports. Fundraiser portfolios, board giving influence, and donor recognition lists should include them. That is what they are for.

Build both report sets separately and label them clearly. "Total raised" and "total influenced" are different numbers, and someone will eventually put them on the same slide unless the names stop them.

Tributes, matching gifts, and in-kind

Tributes. GiftTribute holds in-honour-of and in-memory-of details, including who should be notified. Do not store honouree names in a free text field on the gift. Notification is an operational commitment, so build the task or the acknowledgement flow at the same time as the field.

Matching gifts. A corporate match is a separate gift from the company, with the employee soft credited. Model it that way. Track the expected match as a commitment from the company if you want a forecast, and reconcile when the payment lands. Do not inflate the employee's hard credit with the employer's money.

In-kind gifts. Decide with finance whether these enter the same pipeline at fair market value or stay out of fundraising revenue entirely. Either is defensible. Mixing them in without a flag is not, because your cash reports stop being cash reports. If they come in, mark the payment method so every financial report can exclude them.

Gift entry your development team can run

GiftBatch and GiftEntry handle capture. Gifts are entered individually or in a batch, and after processing the entry records remain as an audit trail of what was keyed.

What makes gift entry actually work day to day:

  • Templates per source. Lockbox cheques, event revenue, and online gifts need different field sets. One generic screen makes every entry slower.
  • Batch totals that must balance. Enter the expected count and amount at the top of the batch and block processing until entry matches. This catches keying errors at the moment they happen instead of at month end.
  • Duplicate donor matching at entry. Surface likely existing constituents before creating a new one. Prevention is much cheaper than merging later.
  • No admin required. The development team must be able to run a batch end to end without opening a support ticket. If they cannot, they will go back to the spreadsheet.

Keep the entry records. When a gift is questioned two years later, knowing exactly what was keyed, by whom, and in which batch resolves it in minutes.

Payment processors and online giving

Salesforce is not a payment processor. You will connect one, and the choice of integration matters more than the choice of vendor.

What to require of any integration:

  • It creates Gift Transactions, not Opportunities or custom objects. An integration written for the NPSP data model will need rework.
  • It respects commitments. A recurring charge must attach to the existing GiftCommitment, not create a fresh standalone gift each month. Otherwise you lose the ability to see a monthly donor as one relationship.
  • It carries the designation. If a donor picks a fund on the form, that has to arrive with the gift.
  • It writes source codes. Use OutreachSourceCode and Campaign so you can attribute revenue to the appeal that produced it.
  • It fails loudly. Errors must create a visible record somebody owns. Silent failures in payment integrations are how organizations lose weeks of gifts. The pattern in our callout framework guide covers retries and logging.
  • It never stores card data in Salesforce. Tokens only, held on PaymentInstrument.

Also plan the accounting handoff. Finance needs gifts summarised by designation and date in a form their general ledger accepts. Agree the file or the integration format during design, not after go-live, because this is the request that always arrives late and blocks month end.

Rollups and the reports that matter

Donor totals come from Data Processing Engine definitions and standard summary objects such as DonorGiftSummary, which run in bulk on a schedule rather than instantly.

Split your figures by how fresh they must be:

  • Batch is fine: lifetime giving, largest gift, first and last gift date, consecutive years of giving, donor segments.
  • Must be live: anything a gift officer reads while a donor is on the phone, and anything an AI agent might quote to a donor. Use a formula field or calculate on demand.

The reports to build first, because these are the ones people ask for in month one:

  1. Cash received this period versus the same period last year.
  2. Revenue by designation, with restricted and unrestricted separated.
  3. New commitments made, and outstanding pledge balance.
  4. Active recurring donors, monthly value, and failures needing attention.
  5. LYBUNT and SYBUNT: donors who gave last year but not this, and some year but not this.
  6. Donor retention rate, year over year.

Retention: the number most orgs ignore

Most fundraising dashboards report money raised. Fewer report whether donors came back, which is the number that predicts next year.

Build retention properly and it changes behaviour:

  • Overall retention: donors who gave in both of the last two periods, divided by donors who gave in the earlier one.
  • First-year retention separately. New donors behave very differently from established ones, and blending them hides the problem.
  • Recurring versus one-time retention. This is usually the argument that wins investment in monthly giving.
  • Retention by acquisition source, so you can tell which appeals bring donors who stay rather than donors who give once.

Define the periods precisely, in writing, before you build. Fiscal or calendar year, and whether a soft credit counts as giving. Whatever you choose, apply it consistently so the trend line means something.

Implementation checklist

  1. Designation list agreed and owned by finance, with restriction type on every record.
  2. Commitment and transaction reporting separated, with the word cash or commitment in every report name.
  3. Recurring giving failure path built: retries, lapse definition, alerts, and an owner.
  4. One system of record for recurring schedules, documented.
  5. Soft credit reports built separately from revenue reports.
  6. Tribute notification process built, not just the field.
  7. Gift entry templates per source, with balancing batch totals.
  8. Payment integration writing Gift Transactions, attaching to commitments, carrying designation and source code, and logging failures.
  9. Accounting export agreed with finance.
  10. Retention reporting defined and built.

Frequently asked questions

How do I model a pledge in Agentforce Nonprofit?

As a GiftCommitment with a GiftCommitmentSchedule for the promise, and one GiftTransaction for each payment received against it. The commitment is the promise and the transactions are the cash. Reporting them added together doubles your revenue.

How do I stop soft credits inflating our total raised?

Build two separate report sets and name them clearly. Financial reports use hard credit only, from GiftTransaction records. Relationship and portfolio reports include GiftSoftCredit records. Never combine them in one revenue figure.

What should happen when a monthly donor card is declined?

A defined retry policy, a visible record, and a human owner. Decide how many retries and how far apart, define what counts as lapsed, for example three consecutive failures, and give someone the weekly job of working the failure list. Recovering a lapsing monthly donor is far cheaper than acquiring a new one.

Should Salesforce or the payment processor own the recurring schedule?

One of them, decided explicitly and documented. If both hold a schedule they drift out of sync, which produces double charges or missed months. Whichever you choose, the other system follows it.

How do I handle restricted funds?

Use GiftDesignation records with an explicit restriction type of unrestricted, temporarily restricted, or permanently restricted, and connect gifts through GiftTransactionDesignation. Set defaults with GiftDefaultDesignation, make designation required at entry, and give finance ownership of the designation list.

How are corporate matching gifts recorded?

As a separate gift from the company, with the employee soft credited. Do not add the employer money to the employee hard credit total. If you want a forecast of expected matches, record them as commitments from the company and reconcile when payment arrives.