Untangling Donor-Advised Fund Giving
Closing the gap between a gift given through a donor-advised fund and the pledge it was meant to fulfill — so fundraisers never lose track of the donor behind the money.
A gift with two identities
Donor-advised funds (DAFs) have become one of the fastest-growing ways people give — a donor contributes to a fund managed by a sponsor like Fidelity Charitable or Schwab Charitable, gets an immediate tax deduction, and later recommends grants out to the nonprofits they care about.
That's great for donors. It's messier for the nonprofits receiving the money. Legally, the gift comes from the DAF sponsor, not the individual who directed it. In Bloomerang's CRM, that meant a gift had to be tracked in two places at once — the DAF as the donor of record, and the individual as a soft credit — with no built-in link back to any pledge that gift was meant to fulfill.
A quiet, compounding gap
This wasn't a hypothetical edge case. It's one of the most common points of confusion in fundraising software: fundraisers routinely ask a DAF sponsor for a repeat gift the following year while completely overlooking the actual donor who recommended it, and pledges from DAF-directed gifts can sit looking unfulfilled indefinitely if nothing connects the payment to the commitment.
- Fundraisers risked asking a DAF sponsor for a repeat gift while missing the actual donor who recommended it
- Pledges could look perpetually unfulfilled even after the money had arrived
- Year-end giving statements could quietly undercount a donor's real support
Designing alongside engineering, not ahead of it
I partnered closely with the product manager and engineering manager throughout this project to make sure the design held up against real technical constraints, working alongside an engineering team to bring it to production.
One added layer of complexity: much of the surrounding product was built on legacy screens and patterns. Part of the challenge wasn't just solving the DAF/soft-credit problem in isolation — it was bridging old and new, making sure the updated flow felt coherent next to interface conventions that hadn't been touched in years, without requiring a full redesign of everything around it.
Four moments, one connected story
Before any gift can be tracked correctly, the system needs to know that two constituents are connected: the DAF (a pass-through account, e.g. "Fidelity Charitable DAF") and the individual donor who advises it.
Setting up the DAF ↔ contributor relationship, with automatic soft crediting for future gifts.
The checkbox here does real work: once checked, every future donation logged against that DAF automatically soft-credits the donor, without a fundraiser having to remember to do it manually, gift after gift.
The donation itself is entered against the DAF's account — since that's who legally sent the money — with the donor added as a soft credit.
Donation entry, with the soft credit visible alongside acknowledgement and fund details.
Soft credits aren't static. If a donor's DAF gift was meant to fulfill an existing pledge, that connection needs to be made explicit — otherwise the pledge sits open even after the money has arrived.
Editing a soft credit, with the original donation shown for context.
From this same edit view, if the donor has an active pledge on file, the soft credit can be applied directly to it — closing the gap between "gift received via DAF" and "pledge fulfilled" without a fundraiser having to track the connection manually elsewhere.
Once set up, the DAF relationship surfaces right at the top of the donor's profile — no digging through tabs required.
The relationship is visible at a glance, right in the constituent header.
Three records, one story
With this flow in place, fundraisers gained the ability to accurately track and credit DAF gifts — and apply those payments toward open pledges — without losing sight of the individual donor behind the money. What had been a manual, error-prone process became a connected one: gifts, soft credits, and pledges finally lived in the same story instead of three disconnected records.