A soft credit should never create a second gift

For soft credits on nonprofit donations, keep one received gift attached to the person or organization responsible for its payment. Add a soft credit only when another constituent deserves recognition for that same gift, and track solicitation influence separately when your system supports it.

That rule prevents one payment from becoming two dollars in a report. It also gives your team a consistent answer when a spouse, employer, foundation contact, or board member is connected to a gift.

Keep payment, recognition, and influence in separate lanes

Start by deciding which of three facts you are recording.

1. Payment ownership answers: who or what is attached to the received transaction?
2. Recognition answers: who else should see this gift in their relationship history?
3. Influence answers: who helped ask for, refer, or secure the gift?

Salesforce Nonprofit Success Pack uses the term soft credit for a person who did not make the gift but receives recognition for it. Its donation glossary distinguishes that relationship from the direct donor. Your CRM may use different labels, so verify its model before copying this terminology into a policy.

The three-lane rule matters because a real person can occupy more than one lane across different gifts. A board member might make one gift directly, receive recognition for a household gift, and influence a friend's gift. Those events belong in the same relationship history without becoming the same kind of record.

If you are still deciding whether two contacts represent the same person, resolve that identity question before merging records. Soft credit connects legitimate records; it does not repair a duplicate contact.

Give every soft credit a five-field contract

A soft credit needs enough structure to survive a staff change and a reporting deadline. Record five fields:

• the stable ID of the received gift;
• the contact or organization receiving recognition;
• a controlled reason code;
• the full or partial amount used for recognition;
• the reports where that amount may appear.

Reason codes should describe the relationship your team actually uses, such as employer match, household recognition, or foundation contact. Do not create a new free-text reason whenever an unusual gift arrives. If the case does not fit the policy, send it to a named reviewer.

Amount also needs an explicit rule. Salesforce NPSP, for example, documents both full and partial soft credits. A full credit can recognize one constituent for the whole gift. A partial credit can divide recognition when a larger payment represents several underlying participants. That is Salesforce behavior, not a universal CRM design.

The fifth field is the safety rail. Write down whether a soft-credit amount belongs in donor-recognition, relationship, or fundraiser-performance views. It should never enter a received-gifts, payout, or bank-reconciliation total as additional money.

Follow one employer-match example

Suppose a donor gives $100, then the employer sends a separate $100 match. Those are two received payments. Keep the donor's payment on the donor record and the employer's payment on the employer record. Link the employer payment back to the employee with the recognition method your CRM documents.

A current Bonterra community discussion began with exactly this record-owner decision. The useful lesson is operational: attaching the employer's payment to the employee can make the employee's direct-giving total look larger than the money received from that person.

This example starts after the match arrives. Before payment, track the expected employer amount as a separate pending record using the employer-match workflow. Expected money, received money, and recognition answer different questions.

Put solicitation influence somewhere else

Use a solicitor, relationship, campaign-member, or referral field when the fact you need is “this person helped bring in the gift.” That preserves the donor's payment ownership and lets you define a separate report for staff or board influence.

Do not force every connection into soft credit because it is the only available field. That makes donor recognition and fundraiser performance answer each other's questions badly. If your system has no distinct influence field, document the limitation and choose one consistent workaround rather than letting each operator improvise.

The boundary is simple: soft credit should serve donor or constituent recognition. Solicitor attribution should serve fundraising-performance analysis. A team may choose a different policy, but the reporting purpose must be written before the field is used.

Audit three reports before you automate

Run one recent gift through every report that will consume it.

1. The received-gifts report should show the payment once under its payment owner.
2. The recognition report may show direct and soft-credit relationships, but each row should retain the original gift ID and credit type.
3. The reconciliation report should use transaction and payout records, with no recognition amount added to cash.

Salesforce's soft-credit rollup documentation shows why this check matters: hard-credit responsibility and soft-credit recognition can have distinct rollups inside the same system. Labels alone do not protect a custom export or spreadsheet formula.

Test one real example from every allowed reason code before turning on automatic rules. Keep the policy manual when a report cannot separate received and recognized amounts. Automation should repeat a decision your team trusts, not make an ambiguous decision faster.

Keep the policy beside gift intake

Place the three-lane rule and five required fields in your gift-processing intake procedure. The operator entering the gift should not have to reconstruct the policy from an old report.

CharityStack's current site describes contacts, receipts, outreach, subscriptions, and payouts tied to each gift. Whatever fundraising system you use, test that connection without assuming it includes a particular soft-credit feature. One received gift needs one stable payment owner; every added relationship needs a stated purpose.