Use one intake packet for every nonprofit gift

A reliable nonprofit gift processing workflow starts with one intake packet for each gift. Capture the source evidence once, give the gift a stable identifier, then review two kinds of facts: the money facts and the donor-context facts. Close the gift only when both decisions are visible.

That approach is more useful than asking whether finance or fundraising “owns” gift entry. Your org chart can vary. The handoff still needs to preserve the same facts.

Capture six parts once

The intake packet can be a record in your fundraising system, a batch row with attachments, or a controlled form. It needs six parts:

1. Source evidence: the form submission, processor record, check image, remittance note, or import row that shows where the gift came from.
2. Stable gift ID: one identifier that follows the gift into reviews, exports, and exception notes.
3. Money facts: amount, date received, payment method, payment status, and processor or check reference.
4. Donor identity: the contact your team believes made the gift, plus the source identifier used to reach that conclusion.
5. Designation and source: the fund, campaign, event, appeal, or other coding your organization actually uses.
6. Communication cues: an address change, memorial note, sponsorship detail, delivery preference, or other source material that someone must review.

Capture evidence before translating it into database fields. If a mailed form says “use my new address,” preserve the form and record the proposed change. If an import calls a fund by an outdated name, keep the source value beside the mapped value. A later reviewer should be able to see what arrived and what your team decided.

This packet should stay small. Do not add fields merely because a system offers them. A field belongs here when it helps identify the gift, validate the money, route donor context, or resolve an exception.

Route money facts and donor context separately

The packet now enters two review lanes.

The money lane validates the amount, payment state, received date, payment reference, deposit or payout connection, and the financial coding your policy requires. The donor-context lane validates the contact, designation, campaign attribution, correspondence, and next donor-service action.

Those lane names describe decisions, not departments. Finance may handle the money lane and fundraising the donor-context lane. An operations lead may handle both. On a one-person team, use two explicit checkpoints at different times so “I entered it” does not silently mean “I verified every part.”

Keep the two decisions attached to the same gift ID. Blackbaud's current gift-batch documentation gives every gift in a batch a shared batch ID and supports review before approval. Its automatic batches can also be grouped by source, date, payment method, and payment configuration. Your system may use different labels, but the useful principle is stable: group the work without losing the identity of each gift.

Neither lane should overwrite the other lane's uncertainty. If the payment is valid but the designation is unclear, keep the payment facts and hold the designation. If the donor is known but the payment is still pending, keep the contact link and the live payment status.

Hold the exception, not the whole process

Give every unresolved gift one hold reason, one owner, and one next check. Use a short list:

• source evidence missing;
• payment fact mismatch;
• donor identity unclear;
• designation or campaign unclear;
• policy review required.

Do not write “needs research” and return the item to a general inbox. Name the unresolved fact. The money lane may be able to close while the donor-context lane remains open, or the reverse.

Batch tools make this distinction visible. Salesforce's current Nonprofit Cloud gift-batch workflow supports a dry run before processing and exposes the entries and results behind failed or partially processed batches. Use that kind of check to locate the record that needs attention. Do not re-review every clean gift because one row failed.

Set a boundary for what “closed” means in your own system. At minimum, both lane decisions should be recorded, required source evidence should be attached or linked, and any remaining downstream task should have an owner. Your accountant or adviser should define accounting treatment, internal controls, receipt policy, and retention rules.

Keep correspondence with the gift

Money can arrive without the context that fundraising needs. A check image may have an address correction on its envelope. A workplace-giving file may use an identifier your contact database does not recognize. An online form may carry a fund choice and a note that never appears in the bank record.

Do not solve that problem by copying details into several spreadsheets and email threads. Preserve the source once, give the people responsible for each lane appropriate access, and record the decision on the gift packet.

The packet is complete when a teammate can answer four questions without reconstructing the handoff:

• What arrived?
• Which donor record and designation did we use?
• Which payment facts were validated?
• What remains open, and who owns it?

If the answer depends on finding the right inbox, the packet is not doing its job.

Test five gifts before changing the workflow

Use real-shaped test records rather than five identical online gifts:

1. A completed online gift with a clean contact match and fund selection.
2. A mailed check with a note and an address change.
3. A payment whose amount is valid but whose designation is ambiguous.
4. A gift where the payment source and the recognized donor need separate review under your policy.
5. A five-gift batch in which one entry has a missing or invalid field.

For each case, confirm that source evidence remains available, the gift keeps one identifier, each lane records its decision, and the exception has an owner. The fifth case passes only when the bad row is visible and the team knows whether clean rows can move under the platform's documented behavior.

Use the packet to evaluate your system

CharityStack's current start guide separates Forms, Payments, Contacts, Subscriptions, and Payouts. It also recommends configuring funds, custom inputs, receipt settings, permissions, and payout setup before launch. Those are the records and settings a gift intake test should exercise.

When you compare systems, submit one gift through fundraising checkout, then follow it through fundraising operations. Check whether source details, contact, payment, receipt, and payout remain connected without forcing one person to translate the gift twice. CharityStack's current site says those records stay tied to every gift.