The Donation Reconciliation Report: Connect Every Gift to the Bank Deposit

A donation reconciliation report connects four records that answer four different questions: the gift in the constituent relationship management system (CRM), the processor transaction, the payout batch, and the bank deposit. The goal is not to force all four totals to look identical on the same day. It is to prove how each gift moved through the chain, explain legitimate differences, and isolate the exceptions that still need action.

That distinction matters because fundraising and finance can both have accurate records while still seeing different totals. A CRM may organize gifts by donor and campaign. A payment processor may organize transactions by settlement activity. A bank statement may show one net deposit for a batch of gifts after fees, refunds, and adjustments. A useful report preserves those differences and reconciles the handoffs between them.

What is a donation reconciliation report?

A donation reconciliation report is a control view that traces gifts from the fundraising record to the cash received. It shows whether each expected record exists, whether the relevant amounts agree under documented rules, and where the first unexplained break occurs.

The report should answer five operational questions:

Does every successful processor transaction that represents a gift have one valid CRM gift record or a documented set of split allocations?
Do CRM gift amounts, statuses, campaign codes, and designations agree with the source transaction?
Can every automatic payout be explained by its included transactions, fees, refunds, disputes, and other adjustments?
Did each expected payout arrive in the correct bank account?
Which differences are timing items, documented adjustments, coding problems, or unresolved exceptions?

This is a reporting and workflow framework, not accounting advice. Finance should define the organization’s posting, period-close, and revenue-recognition policies. The report’s job is to make the underlying records and differences visible enough for those policies to be applied consistently.

Keep the four donation records separate

The most common reconciliation mistake is comparing records that describe different stages of the same money movement. Start by giving each record a clear job.

1. CRM gift record

The CRM gift record explains the fundraising relationship. It should identify the donor or constituent, gross gift amount, gift date, campaign or appeal, designation, payment method, gift status, and the source transaction identifier when available.

2. Processor transaction

The processor transaction explains what happened to the payment. It should show the processor transaction ID, gross amount, status, currency, fees, and any connection to a refund or dispute. A submitted donation is not the same as a successful transaction, and a successful transaction is not yet proof that cash reached the bank.

3. Payout batch

The payout groups processor activity sent toward the organization’s bank account. For automatic payouts, Stripe’s current documentation says its reconciliation report can identify the balance transactions included in a payout and break them into gross amounts, fees, and final amounts. It also notes that manual payouts do not provide the same explicit transaction-to-payout connection. Your report should therefore record the processor, payout method, and the evidence available for the specific account rather than assuming every platform behaves the same way.

4. Bank deposit

The bank deposit is evidence that the net payout arrived. Record the posted date, amount, account, bank reference, and matched payout ID. One deposit can represent many gifts, so a one-gift-to-one-bank-line match is usually the wrong model for online giving.

Use two bridges instead of one forced match

A reliable donation reconciliation report uses two separate bridges.

Bridge A: CRM gifts to processor transactions

This bridge tests gift-record completeness and fundraising classification. Match on a stable processor transaction ID whenever possible. Use date, amount, donor details, or campaign context only as controlled fallback evidence, and mark the match method so staff can distinguish an exact identifier match from a probable one.

The bridge should expose:

successful processor gifts missing from the CRM;
CRM gifts with no valid processor transaction;
duplicate CRM gift records;
amount, currency, status, campaign, or designation mismatches; and
records that require a documented offline or non-processor path.

Bridge B: processor payouts to bank deposits

This bridge tests cash settlement. Reconcile at the payout level, not by donation date. The basic control equation is:

Successful transaction gross – refunds – disputes – fees +/- other documented adjustments = expected net payout

Then compare the expected net payout with the bank deposit. Keep transaction dates, payout dates, and bank-posting dates in separate fields. A difference caused by a legitimate settlement delay should not be labeled an error, but it should remain open until the deposit arrives.

Give every difference one reconciliation status

Totals alone do not create an actionable report. Each unmatched item needs one mutually exclusive status based on the first broken handoff:

Status	Meaning	Next action
Matched	The required records exist and agree under the documented rule.	Close the item and retain its identifiers.
Timing difference	The record or cash is expected, but the normal settlement or posting window has not ended.	Monitor until the expected date; escalate only after the window expires.
Documented adjustment	A fee, refund, dispute, foreign-exchange effect, or other supported activity explains the amount difference.	Confirm the adjustment is classified consistently and linked to its source.
Coding mismatch	The money is accounted for, but campaign, designation, donor, status, or another fundraising field disagrees.	Route to the owner of the source record and preserve the correction history.
Unresolved	The expected record, amount, or deposit cannot yet be explained.	Assign an owner, due date, materiality level, and investigation note.

