A pledge is not a payment: commitment vs. transaction explained

A pledge is a promise to give a set amount, usually over time. A payment is the money arriving against that promise. They are two different things, and the moment your data treats them as one, your numbers start lying to you in two opposite directions at once: overstating revenue while hiding donors who are quietly slipping away.

What’s the difference between a pledge and a payment?

In data terms, this is the difference between a commitment and a transaction:

• A commitment is the agreement: a pledge to give $12,000 over three years, or a recurring promise of $50 a month. It is a single thing that exists the day the donor says yes.
• A transaction is each actual movement of money that pays the commitment down: the first $4,000 installment, then the next, or each successful monthly charge.

One commitment is typically fulfilled by many transactions over time. A model that keeps them as separate, linked objects can answer both “what did this donor promise?” and “what has actually arrived?”, which turn out to be very different questions.

What goes wrong when you collapse them

When a system flattens a pledge into “a gift,” three predictable failures follow:

• False lapses. A donor mid-pledge may make no new commitment this year; the money arriving is just installments on an old promise. Read naively, they look lapsed, so you mail them a reactivation appeal while they are, in fact, one of your most reliable supporters. (This is one face of the donor-count problem: “active” depends entirely on whether a pledge-in-progress counts.)
• Missed churn. A recurring donor’s card quietly fails. No money arrives, but the commitment is still open, so they look active right up until you notice the revenue gap months later. The denominator for recurring churn is expected gifts, not received ones; collapse the commitment and you lose the ability to even ask.
• Double-counted revenue. Book the full pledge and the payments as gifts and you’ve counted the same money twice. Book only the payments and your campaign total understates what was actually committed. Neither is right, because you’re trying to make one object answer two questions.

A worked example

Take a synthetic donor, Dana Okafor, who in FY24 pledges $12,000 over three years and pays it in four installments (illustrative figures):

| Date | What happened | Commitment | Transaction | |---|---|---|---| | 2024-03 | Pledged $12,000 over 3 years | $12,000 opened | — | | 2024-04 | First installment | (open) | $4,000 | | 2025-04 | Second installment | (open) | $4,000 | | 2026-04 | Final installment | $12,000 fulfilled | $4,000 |

If your FY25 report only looks for new gifts, Dana looks lapsed (no fresh commitment that year) even though $4,000 just arrived exactly as promised. If your campaign total adds the $12,000 pledge and the $4,000 payments, you’ve reported $16,000 from a $12,000 gift. Keep the commitment and the transactions as distinct, linked records and both questions answer cleanly: one $12,000 commitment, paid down on schedule.

How the model fixes it

This is exactly the kind of distinction a shared data model makes on purpose. The Advancement Common Data Model separates a commitment from a transaction as first-class, linked objects, so “what was promised” and “what arrived” never have to be untangled after the fact.

The current shape of those entities lives in the open acdm repository; if you’re new to the model itself, start with what is the Advancement Common Data Model?.

What to check in your own CRM

You don’t need to change systems to get this right. You need to know how yours behaves:

1. Can you list open commitments separately from received money? If “pledges” and “payments” only exist as gift rows with a type flag, your reports are one query away from double-counting.
2. Does a pledge-in-progress count as “active” in your retention logic? Decide it, write it down, apply it the same way every time.
3. Can you see a failed recurring charge as churn risk while the commitment is still open? If a lapsed card just looks like silence, you’re learning about churn from the bank statement.

Answer those three and you’ve closed the gap between what your donors promised and what your reports say, and that is the difference between a campaign number you can defend and one you have to apologize for.

For where this fits in the bigger picture, see The Standard (ACDM) and What Becomes Possible.

Examples use synthetic data. ACDM is open and early; treat current releases as drafts.