Aller directement à la fin des métadonnées
Aller au début des métadonnées

CiviCRM Implementation

Pledge Cases

Phase 1

  • admin enters recurring pledge of a given amount + payment of 1st installment
  • admin enters recurring pledge of a given amount + payment to be sent (i.e. pay later)
  • admin enters one-time pledge

Probably phase 2...

  • online constituent enters recurring pledge of a given amount online + pays 1st installment via credit/debit card
  • online constituent enters recurring pledge of a given amount with payment to be sent by check (i.e. pay later)
  • online constituent enters one-time pledge with payment to be sent by check (same as pay later contribution)
  • online constituent receives reminder to pay next "installment" of their pledge via email (email contains link to online contribution page where they can make the payment via credit/debit card)
  • logged in online constituent sees scheduled pledge payments on their "Contact Dashboard" and clicks "make payment" link to make payment via credit/debit card

Data Objects


  • Contact ID
  • Contribution Type ID
  • Date Created
  • Date Modified
  • Date Cancelled
  • Frequency Unit (day, week, month etc.)
  • Frequency Interval (integer - e.g. every "3" months)
  • Frequency Day - The day of week, month or year that payment is scheduled.
  • Number of Installments
  • Total Pledge Amount
  • Pledge Status
  • Pledge Acknowledge Date (when acknowledgement of pledge was sent to constituent)
  • Honor Contact ID
  • Note (join to civicrm_note)
  • Initial Reminder Days (send first reminder this many days prior to each payment due date, default = 5)
  • Maximum Reminders (maximum number to send for a given payment, default = 1)
  • Additional Reminder Days (send additional reminder this many days after last one sent, up to maximum number of reminders)
  • Custom fields

These properties will be derived from the pledge's payment schedule

  • First Scheduled Payment Date
  • Next Scheduled Payment Amount
  • Next Scheduled Payment Date
  • Current Past Due Amt
  • Total Paid
  • Balance Due on Pledge

Pledge Payment

Scheduled and fulfilled pledges are recorded here. Fulfilled pledges are linked via contribution_id to the contribution record (which contains the payment details such as payment date, transaction id, etc.)

  • Pledge ID - Foreign key to pledge record.
  • Contribution ID - Foreign key to contribution record when payment is received.
  • Scheduled Date
  • Scheduled Amount
  • Last Reminder Date - Date when most recent reminder was sent
  • Number of Reminders - How many were sent. The reminder timing (relative to payment due date) and frequency will be configured in the Pledge.
  • Pledge Payment Status (pending, completed, overdue ... )

Pledge Listings and Forms

Details at CRM-3244.

Update Pledge Statuses and Generate Reminders

Details at CRM-3270.

Record Pledge Payments (admin / back-office)

Details at CRM-3269.

Search / Reporting

CiviPledge will have it's own Dashboard with a Pledge Summary showing Pledges Made, Payments Received, Balance Due and Overdue totals (details at CRM-3274). A new search component will allow users to search for pledges by status (e.g. Overdue, Completed...), pledge amounts, start dates, etc. We will include at least one custom search in the release as well - targeted at locating pledges by next payment due date, status, etc.


Fixed Total Pledge Amount vs. Open-ended Pledges
Some systems seem to require that a pledge have a "committed total amount" (sometimes referred to as the "pledge value"), while on our wiki requirements page folks mentioned the possibility of an "open-ended" pledge. Elin's comments on the older Pledges and Soft Credits page indicate that a having a "total pledge amount" is a defining characteristic of a pledge and needed for accounting purposes. The reporting that I've seen includes summing of these pledge totals - along with "balance due" amounts. Not sure how you do that when some pledges are open-ended? Maybe you just derive a "committed total" for a given accounting year.

  • For phase 1, all pledges will have a "committed total". We'll evaluate whether / how to support open-ended pledges in a subsequent phase.

