Nonprofit Cloud · promises and payments
The schedule promises the payments.
Something still has to create them.
A Gift Commitment is the promise, its Gift Commitment Schedule says how much and how often, and each Gift Transaction is one expected or received payment. For a monthly gift the platform plans the next payment on a timetable your admin sets; for an uneven pledge or a grant, somebody has to make sure every expected payment exists. Below: how the three records work together, what the platform does by itself, and what a UK charity build had to add so finance saw the right money on the right dates.
Reviewed 1 November 2026.
Three records
How do a Gift Commitment, its schedule and its transactions fit together?
As one chain. The Gift Commitment holds the promise and its total. The Gift Commitment Schedule holds the rule: amount per payment, frequency, start and end, or a pause. Each Gift Transaction is one payment with a due date and a status. Money still expected is the sum of payments not yet paid, so a missing transaction is missing money.
| Gift CommitmentThe promise: donor, total, schedule type (Recurring or Custom) and status | 1 per promise |
| Gift Commitment ScheduleThe rule: amount per payment, how often, start and end, or a pause. A change of dates ends one schedule and starts another | 1 or more |
| Gift TransactionOne payment, expected or received, with a due date and a status such as Pending, Unpaid or Paid | 1 per payment |
Salesforce’s Trailhead module on gift commitments calls the commitment the promise of a gift that is planned but not paid from the beginning. Add a Gift Commitment on Salesforce Help gives the two schedule types. Both read on 31 October 2026.
What the platform does
Does Nonprofit Cloud create the expected payments by itself?
For recurring gifts, partly. A scheduled flow works out the next instalment and creates its Gift Transaction only if the Create Recurring Schedule Transaction setting is on, and that flow runs on a schedule your admin sets up. Salesforce’s help describes no equivalent step for a Custom schedule, so plan to create those payments yourself.
From Gift Commitment Processing, Fundraising Flows and Manage Recurring Gift Commitments on Salesforce Help, read on 31 October 2026.
- 01
The processing flow runs only when somebody schedules it
Coordinate Gift Commitment Processing runs batch jobs that update commitments from their schedules and payments. Salesforce’s help says it runs on a schedule your admin sets up. Until it is set up, nothing moves: no next payment date, no new instalment, no change of status.
- 02
A recurring instalment is created only if a setting says so
For a recurring commitment the flow finds the next instalment and fills Next Transaction Date and Next Transaction Amount. It creates the Gift Transaction for that instalment only when the Create Recurring Schedule Transaction setting is selected.
- 03
Lapsed and Failing need a number above zero
A commitment becomes Lapsed when its consecutive unpaid payments reach the Lapsed Unpaid Transaction Count, and Failing when failed payments reach the Failing Transaction Count. With either setting at 0, that status never updates. Agree both numbers with finance before go live.
- 04
A pause deletes expected payments
Pause a schedule after it has started and the unpaid Gift Transactions due inside the pause period are removed. Any report of money expected drops by that amount on the day of the pause, which is correct, and which finance should hear about first.
Pledges and grants
Which schedule type fits a pledge or a grant?
Recurring, when the donor pays a set amount on a regular rhythm. Custom, when the promise is paid in one or more instalments that are not regular, which is how a pledge or a grant paid in parts is described. Salesforce’s custom schedule component takes up to 30 schedule records per commitment, so anything longer needs its own plan.
The limit of 30 is in Fundraising Lightning Web Components on Salesforce Help, read on 31 October 2026. How each payment is then divided across programmes is a separate question, answered in the designations article.
From a real build
Six things a UK charity build added.
From building fundraising on Nonprofit Cloud for a community charity in the east of England, 10 to 15 staff, funded by contracts, grants and giving. This charity records its gifts through its own screens rather than Gift Entry, and the whole build is in the charity case study.
- 01
Every expected payment created at the moment of award
One button records the promise, its schedule and its split across programmes in a single pass. The same flow then creates each payment as a Pending Gift Transaction with its own due date, one month apart from the start date. The commitment and its payments are saved first and the stage changes last, so an application never reads Awarded before its money records exist.
- 02
Rounding goes on the last payment
The amount is divided by the number of payments and rounded to the penny, and the last payment takes whatever is left. A promise of £1,000 over three payments becomes £333.33, £333.33 and £333.34, so the payments always add up to the promise. A check refuses to activate a commitment whose programme split falls short, and says how much is still to allocate.
- 03
The payment day is capped at 28
The schedule takes its payment day from the start date, capped at 28, so a promise that starts on the 31st still has a payment day in February.
- 04
Each payment is linked to its schedule
The lookup from a Gift Transaction to its Gift Commitment Schedule was empty on every payment the screen created. A before save flow now fills it: the latest schedule that started on or before the due date, or the earliest one if none has. Without that link the thank you letter could not say how often the donor gives, or tell a first regular payment from the rest.
- 05
The arithmetic is shown before anything is saved
The review screen states the total, the number of payments, the amount of each and the first and last due dates, and turns amber when the total does not divide evenly. The fundraiser sees the rounding before finance does, and goes back to change the figures if it looks wrong.
- 06
A migration links the records later, so the flows must notice
The historical load inserted every object on its own and joined them in later passes. A flow that fired only when a payment was created would never have linked those payments to their schedule or split them. Both flows now also fire when the commitment lookup changes, and a guard stops a second run from creating duplicates.
What makes it worse
Three surprises worth knowing before the first load.
- 01
A draft promise counts in the native totals
On this build a Draft commitment with a schedule still showed its full value in the native current year total. Every report on those totals filters on commitment status, or the forecast includes money nobody has promised.
- 02
Deleting a commitment takes its payments for good
When a commitment was deleted, its payments and schedule went with it. The commitment could be restored from the Recycle Bin; its payments and schedule could not, although a query still found them. Treat that delete as final.
- 03
The schedule has to match the commitment’s type
Load a Monthly schedule under a commitment of type Custom and the platform refuses it with “You can only create a custom schedule when the commitment schedule type is Custom”. Decide the type per promise before the load, not row by row.
Asked often enough to answer here
Questions
Closing is described in Close a Gift Commitment on Salesforce Help, read on 31 October 2026.
- Q
What happens to unpaid payments when a commitment is closed?
They change status. Salesforce's help says closing sets unpaid or failed transactions to Canceled when the Formal Commitment Type is Verbal, and to Written Off when it is Written. That field is not on the page by default, so add it to the commitment layout before anyone closes one.
- Q
Why does a promise nobody has signed show in our totals?
Because a Draft commitment with a schedule still feeds the native current year total, as this build found. Filter every report and dashboard on those totals by commitment status, or forecasts will include money nobody has promised.
- Q
Can we change the amount of a monthly gift without losing its history?
Yes. Upgrade and Downgrade change the amount, frequency or payment method from a chosen date, and a change of dates ends the original schedule the day before the new one starts. The user making the change needs delete permission on the gift transactions.
Promises and payments are part of Fundraising essentials: €4,550 for 70 hours on the ten licences Salesforce donates.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 1 November 2026.
Read next
The question that usually comes after this one.
- 01
Gift Transaction Designations Not Created
Why Nonprofit Cloud payments arrive with no programme split, how to find them with one query, and the flow pattern that writes the split onto every payment.
- 02
Gift Aid in Salesforce Nonprofit Cloud
Nonprofit Cloud has no Gift Aid built in. What HMRC requires as of 28 October 2026, how a claim reaches HMRC, app or build, and seven checks for your org.
- 03
Nonprofit Cloud Migration From Spreadsheets
Move a charity’s donations from spreadsheets into Nonprofit Cloud and prove three totals match your own workbook to the penny before anyone trusts a dashboard.