A clean finance handoff starts with the gift batch

Do not close a gift batch because data entry is finished. Close it only after the expected item count and control total match, every gift has the donor and coding facts your team needs, and each unresolved item has been corrected or moved to a named exception queue.

That distinction gives development and finance a clean handoff. A reliable nonprofit gift batch process makes development prove the fundraising records are complete enough to use. Finance can then apply the organization's accounting and reconciliation procedures without rebuilding the batch from raw reports.

Start with a total that exists before data entry

A control total is the expected number and value of items in the batch before someone begins entering gifts. For checks, it may come from the scanned check packet and deposit preparation. For an import, it may come from the source file. For a processor report, it may come from a defined transaction set rather than the net bank deposit.

Record four facts at the top of the batch:

• stable batch ID;
• expected item count;
• expected gross gift total;
• source evidence and its owner.

Do not change the expected total to make the entered total pass. A current Virtuous workflow describes its batch total as a hard control, while Blackbaud's current gift-record guide calls for review of the gifts and a pre-posting control report before close. Product behavior differs, but the operating principle is portable: the comparison loses its value if the target moves after entry begins. Virtuous documents the batch control, and Blackbaud documents review before posting.

Prove more than the grand total

Two offsetting errors can leave the grand total unchanged. A $100 gift entered as $10 and a $10 gift entered as $100 still produce the same sum. Compare the item count and inspect the records that make up the number.

Each gift should pass the fields your team has defined as required for use after close. That usually includes a donor or documented unknown-donor treatment, amount, gift date, payment method, fund or designation, source reference, and acknowledgment state. Add campaign, appeal, soft-credit, tribute, or restriction facts only when the source evidence supports them.

The batch is not the place to guess. If a check says “programs” but your system requires a narrower fund, keep the gift in an exception state and assign the coding question. Do not choose the closest label to clear the queue.

This closeout begins after the gift intake packet has preserved the source evidence and separated money facts from donor context. It does not replace that intake review.

Remove exceptions from the close path

An unresolved gift should not disappear inside a balanced batch. Give each exception one of three outcomes:

1. Correct now. Fix the record from the source evidence, then rerun the batch checks.
2. Move and own. Remove the item from this closeable batch, preserve its source reference, and assign an owner and next action in an exception queue.
3. Split the batch. When unrelated deposits or source files were combined, rebuild smaller batches whose control totals can be proved independently.

Current Salesforce Nonprofit Cloud documentation treats gift-entry processing as a workflow with batch imports and inspectable processing results. That is a useful boundary even when your software looks different: processing success does not establish that a gift is complete, and one failed item should remain visible instead of becoming an unexplained difference. Salesforce documents gift-entry processing.

Do not close a batch with a note that says only “timing” or “research later.” Name the item, the difference, the owner, and the next check. The closed batch should contain only records that passed; the exception queue should contain everything that did not.

Preserve the handoff finance can trace

When the checks pass, export or retain a batch report before close. It should show the batch ID, item count, gross total, gift-level records, coding fields used for the handoff, preparer, reviewer, close time, and any linked deposit or processor reference.

This is not the bank reconciliation itself. Online gifts may be grouped into payouts, reduced by fees, or deposited on a different schedule. The later gift-to-deposit reconciliation still needs the gift, processor transaction, payout, and bank-deposit chain.

After close, do not quietly reopen history to repair a mistake. Use the correction method your system and organization support, preserve what changed, and send the corresponding adjustment to the handoff owner. The point is not to make batches impossible to correct. It is to keep the correction visible to everyone who relied on the original close.

Use a three-proof close decision

Before closing, ask for three observable proofs:

• Arithmetic proof: expected and entered item counts and gross totals agree.
• Record proof: every included gift has complete, source-supported donor and coding facts.
• Handoff proof: the saved report and reference let another person trace the batch without reconstructing it.

If any proof fails, the batch is still open. If all three pass, close it and let the preserved evidence—not a raw-report scavenger hunt—carry the work forward.