Before you merge duplicate donor records, run three checks

Before you merge duplicate donor records, confirm three things: both records represent one person, every financial relationship has a safe destination, and the surviving contact keeps the right communication choices. If any check is unresolved, hold the pair instead of forcing a merge.

The useful decision is not “duplicate or clean.” It is one of four outcomes: merge, link, mark as not duplicate, or send to an accountable owner.

Treat a match as a question

A duplicate alert is a candidate, not proof. Salesforce's current Nonprofit Success Pack guidance recommends defining which fields identify duplicates and using a second field for common names. DonorPerfect's duplicate-management guidance similarly uses matching criteria to surface candidates, then lets an operator combine, link, reject, or defer the pair.

That distinction matters for a small team. “Pat Lee” at one address and “Pat Lee” at another may be one donor who moved, two people, or a data-entry error. Two contacts at one address may be partners who need separate records. A shared office email may belong to several people.

Start with the first check before reviewing which record looks fuller.

Check the person

Compare several identity fields together:

• full name, including a middle initial or suffix;
• primary and alternate email addresses and phone numbers;
• current and prior mailing addresses;
• organization, household, relationship, or external-system identifiers;
• notes that explain a name change, shared contact point, or prior import.

One matching field is not enough when that field can be shared. Use the evidence to classify the pair:

• Same person: continue to the money check.
• Related people: keep separate contacts and link them if your system supports relationships or households.
• Lookalikes: mark them as not duplicates so the same pair does not return to the queue.
• Unclear: hold the pair and name the person who can decide.

Do not solve a household-model problem by collapsing two people into one donor. That may simplify the contact count while making gift ownership, acknowledgments, and future communication harder to explain.

Check the money

Next, map every financial object attached to both records. Review gifts, pledges, recurring schedules, refunds or disputes, receipts, designations, and processor or import identifiers. Choose the surviving record only after you know where each object will go.

Merge behavior varies by platform. DonorPerfect's current duplicate-management documentation says its merge carries gifts, pledges, contact history, alternate addresses, email addresses, phone numbers, and flags into the final record. Salesforce describes its contact merge as irreversible and recommends a backup before merging. Your system may preserve a different set of fields.

Run a small before-and-after test before a bulk cleanup:

1. Export or record the two contact IDs and the objects attached to each.
2. Note gift count, gross gift total, active recurring schedules, and receipt count.
3. Merge one confirmed pair in a safe, recoverable way supported by your vendor.
4. Confirm the surviving contact has the expected objects and totals.
5. Keep the test record with the cleanup notes.

Stop when a recurring schedule, receipt owner, designation, or external identifier has no documented destination. The operator should surface that exception, not invent the policy that resolves it.

Check the permissions

The fuller record is not automatically the right master. Compare email and SMS status, preferred channel, recognition name, anonymity choice, mailing preference, and any contact-level suppression your team relies on.

Do not keep the most permissive value merely because it allows another message. Preserve the choice your system and policy identify as controlling. If two records conflict and the correct value is not documented, pause the merge for the person responsible for communications or data governance.

This check also covers ownership. Record who reviewed the pair, who approved an exception, and which contact ID survived. A later operator should be able to explain why two records became one without reconstructing the decision from timestamps.

Use a four-outcome queue

Keep the cleanup queue short and decision-based. Each row needs the two contact IDs, matching fields, proposed outcome, owner, next action, and final date.

The four outcomes are enough:

• Merge only when person, money, and permission all pass.
• Link when the contacts are related but distinct.
• Not duplicate when the similarity is coincidental.
• Hold when identity, financial ownership, or communication status remains unclear.

DonorPerfect exposes a similar operational distinction in its product: combine, create a link, mark as not duplicate, or save for later. The framework here is platform-neutral, so use your CRM's documented controls rather than translating every outcome into a delete or merge action.

CharityStack's current pricing comparison lists unlimited contacts on every plan and contact merging on Base and Plus. When you evaluate donor management workflows, test one complicated pair—not two empty test contacts—and confirm what happens to gifts, subscriptions, receipts, identifiers, and communication choices.