A cashier refunds the wrong order. A volunteer processes a refund twice. A guest disputes a charge, gets a refund through the card processor, and then someone also refunds them in Altru. Whichever way it happened, you now have a refund in Altru that shouldn’t be there, and the obvious move of opening it and hitting delete usually isn’t available.
This guide covers why that happens, what you can realistically do, and how to correct the books without making the audit trail worse.
Why refunds are hard to undo
A refund in Altru isn’t a note on the original sale. It’s its own financial transaction, tied to the original order or revenue record, and often to a card transaction at your payment processor. Once it exists, three things can be true at the same time:
- Money has moved. If the refund went back to a credit card, the processor may already have sent it to the guest’s bank.
- The accounting may have moved. If the refund has been posted to your general ledger or included in a closed deposit or batch, finance has already reported it.
- Other records depend on it. Daily sales reconciliation, membership status, and constituent giving totals may all reflect it.
Deleting or freely editing a transaction like that would leave Altru out of step with your bank and your accounting. That’s the main reason the system is restrictive here, and it’s worth keeping in mind before you try to force a change.
First, figure out what state the refund is in
The right fix depends on a few facts. Collect them before you touch anything:
- Payment method. Was it refunded to a card, as cash, as a check, or as a credit to the account? Card refunds involve the processor; the others usually don’t.
- Posting status. Has the transaction been posted to the GL, or is it still unposted? Ask whoever runs your posting process if you aren’t sure.
- Deposit or reconciliation status. Is it part of a daily sales reconciliation or deposit that’s already been closed out?
- Timing at the processor. For card refunds, has the processor’s batch settled yet? Your processor’s portal will show this.
What you can do in each situation
The card refund hasn’t settled yet
This is your best chance at a true void. Many processors let you void an unsettled refund from their own portal, which stops the money from going back to the card. Be aware that voiding at the processor does not automatically update Altru. You’ll still need to correct the Altru side, and that’s where you should involve finance before acting, because the two systems now disagree.
The refund is unposted in Altru
Depending on your security rights and configuration, unposted transactions are sometimes editable in ways posted ones aren’t, such as changing a GL distribution or a date. Whether you can remove an unposted refund entirely is something to confirm in a test environment or with Blackbaud support rather than trying it on a live record. If you have edit rights and the change is limited to details like the date or note, that’s usually the least disruptive correction.
The refund is posted, or the money has already gone out
At this point, treat it as permanent and correct it with a new transaction instead of erasing the old one. Common approaches:
- The guest really did get money back by mistake: contact them and collect the payment again as a new sale or payment, referencing the original order in the notes.
- The refund was recorded in Altru but no money actually left (for example, the processor refund failed or was voided there): work with finance on an offsetting entry. Some organizations record a matching adjustment in Altru; others handle it with a journal entry in the accounting system. Pick one approach and use it every time.
- The refund was duplicated (once at the processor, once in Altru, or twice in Altru): reconcile against the processor’s report to confirm how many refunds actually reached the card, then offset only the extra one.
Whatever you do, add a note on the order or constituent record explaining what happened and what was done to fix it. It saves the next person who runs a revenue report from having to reconstruct the story.
Reducing how often this happens
Since refunds are hard to reverse, most of the value is in preventing bad ones:
- Limit who can refund. Use Altru’s security roles so that front-line staff can sell but only supervisors can refund. Fewer people with refund rights means fewer accidental refunds.
- Require a reason. Make it a habit (or a rule, if your configuration allows it) that every refund has a note saying why.
- Refund in one place. Decide whether card refunds start in Altru or at the processor, and never do both. Duplicate refunds often come from two people working in two systems.
- Check refunds daily. A simple query of refunds created yesterday, reviewed by a supervisor each morning, catches mistakes while the card batch may still be open and before posting.
- Post on a schedule that leaves a review window. If you post to the GL the same afternoon, there’s no time to catch an error while it’s still unposted.
Quick answers
Can I just delete a refund in Altru?
Generally not once it’s posted or tied to a processed payment. For unposted records, what’s possible depends on your configuration and rights; test before relying on it.
If I void the refund at my processor, does Altru update?
Don’t assume so. Treat the processor and Altru as two separate records and correct both.
Who should own refund corrections?
Finance, ideally, with one documented method. Ad hoc fixes by different staff are what make reconciliation painful later.