Is a Recurring Contribution just one type / case of Pledge?
Our existing "recurring contribution" model seems to be exactly the same as one of the pledge cases listed below (online constituent enters recurring pledge of a given amount online + pays 1st installment via credit/debit card). In the current implementation the user can choose to set a fixed number of installments OR make the payments open-ended. Are recurring contributions really different from pledges, or are they just one of the pledge cases.

  • For phase 1, recurring contributions and pledges will be stored separately. Recurring contributions are auto-billed through a payment processor, can be open ended (number of installments is not defined).

Pledges and Contribution Pages / Campaigns / Funds ...
Are pledges linked to an Online Contribution page? What about offline pledges? Many systems allow linkage to a "campaign", "fund", "program" and/or "appeal".

  • Linkage to an Online Contribution page will be included in the data model in phase 1 but probably not implemented in the UI. Fund or program can be represented using the include contribution type. Campaigns are scheduled for a future release.

Billing for Recurring Pledges
How do we handle "billing" for scheduled pledges? Seems like we need a cron-job driven email notification. What about snail mail "billing". Is there a difference between a "bill" and a "reminder"?

  • We will build a cron-fired script to generate reminder emails for "due" pledges. Since a pledge is not a legal commitment or purchase - we'll call these pings "reminders" not "bills" - but the organization can modify template language as desired. Reminder letter generation (for postal mailing) will probably be addressed in phase 2.

Constructing the Pledge Elements
Pledges and their "payment schedules" may be "constructed" in a few different ways. We'll probably need a dynamic set of fields to to handle the relationships between the pledge elements:

  • Enter amount paid each time + frequency + number of installments (e.g. I pledge to pay $20 every month for 12 installments). Then the "pledge value/total amount" is calculated (e.g. $240).
  • Enter amount paid each time + frequency + end date (e.g. I pledge to pay $20 every month starting now until Dec 2008). Then the "pledge value/total amount" is calculated (e.g. $120).
  • Entering a total amount pledged + amount paid each time + frequency (e.g. I pledge to give $240 in monthly installments of $20). In this case the number of installments is derived (e.g. 12 installments)

Donor DB Application - Overview of Pledge Functionality

3 related record types:

  • Gift (regular contribution)
  • Pledge
  • Pledge Payment


Pledges and Pledge Payment Details

(This form is used for both types of records)

  • Date (created)
  • Amount
  • Value
  • Reason / Appeal
  • Campaign
  • Fund / Program
  • Anonymous?
  • Ack. ?
  • By Letter - select letter from drop-down
  • Comment
  • Memorial
  • Method (not sure what this is)
  • Chk Date and Chk #

Additional Pledge Details

Input fields:

  • Frequency (select Annual, Semi-Annual, Quarterly, Monthly, Bi-weekly, Weekly)
  • No. of Payments (text input)
  • First Payment Date

Displayed values (after pledge is created):

  • Next Scheduled Payment Amt
  • Next Pay Date
  • Total Paid
  • Balance Due
  • Current Past Due Amt
  • Schedule (table of calculated payment dates and amounts based on above values)
  • Payment History (table of actual payment dates + amounts for this pledge)

Record Pledge Payment

  • From Gifts and Pledges - pick contact
  • Pick Gift Type - Gift, Dues, Pledge, Pledge Payment, Sale
  • If pick Pledge Payment - then table of pledges for that contact - "Select a pledge"
  • Get pledge payment entry screen

OR ...

  • From the Pledge screen, click "Add Pledge Payment"


Pledge Report

For each pledge...

  • Contact: name, address, email, phone
  • Pledge: amount, date made, "To be paid in $number $interval payments, beginning on $firstPaymentDate"
  • Payments received:
    dd/mm/yyyy $amount
    Total Paid:
    Balance Due:

Report Totals

  • Total number of donors
  • Total Pledges: $totalAmount
  • Total Pledge Payments: $totalPaid
  • Total Balance Due: $totalAmount - $totalPaid

Pledges Past Due Report

