RENXT Recurring Gift Functionality - pros and cons

I would definitely use the recurring gift type functionality. So much cleaner regardless if you have it automated or a recurring batch. Are you looking at using in db view for the next year or jumping to web view for implementation? Why have you opted not to use it? What were your issues?

@Carlene Johnson raised some valid questions to help understand your specific questions. The word 'recurring' can be defined in different ways.

We use the NXT recurring gift functionality for BBMS processed recurring gifts and it functions well. We recently moved from Luminate Online forms to the NXT web form options and they are functioning well, although I hope the functionality for Tribute acknowledgment to the the one honoured to go automatically comes on line soon. For third party recurring gifts, we do not have many by comparison to our online donations. I set up the recurring gift in the record and then manually batch the payments so they get applied to the recurring gift properly. It works well for the volume we have. The time to manipulate/enhance the 3rd party data so I can use the import function to match the recurring gift payments to the recurring gift is about the same as a quick manual batch process so I've stuck with that for now. I do have experience with Engaging Networks as a fundraising and communications platform at a prior organization and they are a solid partner. We imported the gifts from EN using the JMG Solutions Super Importer Exporter. We used pledges rather than recurring gifts there, and the payments did get applied appropriately during the import. I am not affiliated with JMG, but know them well through extensive use of the Super Importer Exporter.

We have been using recurring gifts for over 20 years with about 10,000 active regular givers. We use BBMS for credit cards and process direct debits via our own bank. In a previous organisation I used the recurring gift functionality for gifts being automatically processed externally by a third party and the results were imported to The Raiser's Edge daily.

Here, we have been using BBMS for decades but only automated our credit card processing with Blackbaud 8 months ago. It is definitely worth automating your recurring gifts with Blackbaud if you can, or just using the recurring gift functionality to track your recurring gifts is a step in the right direction. There are lots of advantages to both but there are a few cons which have not been mentioned yet.

If you go ahead be aware of the impact on supporter care, gift management processes, cash flow and reporting. Most of the cons can be managed with staff training, updating gift processes and using gift attributes to improve tracking and reporting.

Manually processed recurring gifts:

1. You can apply a cash gift to a recurring gift, which converts it to recurring gift pay-cash. However, there is no way to convert a recurring gift pay-cash back into a cash gift. For donors who regularly donate into our bank account but occasionally make extra donations to our appeals these extra donations are sometimes mistaken for their recurring gift payment. We can fix the gift coding but not the gift type. This may affect reporting if your reports use gift type. Depending on your audit and reporting requirements, you can either live with it or delete/adjust the recurring gift pay cash and create a new cash gift.

2. The recurring gift tracks changes to amount, frequency etc. with amendments. But if you do need to update things like funds on existing recurring gifts then existing amendments prevent global changes, so imports are required. Amendments make the imports more tricky, still possible just a bit more complicated. Split gift amendments further complicate updates. This is just a training and process issue and there are ways around it.

3. If you have donors who pay directly into your bank account regularly and set these up as recurring gifts then you will need to manage the schedules to keep the next due date up to date i.e. skip payments if they miss a gift, roll back if they make extra gifts, amend gift amounts. Often the frequency is not clear when a donor sets up an automatic payment at their end and if you get it wrong and don't notice e.g. make it monthly when it is actually weekly, then it can be difficult to fix after some time has past. You can use an amendment to fix the frequency, but then you cannot roll back the transaction date before the date of the amendment so gifts may have the wrong schedule until you catch up. Or if you roll back gifts to get the next transaction date correct, you cannot date an amendment to fix the frequency before theoriginal last gift date (before the roll backs). Either way you can end up with schedules with a next transaction due date years into the future and have no way to fix them. If you are not hosted then plugins may help, but most of these plugins are not available to hosted clients. You can either wait to catch up (I use gift attributes to mark these) or cancel one recurring gift and start a new one with the correct schedule.

4. You cannot merge recurring gifts to transfer card details from one to another, so if an existing donor signs up on your website with a new gift e.g. to securely update their card details then you need to cancel their existing gift. This means they have two recurring gift schedules which may cause problems for reporting. We copy the existing coding over to the new gift, and have a cancellation reason (gift attribute = reactivated via new sign up) to help manage duplicates in reporting. We also assign a recurring gift ID (gift attribute) that is used for that entire period of giving no matter how many recurring gifts they end up with over that time.

5. There is no exportable link between the recurrring gift payments and the recuring gift that spawned them. You can export both recurring gift pay-cash and recurrring gifts but no system ID that links them. This may be a problem for reporting if a donor is a regular giver for a few years, cancels for a few years and then signs up again. You can export/query gifts from the donor but not connect them to a particular recurrring gift schedule. as a workaround, you can export installments from a recurring gift using query but not all gift fields are available for the payments. There clearly is a link in RE, you can view payments by recurring gift when looking a an individual record, when importing it is the recurrring gift ID, but Blackbaud have never made it available to export with payments.

Automated gifts

When you move from manually processed gifts to automated gifts the biggest pro is obviously that you don’t need to manually process gifts, so they are still processed on weekends and public holidays. But there are smaller pros too e.g. refunds, and retying failed payments become super easy with just a click of a button from the gift in RE. But there are additional cons.

1. You cannot cancel or amend automated gifts via database view, all changes must be made in web view. Change in web view take longer than the same changes made in database view.

2. Some global changes will not affect automated gifts so changes must be made manually in web view.

3. The multiple recurring gift issue above compounds because once an automated gift has been cancelled or terminated it cannot be reactivated. You can still put gifts on hold and reactivate those but not if it was marked completed or terminated. So if a donor cancels then changes their mind you need to start a new gift and get the card details again. This may be annoying if you have a programme to save cancelling donors or if a donor gets back to you just after you gave up on them updating their failing credit card and cancelled their gift.

We use third part tele-agencies to get new card details when gifts fail, card details are tokenised with BBMS by they agency so they can be sent back to us securely, but you cannot add a new token to an existing recurring gift so we need to cancel the existing gift and start new one with the new credit card token, copying over coding and attributes.

4. Check the time of day that automated gifts are processed. I am in NZ but settlement dates are based on the US time when the gift was processed. When we were manually processing gifts we processed them earlier in our day, before midnight in the US (yesterday to us). Now our automated gifts are processed at 11pm NZ time, which is a new day in the US, now the same date as in NZ. This means that it can take an extra day to receive funds from automated gifts. Some of this is mitigated by automatic processing happening on weekends and holidays but not all.