A couple buys a family membership at the front desk. The husband’s card pays for it, but the wife is the one who has been giving to your annual fund for ten years, and she is the one your development director wants on the donor wall. Six months later someone pulls a giving report, and her lifetime total looks short. The revenue is in Altru. It’s credited to the wrong person.
That’s a recognition credit problem. Fixing it is easy in some places and harder in others, depending on how the revenue got into Altru in the first place.
Revenue credit vs. recognition credit
Every payment in Altru belongs to one constituent: the one who actually paid. That doesn’t change, and it shouldn’t, because it ties back to the money, the batch, and your general ledger.
Recognition credit sits on top of that. It answers a different question: who should get credit for this gift in giving totals, donor listings, and stewardship? A gift paid from a joint account, a donor-advised fund, or a company can be recognized to one or more other people without changing who paid. Recognition credit usually does not affect your accounting, so correcting it is a cleanup for your reporting, not your finance office.
Before you edit anything, agree internally on what recognition means at your organization. Do household members share credit? Does the member or the payer get credit for a gift membership? If two staff answer that differently, the records will keep drifting no matter how often you fix them.
Editing recognition on a donation or pledge
This is the simple case. For revenue entered directly as a donation or pledge, you can open the revenue record from the constituent’s revenue history and edit its recognition credits. Typically you can:
- Add another constituent as a recognition recipient.
- Change the amount or split credit between people.
- Remove a recognition credit that was applied by default and shouldn’t have been.
If your system applies recognition automatically (for example, to a spouse in the same household), check those defaults first. Fixing the default saves you from fixing every future gift by hand.
Memberships: decide who “owns” the credit
Memberships are where most of the confusion starts, because three different people can be involved: the payer, the primary member, and the other members on the card. A gift membership makes it even more obvious. The giver paid, but the recipient is the member.
Look at a handful of recent membership transactions and see who ended up with recognition credit in each case: a straight purchase, a renewal, a gift membership, and one paid by a household member other than the primary. That tells you more than any setting description will. If the results don’t match your policy, compare them against your membership program configuration and your recognition defaults, and test changes in a sandbox before touching production.
For memberships entered through the back office as revenue, recognition can usually be edited the same way as a donation. Memberships sold through daily sales, advance sales, or online are a different story.
Sales orders: the hard part
Revenue that comes in through a sales order (the front desk, advance sales, or a web form) is created by the sales process, not entered as standalone revenue. In our experience, the recognition credit editing that’s available on a regular donation is limited or not available for those payments, and how much you can change seems to depend on the transaction type and your Altru setup. We aren’t certain of the exact behavior in every configuration, so confirm it before you plan around it:
- Find a recent sales order that included a membership or donation and open its revenue from the constituent record.
- See whether a recognition edit option appears and whether it saves.
- If it doesn’t, ask Blackbaud support whether that’s expected for your version and transaction type, and whether there’s a supported workaround.
Workarounds when you can’t edit after the fact
- Get the constituent right at the register. Most bad recognition on sales orders starts with the wrong person attached to the order. Train desk staff to search for the existing record (and the right person in the household) before ringing up a membership or add-on donation.
- Take larger gifts outside the sales order. A significant donation made at the desk can be entered by development staff as regular revenue, where recognition is fully editable. Agree on a dollar threshold so staff know when to hand it off.
- Reverse and re-enter. For a gift that really matters, voiding or refunding the original and re-entering it correctly is sometimes the cleanest fix. It affects batches and possibly your GL, so coordinate with whoever reconciles revenue before you do it.
- Report around it. For stewardship lists, build a query that pulls both the revenue constituent and the household, so a gift paid by one spouse still shows up for the household. It’s not a data fix, but it keeps the wrong person off the thank-you list.
Find what’s already wrong
Don’t wait for a donor to notice. Run a revenue query for the last year that returns the paying constituent, the recognition recipients, the transaction source, and the amount. Sort for gifts where payer and recognition recipient are different, and for membership revenue with no recognition at all. Fix the high-value records first, and add a constituent note when you change credit so the next person knows it was deliberate.
Then repeat the query monthly. If the same kind of error keeps showing up from the same sales channel, that tells you where to put your training time.
Quick answers
Does changing recognition credit change the payment?
No. The payer and the amount paid stay the same. Recognition only changes who gets credit in giving totals and recognition reports.
Can recognition be split between two people?
For regular revenue, generally yes. Split the amount however your policy says, and keep the policy consistent across staff.
