Keep split donations balanced around one payment

A split donation across multiple funds should preserve the payment as the money record. Add one allocation line per fund, require those lines to equal the payment total, and carry one stable payment or group key into every connected system.

That rule keeps a split donation from becoming duplicate revenue just because an export contains multiple rows.

Start with one payment-allocation invariant

Use this pass/fail test:

One payment amount = the sum of every allocation tied to it.

Suppose a donor makes one $1,000 payment and assigns $600 to the general fund and $400 to a scholarship fund. Your records should preserve three different facts:

• Payment: $1,000 received through one transaction.
• Allocation 1: $600 assigned to the general fund.
• Allocation 2: $400 assigned to the scholarship fund.

The two allocation lines explain the payment. They do not prove that two payments occurred.

Current fundraising systems implement this relationship in different ways. ActiveDonor requires allocation rows to add up exactly to the receipt total, while Blackbaud applies the same full-amount rule to gift splits (ActiveDonor, Blackbaud). Treat that balance rule as your first control even if your own software uses different names.

If you first need to decide whether a field is a fund, campaign, or appeal, use the three-part gift-entry test. Split allocation begins after the fund meaning is clear.

Keep the money fields off the allocation lines

The payment record should own the facts that happened once:

• processor transaction or check number;
• payment date, method, amount, and status;
• donor or payer identity;
• payout and refund references; and
• the stable payment or group identifier.

Each allocation line should own only the facts that vary by designation:

• fund or program;
• allocated amount or percentage;
• allocation status when your system uses one; and
• a source row ID for imports or corrections.

This separation matters because one checkout can produce several staff-side rows. Fundraise Up, for example, documents separate donation records for designations that share a Grouped Donation ID, while Beacon uses linked split records with a shared Split ID (Fundraise Up, Beacon).

Do not count exported rows and call that the number of payments. Group first by the processor transaction, original payment ID, or documented group key. Then sum the allocation lines inside that group.

Test the donor and staff views together

One bank charge can coexist with several designation rows. Tithely documents one transaction with separate fund line items, while Fundraise Up documents one payment process and a consolidated first receipt even though each designation creates a donation record (Tithely, Fundraise Up).

Before you enable a split-fund path, run one controlled gift and inspect all six places:

1. The donor chooses the intended funds and amounts.
2. The payment method shows one expected total charge.
3. The confirmation and receipt show the correct total and useful allocation detail.
4. The fundraising platform preserves one payment identity.
5. The CRM or export keeps every allocation tied to that identity.
6. The payout and reconciliation view can return the allocation rows to the original payment.

Record the expected value and actual value for each checkpoint. A successful checkout is not enough if the CRM later imports two ungrouped gifts. Apply the same source-key discipline used to prevent duplicate donation imports.

Treat edits and refunds as separate tests

Do not assume the platform that accepts a split donation will edit, recur, or refund it the way you expect. Current vendor behavior differs materially. Fundraise Up documents an all-designation refund for a multiple-designation payment, while Tithely documents refunding an individual fund line; their recurring behavior also differs (Fundraise Up, Tithely).

Before staff changes a live split gift, verify the platform's current behavior and answer four questions:

• Does the action change an allocation, the payment, or both?
• Will the donor-facing receipt or history change?
• Will connected systems receive an update or a new row?
• Which identifier will let reconciliation find the original transaction?

If your team cannot answer those questions, hold the edit and assign one owner to test the path. Do not repair an allocation mismatch by entering another payment.

Close only when the group balances

A split donation is ready to close when the donor charge, payment record, receipt total, allocation sum, CRM group, and downstream reconciliation evidence agree. The allocation count may differ across systems; the payment identity and total must not.

Use your normal donation-to-deposit reconciliation after the split passes this internal check. Keep legal, tax, accounting, restricted-fund, and receipting decisions with the qualified people and policies that own them.