4

What's the difference if I set up a recurring payment for $100/month versus a pledge for $100/month?

Why should I use one method versus the other?

4

CiviCRM allows pledges to be recorded for promises of future payments. This is commonly done for future expected donations for capital campaigns. In most cases, 'pledges' are not things that people are obligated to pay, and so they should not be recorded as accounts receivable for bookkeeping purposes. The courts in some US states are starting to recognize pledges as contracts that can be enforced, but this is not case in Canada or most states (see http://drache.ca/articles/unpaid-pledges/). Only when a payment is received against a pledge is the amount recorded as revenue to the appropriate account (eg Donations or Campaign Contributions) and as having been deposited into the appropriate asset account (eg bank account or payment processor account or cash and cheques on hand).

By contrast, when a recurring payment is set up, the contact authorizes the organization using CiviCRM to be paid those future payments, eg from a credit card, a bank account associated with a debit card, or some other payment instrument. This makes it reasonable to record the future income from recurring payments as accounts receivable immediately, which will be the case starting in 4.7. When those payments are received, accounts receivable will be reduced by the payment amount and the appropriate asset account will have the funds credited to it.

Simplifying a bit, if you have an automated method of receiving payments, then you should set this up as a recurring payment. But if you may or may not receive the payments (for example, you are dependent on the donor to send in a cheque each year), then you should setup a pledge.

While it is true that a donor can cancel a recurring payment (whether setup through ARB, ACH, etc.), this doesn't change the fact that they have made a legal agreement to pay the monies. If they do ask to cancelling a recurring payment, then CiviCRM will reverse the accounts receivable at that point in 4.7. (If the recurrence does not have an end date, then the system keeps the accounts receivable accurate for the coming 12 months, and those 12 months will be reversed at the time of a cancellation.)

4

In simple terms, if the person is planning to pay by an unknown or manual process (check, cash, bookkeeper manually recording payment as they see it on a bank statement) then you will use a pledge in CiviCRM.

If the person is going to pay using a CiviCRM payment processor that offers recurring (such as credit cards/ACH via iATS or Authorize.net, etc) then you will need to use a recurring contribution in CiviCRM.

In theory, the legal obligation for the donor/member to make all payments should be considered. However, in practice the mechanism of payment is what determines the use of pledge vs recurring contribution. (at least in all stable versions of CiviCRM)

  • 4.7 will also see manual recurring payments as I understand it based on work by Compucorp in the UK. – Joe Murray May 8 '15 at 1:02
  • Thats good news for version 4.7. What about the work being done for partial payments? Wouldn't another option be to partially pay a contribution? Since this is already possible in the back-office for event contributions, is there work to extend partial payments to stand-alone contributions and membership contributions? – Sarah Poger Gladstone May 8 '15 at 1:45
  • 1. There is a GSoC project that aims to do refunds and partial payments. I'll be very happy if it produces code that is committed to core for one of those areas. – Joe Murray May 8 '15 at 2:30
  • 2. Either as part of that initiative or for our own purposes JMA will be aiming to get a good API for payments and and likely refunds built and included in 4.7. – Joe Murray May 8 '15 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.