Understanding Split Gifts in Humanitru

"Split gift" is a term donors and development staff use to describe a single contribution that's meant to support more than one thing at once. A donor writes one check for $1,000 but wants $600 to go to the Annual Fund and $400 to a capital campaign. A corporate matching gift comes in as one lump sum on behalf of several employees. A membership renewal and an event ticket get paid together on the same card swipe. In every case, one payment is doing the work of multiple designations, funds, campaigns, or even multiple donors.

Because this comes up constantly in day-to-day gift entry, it's worth being clear on what the term means, how other platforms have historically handled it, and why Humanitru takes a deliberately different approach.

In practice, the phrase covers a few related but distinct scenarios:

• Splitting across designations — one payment divided between multiple funds, campaigns, or appeals (e.g., $300 to Annual Fund, $200 to Capital Campaign).
• Splitting across GL codes — the accounting-side version of the above, where a single transaction needs to post to more than one general ledger code.
• Splitting across purposes — one payment covering two different types of activity, such as a membership renewal bundled with a ticket purchase or a donation.
• Splitting across constituents — a single lump-sum payment (most commonly workplace giving platforms like Benevity) that represents contributions from multiple individual donors and needs to be attributed to each of them.

Whatever the flavor, the underlying ask is the same: one payment, more than one place for the money — and the reporting — to land.

Platforms like Raiser's Edge built split gifts as a native, first-class feature: a single gift record can carry multiple designation line items, each with its own GL coding and its own soft-credit calculation, all tied back to one parent transaction. This is powerful in that it keeps one payment as one record. It also means the reporting and GL export logic has to account for a single transaction fanning out into multiple downstream destinations — which is exactly the kind of complexity that tends to produce inconsistent exports when integrations, plugins, or custom reports don't all handle the fan-out the same way.

Humanitru intentionally does not recommend that a single Action carries more than one designation or more than one GL code. Instead, every designation gets recorded as its own separate Action, and those Actions are linked together using a shared reference point — most commonly a Check # or a Transaction/Order # (which many integrations populate automatically).

So the same $1,000 check above becomes two linked Donation Actions: one for $600 coded to the Annual Fund, one for $400 coded to the Capital Campaign. A membership-plus-ticket payment becomes one Membership Action and one Ticket Action, linked the same way.

This is a deliberate architectural choice, not a workaround:

• One credit GL code and one debit GL code per Action means every GL export and integration behaves predictably, every time — there's no fan-out logic for a report or integration to get wrong.
• Clean, individually reportable records. Each Action can be pulled, filtered, and reported on independently, without needing to first "unpack" a multi-line gift.
• Consistency across data entry and integrations. Whether a gift comes in through a staff member's manual entry or through an integrated payment platform, it follows the same one-designation-per-Action pattern.

• Pick one linking convention and use it every time. Check # works well for physical checks; a Transaction/Order # (often populated automatically by integrations) works well for electronic payments. Consistency is what makes it possible to reconstruct the full picture of a payment later.
• Use Action Notes to explain the link. A short note noting that an Action is one part of a linked payment helps any staff member who later looks at the record in isolation.
• Use Blueprint Actions to keep data entry consistent across staff whenever a gift needs to be split or a payment needs to be recorded as linked Actions.
• Use Smart Automations to help route linked Actions to the correct credit/debit GL codes, reducing manual entry error.