We have a couple of customers who have been asking to be able to set-up recurring contributions against pledges. This seems to be a possibly contentious improvement so I'm looking for feedback on it.
These organisations in question deal with lots of pledges (they solicit them by phone) and they record them in CiviCRM. Some of them are paid off by cheques, & some by credit card. Usually they try to get a commitment to set up a recurring credit card contribution & here's where they are struggling with CiviCRM. CiviCRM won't let you record a recurring credit card contribution against a pledge.
We have hacked out CiviCRM 3.4.7 / 4.0.7 install to meet their needs but obviously if we are going to move to 4.1 then we want to know we have a way to manage that.
There are 2 main reasons why they want recurring payments against pledges:
1) Because they want the same reporting for all their pledges no matter how they are paid
2) Because the pledge may be paid by different mechanisms over it's lifetime.
The scenario we have is
Someone pledges to pay $20 for month for 3 years. They agree to set up a recurring contribution against it for the first 6 months (until the credit card expires). At that point they send in a cheque for the next couple of months & one the following one they provide a new credit card for the rest of the pledge.
We have removed the code that hides recurring payment options when submitting a pledge payment. This means that the first payment is recorded against the pledge & is a trivial tpl tweak.
We've also tweaked the BaseIPN code so that when each payment comes in IF another payment in that recurring payment subscription has been treated as a pledge payment then the new one is treated as a payment against that pledge too. This seems to make sense as we are looking at a situation where there might be more than one recurring payment subscription for a single pledge but a recurring payment subscription only ever goes against one pledge.
I had some thoughts about how to deal with validation (ie. rules for when payments don't match) but the concern the core team has is actually whether it's a good idea at all.
As Dave put it "we're a bit hesitant about this because in prior discussions folks indicated that Pledges and Recurring Contributions were different animals and should be kept separate due to differences in how they're supposed to be "accounted".
So, I guess the question I want to ask is whether there is good reason not to go down this path in CiviCRM core (our customers are committed to the path so that's not in question).
As an aside, Authorize.net supports payments with a future start date when you are using recurring payments - even if there is only one installment. The tpl tweak allows us to set-up post-payday payments against a pledge.
I'm new to the conversation, but it seems to me that the easiest way to solve this is to add the functionality to CiviPledge to indicate how the person intends to pay the pledge (i.e. invoice me, debit my credit card, debit my bank account, etc.). This would be set up for each Pledge record and the customer could change the method of paying the Pledge at any time. So they might start off when they initially pledge the money by paying automatically with a credit card each week/month/year but 6 months into it they decide they'd rather be billed. Either they go into the pledge record or some administrator does it.....but that pledge record is changed to invoice me and from that point on....email pledge reminders (or print pledge reminders) are sent. this would keep the recurring and pledges separate. If the person chooses to automatically debit their card for the pledge then a cron could be set up to generate an email X number of days prior to the debit to let the person know it's going to debit. This ensures that at any time the person can change their mind and how they want to pay it.
What is the current status of this? This is one of the highest priority issues we have for CiviCRM. Another would be simply allowing the donor and admin user to set the date for when a reocurring gift comes out on each reocurring cycle rather than just defaulting to the day the donor or admin enters the reocurring gift.
We have been in business as a non profit for about 18 years. We recently moved to CiviCRM. One of our biggest frustrations is the way it handles 'reocurring contributions' different from pledges. I think it strongly confuses methods of payment with a mode of giving. When you tell an organization you are going to give monthly, quarterly, etc. you are making a pledge. This doesn't change if you then say, "I would like to pay via check" or "I would like to pay via credit card."
The current structure makes reporting on a very vital issue impossible without modifications. If I simply want to see how many donors we have giving how much in total as pledges/recocurring gifts you have to run two reports and then manually combine them or create a custom reporting solution.
It is a very common requirement for organizations who deal with donors who give each month or quarter to want to know how much in total they have of these type commitments for each internal fund regardless of how the donor is actually paying the commitment.
I would like to see a way to link reocurring gifts to a pledge. This would make a world of difference to us and many other organizations.
As a side note, it would be great also if you could link a contribution to a pledge simply in the batch entry screen. The current process of linking a contribution to a pledge is far to cumbersome to use in quantity. Most donor software allows you to quickly search for and link a pledge to a contribution in a batch entry process....kind of like Google fills in the rest of your search term as you type part of a word.
Anyone interested in revisiting this? I have a client who is interested in having pledge payments automatically relieved by a reucrring credit card transaction. When the user is making the pledge on the font end, the cleint would also like to have the start date either definable by the user, or set on the back end by the administrator.