Do not use “other” as a permanent status. If a new recurring difference appears, define it in the organization’s reporting rules registry and decide whether it belongs inside one of the existing statuses or requires a controlled rule change.

A worked donation reconciliation example

Suppose a processor payout contains $12,500 in successful gifts. Its activity also includes a $300 refund and $335 in processing fees.

$12,500 – $300 – $335 = $11,865 expected net payout

The bank shows an $11,865 deposit with the matching payout reference. Bridge B is reconciled.

Before review, however, the CRM shows $12,650 in gifts linked to the batch. The $150 difference is not a processor fee problem because CRM gift gross should first be compared with successful gift gross, not with the net bank deposit. Record-level review finds one duplicate $200 CRM gift and one successful $50 processor gift missing from the CRM.

$12,650 – $200 duplicate + $50 missing gift = $12,500 corrected CRM gross

Now Bridge A ties at $12,500, and Bridge B explains how that gross activity became an $11,865 bank deposit. The report also preserves the campaign and designation fields for the corrected records instead of reducing the exercise to a single cash total.

Metrics that make reconciliation manageable

Use a small set of metrics that point to work, not a wall of financial summaries:

CRM match rate: successful gift transactions with one valid CRM gift record or a documented allocation set divided by successful gift transactions in scope.
Reconciled payout rate: payout batches matched to a bank deposit with all included activity explained, divided by payout batches due in the period.
Unresolved variance: the dollar value still lacking sufficient evidence, shown separately for the CRM-to-processor and payout-to-bank bridges.
Oldest unresolved age: elapsed days since the first expected record or deposit became overdue under the organization’s rule.
Classification completeness: matched gifts with the required campaign, appeal, designation, and donor context divided by matched gifts in scope.

Show counts and dollars together. One high-value unresolved gift may be material even when the match rate rounds to 100%, while many small coding errors may reveal a workflow problem even when the dollar variance is low.

Minimum fields for the report

At minimum, retain:

CRM gift ID and processor transaction ID;
payout ID and bank reference;
gift, transaction, payout, expected-arrival, and bank-posted dates;
gross amount, fee, refund, dispute, other adjustment, expected net, and deposited amount;
currency and destination bank account identifier;
donor or constituent ID, campaign, appeal, designation, and payment method;
match method, reconciliation status, exception owner, due date, and resolution note; and
source refresh time and the report’s as-of timestamp.

Because the sources update on different clocks, pair this report with a fundraising data freshness view. A payout that has not arrived yet may be normal at 24 hours and overdue at five business days, depending on the processor and the organization’s documented expectation.

Decide when fundraising totals are ready to release

Use a three-level release rule tied to the decision the report will support:

Ready: both bridges reconcile, or remaining items are below the approved threshold and do not change campaign, designation, donor, or cash conclusions.
Explainable: one or more timing differences or documented adjustments remain open, but their amount, owner, expected resolution date, and decision impact are visible.
Blocked: an unresolved item could materially change cash received, donor credit, campaign performance, designation, or the reporting period.

The threshold should be defined by finance and fundraising leadership for the specific use. A weekly campaign pulse can tolerate more open timing items than a month-end close or board report. Before release, run the organization’s fundraising report preflight so the reconciliation status, source cutoffs, and remaining exceptions travel with the number.

How ReportWerks supports the workflow

Reconciliation becomes difficult when gift records, processor activity, campaign codes, and reporting notes live in separate exports. ReportWerks brings fundraising, marketing, and performance data into connected reporting views. For this workflow, the useful outcome is a shared control view that keeps source identifiers, campaign context, freshness, and exception ownership beside the totals.

The reporting layer should not silently change finance policy or pretend that uncertain matches are exact. It should make the chain inspectable: which gifts matched, which payout explains the deposit, which differences are legitimate, and which records still need a person to act.

Start with one payout and make the chain auditable

Do not begin by trying to reconcile every platform and every historical gift. Choose one processor, one bank account, and one completed payout. Preserve the four identifiers, calculate the two bridges, assign every difference a status, and document the release decision.

Once that single chain works, repeat it. A strong donation reconciliation report turns month-end detective work into a visible operating process and gives fundraising and finance one answer they can both explain.