Don’t let a fundraiser total replace the donor record

In peer-to-peer fundraising, record the gift on the person who actually paid. Keep the participant as a separate fundraiser, preserve the page or team that led to the gift, and connect those records with stable IDs. A fundraiser total is an attribution view; it should not replace the donors behind that total.

Keep four objects distinct

A useful peer-to-peer record model has four parts:

• the donor who completed the payment;
• the received gift, including amount, date, status, and transaction ID;
• the participant who created or shared the fundraising page;
• the page or team that connects the gift to the participant and campaign.

Current vendor reports support this separation. Give Lively provides one export for fundraiser contact information and another for the donors who gave through a fundraiser's page (Give Lively fundraiser and donor exports). Its broader donor report keeps donor name and payment fields beside page type, page URL, team ID, and fundraiser ID (Give Lively donor-data fields). Blackbaud's current peer-to-peer detail report similarly includes donor information and creator information in the transaction view (Blackbaud peer-to-peer guide).

Those products use different schemas. The shared operating lesson is narrower: the person who asked and the person who paid can both matter without becoming the same contact or owning the same gift.

Preserve five IDs before importing totals

Start with identifiers, not display names. When the source provides them, preserve:

1. donor or supporter ID;
2. transaction, order, or line-item ID;
3. fundraiser or participant ID;
4. page or team ID;
5. campaign ID.

Use the transaction ID to prevent a repeated export from creating the gift twice. Use the other IDs to maintain relationships even when a participant changes a page title, a donor changes an email address, or two people share a name.

This is the same discipline behind giving every fundraising link one stable source key: keep attribution data attached to the received gift without asking the source field to become donor identity.

If your export provides only names, keep the source row and mark the match confidence. Do not merge a donor and fundraiser because one email address or household name happens to match. Apply the identity checks from the duplicate donor record workflow before joining contacts.

Hold incomplete rows instead of guessing

Some peer-to-peer channels send donor-level rows. Others may send an aggregate payout, an anonymous donor, or a row without a fundraiser ID. Missing data changes the next action; it does not transfer ownership to the participant.

Route an incomplete row to an exception queue with:

• the source platform and report name;
• payout, transaction, or row identifier;
• amount and source date;
• known page, team, campaign, or fundraiser reference;
• the missing field and the person assigned to review it.

If the platform withheld donor identity, retain the gift with the truthful identity state your system supports. Do not invent a donor, copy the fundraiser onto the gift, or search for a person merely to make the row look complete. If an aggregate payout cannot be separated into donor gifts, preserve it as an aggregate source record until an approved process resolves the detail.

The gift intake packet can hold that source evidence and owner without letting one exception stall the rest of the import.

Report revenue, attribution, and stewardship separately

One peer-to-peer campaign needs three useful views:

• Received gifts: one row per completed gift, owned by the payer and counted once.
• Fundraiser attribution: gifts grouped by fundraiser, page, or team so you can show progress toward a participant goal.
• Participant stewardship: fundraiser contacts, page status, coaching or acknowledgment activity, and the next participant action.

Do not add the fundraiser-attribution total to the received-gift total. They are two views of the same money. Do not let a participant leaderboard become a donor report either; it answers who helped generate gifts, not who made each payment.

This separation also keeps follow-up honest. A donor may need a receipt or gift acknowledgment. A participant may need a progress update or a thank-you for organizing. Those messages have different recipients and jobs even when they refer to the same campaign.

Test one gift across the full path

Before importing a campaign, trace one real or controlled gift. Suppose Lee gives $75 through Sam's page on the River Team.

The result should show Lee as the donor on one $75 gift, Sam as the fundraiser, River Team and the page as attribution, and the campaign as shared context. Sam's page total should rise by $75, but Sam should not acquire Lee's gift history. The received-gift report should still contain one $75 payment.

Fail the test if the import creates two gifts, assigns the gift to Sam, drops the page or team, or cannot explain which source row produced the record. Fix that mapping before importing the rest of the campaign.