A pledge tells you what’s promised. A gift tells you what arrived.

Track a nonprofit pledge as one donor commitment, then record every payment that actually arrives as a separate linked gift. Keep promised, received, and remaining amounts in different views so your team can follow the commitment without counting the same money twice.

The rule is simple: the pledge records intent; the payment record proves receipt.

Build two linked records

A useful pledge workflow starts with a commitment record. It should answer what the donor promised and how your team expects that promise to be fulfilled:

• donor or organization;
• commitment date and total amount;
• expected schedule or target date;
• campaign, fund, or designation supplied with the pledge;
• source document or conversation note;
• staff owner and current status.

That record is not a substitute for a gift. When money arrives, create a payment record with the received date, amount, payment method, final status, and source identifier, then link it to the commitment.

Current fundraising systems use this same boundary in different ways. Microsoft's donor-commitment guide links partial or full transactions to an existing commitment. Blackbaud's pledge guidance says each pledge payment received gets its own payment record, whether the donor pays once or in installments.

Use the controls your system provides. The important test is whether a staff member can open the commitment, see every linked payment, and explain the remaining amount without editing a received gift.

Record four events instead of rewriting history

A pledge changes over time. The donor may move a date, change the amount, pay early, combine installments, or end the commitment. Do not make the current record look as though the first agreement never existed.

Keep a short event log:

1. Created: original amount, schedule, date, source, and staff owner.
2. Revised: old value, new value, effective date, reason supplied, and operator.
3. Payment linked: gift ID, received amount, received date, and remaining amount after the link.
4. Closed: outcome, closure date, final received total, remaining amount, and approving owner.

This is a fundraising audit trail, not an accounting policy. Your finance lead or qualified adviser should decide how a pledge affects the books. The fundraising record's job is narrower: preserve what the donor said, what arrived, and what your team changed.

Keep three numbers in separate views

Every pledge needs three clearly labeled numbers:

• Promised: the current agreed commitment.
• Received: the sum of completed payments linked to that commitment.
• Remaining: promised minus received, adjusted only through a documented revision or closure.

Suppose a donor pledges $1,200 in four quarterly payments. The first $300 arrives and succeeds. The commitment view shows $1,200 promised, $300 received, and $900 remaining. The gift report shows one $300 received gift. It does not show $1,500 by adding the pledge and payment together.

QuickBooks' current nonprofit guide exposes the same sequence in product-specific terms: record a pledge before the donation arrives, then use a separate receive-payment action when it does.

Name these views precisely in dashboards and exports. A board forecast may need commitments. A cash report needs completed gifts. A follow-up queue needs remaining amounts and due dates. One unlabeled “total raised” number cannot safely do all three jobs.

Hold uncertain payments in an exception queue

Never force a payment onto a pledge because the amount looks familiar. A $250 check might fulfill an installment, represent a new gift, or belong to a different member of the same household.

Hold the payment when any of these facts conflict:

• donor identity;
• amount or expected date;
• campaign, fund, or designation;
• payment memo or accompanying note;
• external transaction, check, or import identifier.

The exception needs one owner and one next action: confirm with the source evidence, ask the donor through an approved contact path, or leave the gift unlinked while the investigation continues. The broader gift-processing intake packet can carry that evidence without creating a second shadow log.

Once the match is supported, link the existing received gift to the commitment. Do not delete and recreate a valid payment merely to make the pledge screen tidy.

Close the commitment with an explicit outcome

A pledge should not remain open forever because nobody wants to choose a status. Close it with one observable outcome:

• fulfilled: completed linked payments equal the current commitment;
• revised and replaced: a new documented commitment supersedes the old schedule or amount;
• ended by donor: the donor clearly changed or ended the commitment;
• closed before full payment: your approved policy owner decided no fundraising follow-up remains.

Record the decision without inventing an accounting label. “Closed before full payment” describes the fundraising workflow; it does not decide whether finance calls the balance a write-off, modification, receivable adjustment, or something else.

Close the communication work too. A pledge acknowledgment can thank the donor for the commitment, while each received payment follows your approved gift-receipt process. A donation receipt and a thank-you note do different jobs explains why one message should not quietly stand in for every operational purpose.

Before the monthly review ends, test one commitment from source note to linked payment to bank reconciliation. The pledge view should explain the promise, the gift record should explain the money, and the donation-to-deposit chain should start only with what was actually received.