For each past due pledge...

  • Contact: name, phone, email
  • Pledge Date (created)
  • Pledge Amount / Total Paid / Balance Due
  • Bill Amount / Past Due Amount (? not sure what the difference is ? )
  • Last Paid Date / Last Billed Date
    (seems to be missing Past Due Date ?? )

Report Totals

  • Total Amount and Number of Past Due Pledges


Pledge Reminder

  • Could either create Word Doc template(s) w/ tokens
  • Gifts and Pledges dashboard has link to "Send pledge reminders" OR go to Quick Mailings and select "Quick Pledge Reminders"
  • App "finds" all "past due" pledges and creates Word doc w/ merged data (a letter for each past due pledge)

Contributions Statement

  • Create Word Doc template(s) w/ tokens
  • Gifts and Pledges dashboard has link to "Send Statements" OR go to Quick Mailings and select "Quick Contributions Statements"
  • A range of dates is requested.
  • Pledges, Pledge Payments, Pledge Balance and Contributions are reported within the date range, organized by fund or contribution type. An example is attached to this page.
  • Aucun
  1. Jun 25, 2008

    OK, mostly thinking out loud:

    The pledge payment schedule might be a bit over ambitious for a v1 release. Not sure what the goal is. If the goal is to provide a CiviCRM user with an automated reminder to fill a pledge, I would think that would be handled best by activities>tasks. Workflow (a) create a pledge. (b) record a task for next month when you need to get the check. (c) get a reminder from the task. (d) get the check from the donor.

    If the case is the recurring donation,  then I tend to favor generating multiple pledges- each installment equals a separate pledge... but we would need some type of automation to create those pledges into the future.

    Since CiviCRM has no ability to fire a reocurring transaction, the standard pledge workflow will be to track a payment entered externally. You would know the installment structure of the payments (one option is indefinate), therefore you could create a series of pledges, each representing a single installment.

    In this structure each pledge has one or more payments associated with it.... seems like we really need two objects... the pledge and then one or more bills/invoices derived from the pledge that are then matched with payments/contributions. The pledge reminder should be associated with the bill and not the pledge.

    For reporting, seeing a list of constituents making pledges would be a list of pledges. If you want to talk about the dollar value of pledges (how much is expected next month), then you really are talking about summing bills/invoices.

    I would rework the reporting requirements a bit:

    1. Who do I need to call to get money from? This is invoices due that are not automatic/recurring.
    2. How much money did I expect last month and how much did I actually get?
    3. Did I leave any money on the table (i.e. are there overdue pledges I need to follow up on, donors I need to call to get their correct credit card number, etc)?  [current past due report]
    4. General pledge overview (same as current report)

    I suspect the workflow for pledge management might require a few more steps.

  2. Jul 08, 2008

    Shawn Duncan dit :

    We use the kind of statement that I added under letters above which also functions as a gentle sort of reminder for those who are past due. I'm sure we're not the only one who would find such a report useful

    1. Jul 09, 2008

      Shawn - For phase 1 we plan to includ an automated reminder-via-email feature. You'll be able to turn this on or off and control the frequency and number of reminders on a per-pledge basis. The content will be in a template file that can be customized as well as needed. We'll look at generating letters / statements for mail-out as a phase 2 feature. If you have an example of the "statements" that you currently generate - it would be most helpful if you attached it to this page - so we have a good example to start with when we get there.

      1. Jul 09, 2008

        Shawn Duncan dit :


        That's a solid plan. I've attached an example (pdf format). We calculate a "suggested" payment per month to complete the pledge on our statements. It would probably be more elegant to refine that to payment per period based on the frequency of the original pledge. The point of this is suppose Mr. Jones pledges $200 per month for the year. After 6 months, he should have contributed $1,200. If in fact he missed a month and has only contributed $1,000 then we not only want him to continue his monthly payments, but increase them to $233.33 in order to complete the pledge on time. Donors who pledge may be unable to simply send in a double payment to catch up if they are behind.

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.