Money left the processor, but the order never fully landed in Altru. Six weeks later someone in finance asks who issued that refund, why, and whether it was ever recorded against a constituent. If the order was stuck in an unresolved state when the refund happened, the answer can be surprisingly hard to find.
This article explains why refunds on unresolved or canceled online orders are a blind spot, what you can reasonably check inside Altru, and how to build an audit trail that holds up when your auditor or controller starts asking questions.
Why these refunds are hard to trace
A normal refund in Altru starts from a completed sale. There’s an order, a constituent (or an anonymous daily sale), revenue that posted, and then a refund tied back to it. That chain is what makes a refund auditable.
Online orders that never resolved break the chain. A guest checks out on a web form, the payment is authorized or captured, but something goes wrong before the transaction is fully processed in Altru: a matching problem, a timeout, a canceled payment, a duplicate submission. Staff then handle it in one of several ways:
- Refund or void the charge directly in the payment processor’s portal.
- Cancel or delete the pending online transaction in Altru.
- Resolve the order first and then refund it the normal way.
- Leave it alone and hope someone else deals with it.
Only the third path leaves a clean refund record in Altru. The first two can leave money moving in the processor with little or nothing on the Altru side tying it to a person, a reason, or a date. That’s the gap you’re trying to close.
What to check in Altru first
Be careful about assuming Altru keeps a history you can report on here. Whether it records who canceled a pending online transaction, and when, depends on your version and how your site is set up, and we wouldn’t promise either way. Before you design anything, confirm it:
- Run a test in a sandbox or during a controlled window. Place a small test web order, cancel or refund it the way staff actually do, and then look at what appears on the constituent record, in revenue, and in any query you can build against refunds and payments.
- Look at your revenue and payment queries. See whether refunds, payment method, date, and the user who entered them are available as fields. If the “added by” or “changed by” style fields are there, a saved query may cover a lot of what you need.
- Ask Blackbaud support directly whether canceled or deleted pending online transactions are logged anywhere you can access, and if so, how to report on them. Get the answer in writing so you can cite it in your procedures.
Whatever you learn, write it down. Your audit approach depends on it.
Treat the processor as the source for these cases
For refunds on orders that never resolved, the payment processor is usually the most reliable record of money moving. It shows the original charge, the refund, the amount, and the date. What it usually lacks is context: who asked for the refund and why.
So the practical audit trail is a reconciliation between three things:
- Processor activity: every refund and void for the period.
- Altru refunds: refunds you can pull from a revenue or payment query for the same period.
- A refund log: a simple record your team keeps for anything that doesn’t match.
Any processor refund without a matching Altru refund is exactly the population you care about. Most will be unresolved web orders, canceled payments, or duplicates. Each one needs an explanation in the log.
Set up a refund log that’s actually used
Keep it short, or nobody will fill it in. A shared spreadsheet with locked edit history works fine. Capture:
- Date of refund and processor transaction reference
- Amount and original charge date
- Guest or constituent name, plus the Altru constituent record if one exists
- Reason (failed order, duplicate, canceled visit, payment error, other)
- Who requested it and who issued it
- What happened in Altru: resolved and refunded, canceled, or nothing recorded
If a constituent record exists, add a note or an action on it pointing to the log entry. That way the next person who looks up that guest sees the history instead of a confusing gap.
Controls worth putting in place
Limit who can refund in the processor
Processor portal access tends to spread over time. Review who has refund rights and trim it to the people who also maintain the log. Refunds issued outside Altru should be the exception, not a habit.
Prefer “resolve, then refund”
Where it’s possible, train staff to resolve the stuck online order in Altru first and then process the refund normally. It takes a few minutes longer, but the refund lands on the right record with revenue and batch history intact.
Separate request from approval
For refunds over a set amount, require a second person to approve before money goes back. Note the approver in the log.
Reconcile on a schedule
Match processor refunds to Altru refunds every week or at month-end close, before deposits are finalized. Catching a mismatch three days later is easy. Catching it at year-end audit is not.
Reduce the number of unresolved orders
The best audit trail is fewer exceptions to audit. Keep an eye on the queue of pending online transactions and work it daily so orders don’t age into problems. When you see the same failure pattern repeatedly, such as duplicate submissions or a certain payment type failing, raise it with Blackbaud support with specific examples. Fixing the cause shrinks the refund log over time.
Quick answers
Does Altru show who canceled a pending online order?
We can’t confirm that it does for every setup. Test it in your own environment and ask Blackbaud support before relying on it.
Is the processor report enough for auditors?
It proves money moved, but not why. Pair it with a refund log that records the reason and the people involved.
Should we delete stuck online orders after refunding them?
Decide that as a written policy, and only after confirming what deleting removes. If deletion erases the only Altru trace of the order, record the details in your log first.
