You refund a membership payment and the money side looks right. The revenue record shows the refund and the batch balances. Then you open the constituent and the membership history still lists a “Join” or “Renew” for a purchase that has been fully reversed. Anyone reading that record later will reasonably assume the person paid for that term.
The cause is that Altru keeps revenue and the membership as related but separate records. A refund changes the revenue. It doesn’t automatically rewrite the membership’s transaction history. Below is how to think about the gap, what you can do about it, and how to keep your membership numbers honest while it exists.
Why the action survives the refund
When someone joins or renews, Altru records two things: the payment (revenue) and the membership transaction (the join, renew, upgrade, or rejoin that set the level and dates). A refund is a revenue event. It reverses money. It doesn’t necessarily decide what should happen to the membership, because that depends on the situation:
- A member who changed their mind and wants out entirely: the membership should end.
- A duplicate charge where the member really did renew once: one transaction should stay and the other should go.
- A comp or goodwill refund where the member keeps their benefits: the membership should stay as it is.
Because one refund can mean three different things, the membership side is mostly left to staff. Exactly what your version of Altru does here, and which options appear during a refund, depends on your release and your security roles. Before you write a procedure, check this in a sandbox or with Blackbaud support. Don’t assume.
Decide what the record should say first
Before you touch anything, settle which of these outcomes you want. Most cleanup mistakes come from picking a mechanism before deciding on an outcome.
The member is out
Cancel the membership rather than trying to make the transaction vanish. A canceled membership tells future staff the truth: this person joined, asked for their money back, and isn’t a member. Card access, member pricing, and renewal mailings should all key off that status. Use a cancellation reason that makes the refund obvious, and add a note on the constituent record that references the refund date.
The transaction should never have existed
Duplicate charges and test transactions are the real case for removing the action itself. Depending on permissions, Altru may let you delete a membership transaction, or it may only let you do that when no revenue is still tied to it. If your role can’t do it, that is usually deliberate. Find out who in your organization holds that right and send these cases to them rather than widening access for everyone.
The member keeps their benefits
Leave the membership alone and document the refund. A note explaining why money went back while the membership stayed active will save someone a confusing phone call next year.
Order of operations matters
Altru sometimes blocks a change to one record because another record still depends on it. A sequence that avoids most dead ends:
- Process the refund and confirm it posted correctly in revenue and in your batch.
- Pull up the constituent’s membership and look at which transactions are tied to the refunded payment.
- Apply the membership outcome you decided on: cancel, remove the duplicate transaction, or leave it.
- If the member had been upgraded or renewed by this transaction, check that the level and expiration date now reflect what they actually paid for. Fix those by hand if needed.
- Add a note to the constituent record so the history makes sense to whoever reads it next.
If a step won’t save, read the error closely. It usually names the dependent record. Work through it rather than forcing a workaround such as editing amounts to zero, which leaves the books and the membership disagreeing in a new way.
Keep reports from counting refunded joins
Even with good habits, some refunded transactions will slip through. Protect your numbers with queries rather than relying on everyone remembering the cleanup:
- An exception query. Build a membership transaction query for the last 30 to 90 days and include the related revenue, then filter to transactions whose payment has been refunded. Anything on that list with an active membership needs a decision. Run it weekly or before monthly reporting.
- Adjust your membership counts. If your board reports count new joins or renewals from transaction history, check whether those reports exclude refunded revenue. If they don’t, build the count from a query that does, or note the adjustment in the report.
- Watch your renewal mailings. A refunded member who still looks active can drop out of lapsed-member outreach, or get a “thanks for renewing” email they won’t understand. Run your communication selections against the exception query before a big send.
Write it into your refund procedure
The lasting fix is procedural. Wherever your staff handle refunds, whether at the front desk, in the membership office, or in finance, the refund steps should end with a membership check: “Is this a membership payment? If yes, what happens to the membership?” One line on the refund checklist prevents most of these records from ever going stale.
Make sure finance and membership agree on who owns that step. Refunds are often processed by people who never open the membership side, and membership staff often don’t know a refund happened until a member calls.
Quick answers
Does refunding the payment cancel the membership?
Don’t count on it. Confirm in your own Altru environment. Treat the membership outcome as a separate step unless you’ve verified otherwise.
Should I cancel or delete?
Cancel when the person really joined and then backed out, because that history is true. Delete only when the transaction was an error, such as a duplicate or a test, and only if your permissions and Altru allow it.
