Build the donor list from gifts, not a contact export

Build a nonprofit donor recognition list from qualifying gifts received during one defined period, not from a general contact export. Apply each donor’s public-recognition choice before combining households or assigning levels. Then run two proofs: every published line must map to an eligible gift, and every eligible gift must map to a line or a documented exclusion.

That sequence keeps three different facts from collapsing into one field: who made the gift, how the donor wants to be named publicly, and whether the gift belongs in this particular list.

Define the list before you export it

Write a short list contract that another staff member can follow. It should state:

• the first and last gift dates;
• which received gift types, funds, or campaigns qualify;
• whether recognition levels use one gift or the donor’s combined eligible gifts;
• where the list will appear; and
• who approves exceptions and the final proof.

Do this before choosing names. A current public annual-report example from Greenbelt defines which gift categories belong in its list and groups the resulting names by level. Your policy may differ. What matters is that the rule exists before the first export, so a familiar donor is not included or promoted by memory alone.

If your organization has decided not to publish donor names, stop here. A donor database does not create a reason to publish an honor roll.

Start with qualifying gifts

Create the working file from eligible gift records. Keep a stable gift ID, received date, amount used for recognition, fund or campaign when relevant, donor record ID, and current recognition instruction.

Do not begin with “all active donors.” A contact can be active without having an eligible gift in the period. The reverse can also happen: an eligible gift may belong to an organization, a donor-advised fund sponsor, or a person whose contact record needs review. Starting with gifts gives every candidate line a traceable source.

Next, aggregate only as your list contract permits. If levels use combined giving, calculate them from the qualifying rows and preserve the underlying gift IDs. Do not replace the source rows with a typed total.

Apply recognition choices before formatting names

Public recognition is a separate decision from receiving and acknowledging a gift. The National Council of Nonprofits notes that donors may look for their names on public lists and may also be unhappy if a request for anonymity is missed.

For each candidate, resolve these fields in order:

1. Public, anonymous, or not yet confirmed.
2. Exact publication name for this list.
3. Individual, household, or organization presentation.
4. Recognition level produced by the list rule.
5. Source and effective date of the instruction.

Keep the publication name separate from a mailing salutation and from the legal or payment name. Practitioners in the Blackbaud community describe collecting preferred listing names and anonymous choices, sometimes for a specific campaign, and using a draft list to resolve changes before publication.

If two people are connected by a household record, do not assume they want a combined public name. Preserve individual gift ownership as described in the donor household workflow, then use a documented recognition choice for the public line.

Put ambiguity in an exception queue

Do not let an uncertain row silently inherit a default. Give it an owner, a reason, and a due date. Useful exception reasons include:

• no recognition choice on file;
• conflicting anonymous instructions;
• publication name differs across recent campaigns;
• household or organization presentation is unclear;
• eligible gifts appear under duplicate contacts; or
• the calculated level changes after a refund or correction.

An anonymous instruction should stay attached to the gift or recognition context that created it. The anonymous donation record workflow explains why “anonymous” should not become a catch-all identity. For the public list, an unresolved privacy conflict means hold the name, not guess.

Run the proof in both directions

A spelling review is useful, but it cannot find every structural error. Run two reconciliations against the frozen candidate file.

First, move from publication to source. Every line in the proof must map to eligible gift IDs, the applied recognition rule, and a resolved publication name. This catches extra names, unsupported levels, and typed additions that bypassed the data.

Second, move from source to publication. Every eligible gift must map to a published line or a documented exclusion such as anonymous, withheld pending confirmation, or outside the approved recognition scope. This catches missing names and dropped rows.

Nonprofit operators discussing annual reports repeatedly emphasize checking donor names and levels. The two-way proof makes that review testable: reviewers are not only scanning a long page and hoping a familiar name looks right.

Freeze the approved snapshot

Once exceptions are closed, save the approved source export, calculation date, proof file, and approver together. Send the publication team the frozen list, not a live spreadsheet that can change after signoff.

After layout, rerun the publication-to-source proof on the rendered page. A correct spreadsheet can still become an incomplete document if a row is dropped during sorting, design, or pagination. Publish only when the rendered list matches the approved snapshot and every late change has an owner.