November 5, 2026
A donor named Mike gave a gift at a spring event. Three years later, Michael sent a check. Last year, Mrs. Michael Reyes, who had recently married and changed her last name, gave online. Her address was updated in the CRM when she renewed her membership, but the donor database still had her old address from the event. Nobody noticed the mismatch until the foundation asked for a list of donors by zip code.
That's not a software problem. It's a process problem that shows up as a software problem.
Why the data gets messy
Most nonprofits we work with have more than one system that holds information about the same person. Usually that means a CRM for clients, members or program participants, and a separate donor database for giving. Each system was set up for a good reason. The trouble starts when information moves between them, or doesn't.
Donor data is created in many places, often at the same time:
- Online gifts that flow straight into the donor database
- Card terminals at events, or a separate credit card system
- Paper checks typed in by hand later
- Large gifts entered by a leader or development staff
- Membership dues that include a donation, transferred monthly through a spreadsheet
- Address and name changes made in whichever system the person last dealt with
Each of those is a chance to create a duplicate record for the same person. Every time the foundation asks for a report, someone has to cross-reference records by hand and hope they matched the right people.
Data cleanup is real work, and it doesn't end. Someone is always typing in a name. People move, change their names and pass away. A one-time cleanup helps for a few months. Then the gaps come back.
It's not really about which database you choose
When an organization has a data problem, the first instinct is often to look for a new platform. Sometimes that's the right call. But in most cases, a new system just carries the same habits into a shinier interface.
The first question isn't "Which donor database should we buy?" It's "Who decides what a donor record is, and what happens when a record changes?"
If those answers are unclear, every system will drift. If they're clear, almost any reasonable system can work.
Five decisions to make before you touch the software
These are process questions, and leadership, not IT, should usually answer them. Settle them before you migrate, merge, or buy anything.
1. Who owns the donor record? Name one person or role responsible for its accuracy. If everyone can edit it, no one is responsible for it.
2. What's the rule for matching a person? Decide how you'll handle nicknames (Mike and Michael), name changes after marriage and moves. Write the rule down, even if it's imperfect.
3. How are members who also give linked across systems? Decide whether membership and giving records should share a common identifier. If they don't, decide how staff will know someone is in both.
4. When does an address change flow to the other system? Pick a direction, a frequency and a person who checks it. "Whenever someone remembers" is not a process.
5. What does the donor report pull from, and who signs off on it? If the report is built by hand every month, it will keep being built by hand until someone decides which system is the source of truth.
Your donor data checklist
Use this as a starting point for a monthly review. Keep it short enough that someone will actually do it.
[ ] Name one owner for donor record accuracy
[ ] Write down the matching rule for names, nicknames and name changes
[ ] Check for duplicate donors before each foundation report
[ ] Confirm that address changes in the CRM have reached the donor database
[ ] List every intake point (online, event, check, membership, spreadsheet) and note who enters the data
[ ] Confirm which member-donors appear in both systems
[ ] Record the report source and the person who signed off on it
[ ] Set a rule for how deceased donors and constituents are flagged, and who updates the record when notice arrives
What to walk away with
Start with the process. Map where donor information comes in, decide who owns it and set the rules for matching and updating it. Once those are clear, you'll know what your systems need to do, and any conversation about tools gets much easier.
If your donor and client data feels like it lives everywhere, that's a common starting point, not a failure. Coat Rack's Nonprofit Tech Strategy Blueprint is a six-week engagement that maps your current systems, data flows, and reporting needs, then gives your leadership team a practical roadmap. If you'd like to talk through where your data breaks down, reach out and we'll start there.
