Almost every donor-data problem a small team hits eventually traces back to one decision: whether the system has one identity per gift or four related ones. Here is the model that holds up, described in terms of the documents it protects.
Legal donor — who the receipt belongs to
The legal donor is the entity entitled to the tax receipt. It is determined by whose funds were given, not by who filled in the form. If a gift comes from a donor-advised fund, the legal donor is the sponsoring organisation. If it comes from a family business account, the legal donor is the business.
This field drives the receipt name, the tax identifier where relevant, and the year-end statement grouping. It should be difficult to change and always audited.
Payer — whose card or account moved
The payer is the payment instrument's owner and the identity your processor will show on a dispute. It is often the same person as the legal donor, and when it is not, treating them as the same field silently rewrites your donor record.
Practical consequence: a board member paying for a colleague's table, a spouse's card on a joint gift, a business card used for a personal gift. Store the payer separately and the relationship survives.
Recognition — how the gift is named in public
Recognition is a preference, not a fact derived from the other fields. 'The Alvarez Family', 'Anonymous', 'In memory of R. Chen' — donor walls, annual report listings, leaderboards and impact updates should all read from this one place.
The failure mode when recognition is derived rather than stored is well known: a donor asks to be anonymous, one report honours it, and another does not.
Household — who receives one mailing
A household groups constituents who should get one envelope, one salutation and one year-end statement. It is a communication and statement construct, not an ownership construct: two spouses each have their own giving history and their own legal-donor identity, while sharing a household salutation and address.
Household totals are useful for stewardship and dangerous for receipting. Keep them clearly separate.
Soft credit — influence without ownership
A soft credit records that someone caused a gift they did not legally make: the advisor behind a DAF grant, the board member who secured a corporate gift, the spouse in a household. Soft credits must never affect revenue totals, receipts or fund balances, and must appear in portfolio and moves-management views.
The test of a correct implementation is simple: if you sum all credited amounts across constituents and the total exceeds your revenue, that is expected. If your revenue report changes when you add a soft credit, the model is wrong.
“Recognition is a promise to the donor. Legal donor is a promise to the tax authority. They cannot share a column.”
A worked example
A $10,000 gift arrives from a family foundation. The advisor's daughter sits on your board and directed it.
- Legal donor: the family foundation. The receipt, if any, names the foundation and follows DAF rules.
- Payer: the foundation's disbursing account, reconciled as a cheque or ACH deposit.
- Recognition: 'The Alvarez Family Foundation', per the advisor's stated preference.
- Household: the Alvarez household, which receives the stewardship letter.
- Soft credit: $10,000 to the board member, visible in her portfolio, excluded from revenue.
Migrating into this model
- Do not auto-merge on name similarity. Merge on verified identifiers, and route the rest to human review.
- Import the legacy name into legal donor, then review business-named records individually — those are usually payer, not donor.
- Treat missing recognition as unset rather than defaulting to the legal name.
- Build households after constituents, never as part of the same import pass.
- Keep the source record's original identifier on every row, permanently.
Honest status
This model is implemented in the Beneora relationship module, including soft credits and duplicate review. It has been exercised with design-partner scenarios and demo data, not with a production donor file at scale.