Veröffentlicht
2011-11-08 18:20
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.Filed under
Comments
I agree with Dave that many orgs view pledges and recurring contribs as different animals. And I suspect there are a lot of orgs that use recurring contribs, but who never make use of pledges. To force them to migrate to a pledge structure will not be popular -- for the same reason you want all pledge/recurring in a single location (they would prefer recurring and one-time remain consolidated in the single contrib tab).
But your use case is also totally valid. My vote would be to allow what is essentially the same basic behavior (recurring contribs) in both places. I don't like the confusion that potentially creates, but think feature flexibility trumps the confusion risk.
I'm not sure if you think that I or Sarah was suggesting to force people to set up pledges for all recurring. What my customers want is the ability to pay off pledges with recurring contributions. The major assumptions I would include are:
1) If one payment out of a recurring contribution sequence has been used to pay off a pledge (ie. the first one) then subsequent ones would be put towards paying off the same pledges as long as there is payment outstanding (& no linkage in the edge case where it's already paid off).
2) Recurring payment amount mismatches would not change the pledge total but could change expected installments(pretty edge case that they wouldn't match too).
I have the exact situation you are describing with my clients too.
The comment "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" does not make sense to me in terms of the current CiviCRM capabilities. Currently CiviCRM does not have a uniform way to indicate how a particular situation should be "accounted for" ie does the organization consider something an obligation (affects the balance) or not. (does not affect the balance.)
Without hacking CiviCRM, an org ends up using automated recurring contributions instead of pledges solely because someone wants to automate their payments. Had the person said they would pay by check, it would be entered as a pledge, not a recurring contribution.
Currently there is no clear separation between the original obligation, and how the person plans to pay it off over time. For example: If someone wants to automate payments on a credit card for a yearly membership, then the org needs to set up a different membership type for each billing plan, such as monthly, quarterly, etc). If someone changes their billing plan, then the membership records are funky because it now looks like they switched membership types, when in reality they just changed billing plans. Without hacking CiviCRM, an org ends up using automated recurring contributions instead of pledges solely because someone wants to automate their payments. Had the person said they would pay by check, it would be entered as a pledge, not a recurring contribution.
What needs to be addressed for all financial activity: Allow the organization to easily specify if something is considered an "obligation" or not from an accounting point of view. Then allow the donor/member to pay off that obligation in a variety of ways: checks, one time credit card payments, automated recurring credit card payments, or some mixture. Also the intended schedule of installments may change over time. A person may change jobs, and wants to switch the installment plan from monthly to every 2 weeks to match their new paycheck cycle. Or they paid more/less than expected for one installment, and the staff wants to "reset" the remaining payments to evenly spread out the remaining balance.
As an aside - being able to record custom data against recurring contributions & having them better exposed would reduce the need to use pledges in some cases.
just to clarify -- you can extend them with contribution type custom fields, but the data is only collected and stored in the first record, not subsequent ones. though it's not too difficult to have that carried over to future records via hooks.
how this is implemented and managed by Raisers Edge / Convio and other fundraising packages. Might give us a bit / lot more insight.
From a very brief look at raisers edge docs (the gift records guide), it seems the two are kept separate and distinct from each other. There is an option to convert a pledge to recurring gift
lobo
Lobo just pointed me to this link
http://www.blackbaudknowhow.com/the-raisers-edge/recurring-gifts-in-the-raisers-edge-you-know-you-want-them.htm
& it made me think about the difference between pledges & recurring. The difference in 'real life' & in 'Civi' are different
1) In real life recurring can be open ended & pledges are for a fixed $ amount (same in Civi)
2) In real life open ended recurring payments can be paid by a variety of mechanisms. In Civi they can only be be paid by recurring credit card payment
3) In real life someone might phone up & say 'bill my credit card for the last 6 pledge payments'. Civi won't allow this.
4) Civi provides very little visibility of Recurring, You can't extend them with custom fields, they don't show on the tab. I think you can use them as a search criteria for contributions but you can't search to see a list of subscriptions (I suspect there is a custom report). They are largely hidden.
Perhaps this is another case of the situation where the intention to pay & the payment mechanism are just too closely intertwined in Civi.
that since pledge is more developed than recurring, we should link recurring to a pledge. I think adding the missing functionality to recurring seems to be a better step. with regard to your comments above:
2. The folks at Koumbit (samuelsov on IRC) is working on allowing other sorts of "recurring credit card payments". For them it will be driven by an external script that triggers the recurring payment. As part of the work, he's also exposing recurring contributions on the contributions tab (part of point 4)
3. linking recurring to pledge wont solve this either.
4. would be a good feature add to the recurring stuff
lobo
Realistically I think there are 3 distinct things
1) a fixed amount pledge
2) an open ended agreement to make a regular payment
3) a recurring credit card payment subscription against either of the above (they could also be paid by another means).
It's the ability to make a recurring credit card payment against something other than #2, or indeed to pay off #2 by something other than a credit card that is missing.
I agree that it would be great if the concept of an open ended gift were fully developed. It would have to accept payments other than recurring credit card payments to be useful for our customers.
The patch itself is trivial - unless a pledge_payment entry has already been made for a given pledge it has no effect. But, obviously it's pretty key for us as it will dictate our upgrade strategy (ie. if we are managing a patch we won't want to be having too many point version upgrades)
Great that this issue is getting raised as we also have this issue for a client.
Part of what we are wanting to achieve with the "CiviAccounts Project" is to separate the logic of "obligations to pay" from "payments" and to enable finer grained accounting code allocation to items within a single order/payment - e.g. payment for items in a price set.
The situation you are describing seems to be arising where a payment is received and/or is anticipated to be received, and it needs to be reconciled against an "obligation to pay" (recurring contribution) or an "intention to pay" (pledge).
The way I envisage it is that there should be a new option on the Contributions tab to "Record a Payment" and that you would then have the option to choose whether that payment creates a new Contribution or is applied against an existing Contribution (such as an event registration, membership or a Recurring Contribution) or a Pledge. If you are using a payment processor to enter a credit card for a Recurring Contribution/Pledge, then you could have the option to "Make future payments from this Card/Account" so that the reconciliation can be automated when the payment processor pings you to advise another payment for this amount has been paid.
The API could do similarly.
Your idea makes sense - I guess I'm only focussed on a small part of it at the moment - ensuring that - assuming the payment has been linked to *something* then that *something* is updated when the next payment is received - in this case the *something* is a pledge.
IE I'm mostly interested in what BaseIPN does because it doesn't call hooks.
From my perspective, Recurring Payments is a payment method. Pledges is one of the things that one can pay for or toward that benefits from such a method. Memberships is another. It makes sense to be able to change the payment method attached to something that can be paid. In the same line of reasoning, it would provide better customer service to be able to change payment methods on Events too when they are not yet paid.
Objects that need payment need to know if they are paid but they don't need to know how.
A recurring payment means that there is a legal right to keep taking the money from someone's account, whether a credit card or a direct debit. A pledge does not provide that - it's merely a promise from someone that they intend to give, but can't be enforced. It is useful for fundraisers to track pledges, but they can't be sent to a collection agency like the outstanding balance for missing monthly payments on an annual membership.
In Canada low end fundraising generally never sets up monthly recurring donations for a defined number of payments, only indefinite (people can revoke their authorizations for them at any time, more or less, but not retroactively). Limited numbers of installments on recurring payments are used for things like pledges to a 3 year capital campaign, where someone promises to give $18k or $180k in total.
Mixing and matching various payment methods for different payments against a pledge seems like it would be a nice to have feature. Allowing recurring payments to be recorded as paying down a pledge seems like a nice thing, since often these donors will be paying for a membership, coming to dinners or making other one-off donations as well.
Collapsing pledges into recurring payments or recurring payments into pledges would be problematic. But the way I see the proposal is to continue to have recurring payments and pledges as two separate things, optionally linked via configuration of a certain page or campaign or something. Some organizations will be able to set it up so that some recurring payments are set up to be recorded as paying down some pledges. That's fine.
Hmm - that's an interesting point. I guess there are 3 concepts here aren't there?
1) A pledge - an unenforceable promise to pay
2) A recurring credit card set-up - a payment method that gives you the legal right to take money from their accounts - but presumably not to pursue them for the $$ if they miss a payment. e.g. it bounces
3) An invoice broken into payments - e.g. a membership with monthly payments - which gives you a legal right to pursue them for missed payments (if the terms so say) . This is probably less common in the CiviCRM world but in the business world often applies to things like lease agreements where you are locked into paying 3 years of installments whatever happens
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.