Someone in finance asks a fair question: “Of the tickets we sold for last month’s evening event, which ones were refunded, and who held them?” You open Altru’s query tool, start from sales orders, drill into the ticket and registrant details, and find plenty about who bought what. Refund details, though, are hard to find at that level, or missing entirely.
That gap is real, and it trips up a lot of administrators. This article explains why refund data and ticket-level detail tend to live in different places in Altru’s query structure, how to check what your own database exposes, and how to get to a reliable “refunded tickets by guest” report even if no single query gives it to you.
Why refunds don’t sit neatly next to the ticket
In Altru, a sale and a refund are separate financial events. The sales order records what was sold: items, quantities, prices, and for tickets, the program, event time, and any registrant information. A refund is a later transaction that reverses all or part of that money.
Because the refund is its own record, the query views built around the sales order and its items are mostly about the original sale. Registrant and ticket item details are useful for attendance and guest lists, but they may not carry fields such as refund date, refund amount, or refund reason. Whether any refund information is reachable from the ticket registrant level depends on the query views available in your Altru environment. We can’t promise either way, so check it yourself before you build a report around an assumption.
Check what your query views actually expose
Before designing a workaround, spend fifteen minutes confirming what’s there:
- Start a new sales order query and expand every node under the order and its items. Look for anything labeled refund, return, or adjustment. Note which node it lives under; a refund field at the order level behaves very differently from one at the item level.
- Look at revenue and payment-oriented query sources. Refund transactions are financial, so they often appear more naturally in queries built from revenue or payments than from sales orders.
- Test with known examples. Pick three or four orders you know were refunded, including one partial refund (one ticket out of four). Run your test query against just those orders and see whether the output tells the truth.
- Ask Blackbaud support if you still can’t find a path. Describe the exact output you need, such as “registrant name, event date, ticket type, and refund amount on one row,” and ask whether a supported query view can produce it.
The partial-refund test matters most. A query can look correct for whole-order refunds and still be wrong when only some of the tickets on an order came back.
Workaround: two queries, one join
When no single view gives you ticket detail and refund detail together, the dependable approach is to pull them separately and match them up.
Query 1: ticket and registrant detail
Build a sales order query filtered to the programs or date range you care about. Include the sales order ID or transaction number, order date, ticket item details (program, event date and time, price type), and registrant or constituent name.
Query 2: refund detail
Build a second query from whichever source in your environment exposes refunds, filtered to the same period. Include the same order identifier, refund date, refund amount, and any reason or note field you use.
Match them
Export both and join them on the order identifier in a spreadsheet, using a lookup formula or a pivot table. Every ticket row that finds a match in the refund list gets flagged.
For partial refunds, an order-level match only tells you that something on the order was refunded. If you need to know exactly which ticket came back, compare refund amounts to item prices, or, better, adopt a consistent practice at the desk of noting which item was refunded. A short note field your team fills in every time will save hours of guesswork later.
Habits that make refund reporting easier
- Use refund reasons consistently. If your setup supports reason codes, keep the list short and train staff to always pick one. “Weather,” “duplicate purchase,” and “guest request” are far easier to report on than free text.
- Refund against the original order. Processing a refund as a standalone transaction, rather than from the order it reverses, breaks the link your join depends on.
- Save your queries with clear names, such as “Ticket detail for refund match” and “Refunds by order,” so the next person running month-end finds them.
- Reconcile against batches. Once a month, compare your refund query total to what posted in your revenue batches. If the numbers disagree, your query is missing a refund type.
Keeping the joined report current
The two-query method works, but exporting both files and rebuilding the spreadsheet every time someone asks gets old quickly. Data Bridge, our Altru add-on, syncs Altru query results to Google Sheets. With both queries feeding their own tabs, the lookup formulas can stay in place and refresh as the data does, so the refunded-tickets view is ready when finance asks again. The queries themselves still need to be built and tested in Altru as described above.
Quick answers
Can I see refund amounts in a sales order query?
Possibly at the order level, depending on the query views in your environment. Ticket and registrant level is less likely. Test against known refunded orders before relying on it.
Why does my refund total differ from my batch total?
Usually because the query covers only one kind of refund, or uses a different date (order date versus refund date). Filter both by refund date and check which transaction types each one includes.
