Recurring Donations in NPSP

This insight will resonate with those familiar with Salesforce, the Nonprofit Success Pack (NPSP), its various iterations, and other related Salesforce automation features. Recurring Donations in NPSP create a special challenge, Tectonic has found. For those less engaged in these topics, there are still valuable ideas to discuss.

Thank you for reading this post, don't forget to subscribe!

For over a decade, there has been an ongoing challenge with handling donations processed through multiple transactions. These Multi-Installment Donation Scenarios (MIDS) include:

Multi-year grants (outbound and inbound)
Monthly recurring donors
Pledges fulfilled by different donors in the same household
Any type of pledge fulfilled in chunks

Tracking donations where the commitment and transaction occur simultaneously is straightforward. For example, credit card donations through online forms require creating a donor record (if it doesn’t already exist) and a gift record. However, when there is a time lag between commitment and transaction, similar processes can be used. The challenge arises when commitments result in multiple checks or credit card transactions over time, breaking standard rules.

This has puzzled fundraisers, operations personnel, accountants, and database admins for years, leading to various approaches. Each role may prefer different methods, adding complexity. Even Salesforce has changed its approach to MIDS, resulting in multiple models/modules in circulation. If you feel overwhelmed by MIDS, you’re not alone.

MIDS are one of many complex scenarios to record in a donor database. However, other scenarios are not covered in this insight, such as:

Gifts from Donor Advised Funds (DAFs) unless fulfilling a MIDS
Bequests, even though often processed in installments
Employer match contributions, which seem like installments
Two or more donations from the same person in a short period, without expressed donor intent or pledge card
Peer-to-peer fundraising, which resembles MIDS installments under the peer’s campaign

There are several options for modeling MIDS in Salesforce:

Donation With Payments: Commonly used for grants, NPSP automates payment scheduling according to interval rules. This is recommended for organizations using accrual accounting.

Legacy Recurring Donations: Allows setting donation schedule rules, with Salesforce automatically creating donations accordingly. Suitable for projection reports and updating each donation when the transaction occurs.

Enhanced Recurring Donations: Introduced by Salesforce in 2020, this module solves issues like skipping months or changing future payment amounts by creating one installment ahead. When the installment is paid, the next one is created according to the schedule/rules.

Custom “Pledge” Object: Useful for grouping donations according to pledges, without needing automation for scheduling installments. Ideal for tracking multiple data points about each pledge.

Our Opinion:

Tectonic has a strong preference for Legacy Recurring Donations over Enhanced Recurring Donations, although it’s not a significant issue to use either. Donations with Payments are problematic and should be avoided. Here’s why:

Problems with Donations with Payments:

The official documentation suggests this model for accrual accounting, but this recommendation is questionable. Many readers lack a foundational understanding of accounting models. Furthermore, dividing a donation into parts (payments) complicates reporting and rollup fields.

Recurring Donations Benefits:

The Recurring Donations (RD) model is smart and elegant. NPSP’s automations for both Legacy and Enhanced RD modules are strategic and reliable. Using the RD model for more than just traditional recurring donations (like monthly donations) can be beneficial. Rebranding “Recurring Donation” to “Pledge Fulfillment Schedule” can naturally incorporate various MIDS types, such as grants and pledges.

Top Tips for Configuring Legacy Recurring Donations:

Create projection reports for pledged donations in future years.
Standardize reports showing active RDs with grouped donations.
Run reports for overdue donations using the RD data model.
Create Record Types for Individual RD and Org RD to simplify data entry.
Use a formula field to record the Pledge Date on donations.
Enable copying the Campaign from RD to each child donation in NPSP Settings.
Create naming conventions for donations and RD records in NPSP Settings.
Consider a Before Save Flow to update record names when the Campaign or Close Date changes.
Store Pledge Cards on the Recurring Donation rather than individual donations or households.

One Odd Thing:

In moves management, if a donor switches from a lump sum to installment gifts, create an RD and auto-create installment donations. Delete the first donation in the series and connect the Moves Management donation to the Recurring Donation record.

Legacy Recurring Donations are a preferred option for modeling MIDS. This data model is suitable for all scenarios. With proper setup, it can become a powerful tool for a data-driven fundraising department or a streamlined option for tricky use cases.

Two principles of good design—“like goes with like” and “measure twice, cut once”—explain why transaction-oriented information should stay on the Donation record, and pledge-oriented information on the Recurring Donation record.