Finance wants to know what the spring member-preview discount actually cost. Marketing wants to know whether the half-price child promo moved anyone on weekday mornings. Both questions sound simple, and both get stuck on the same detail: they need discounts broken out by price type and by the date of the event or visit, not just a total by discount name for a sales period.
Altru’s built-in discount reporting is a good starting point for “how much did we give away last month,” but it isn’t always shaped for these narrower questions. Below is how to think about the gaps and how to build the view you need from queries.
Three questions that the standard report may not answer cleanly
1. Which price types got discounted?
A discount applied to an order can touch adult, child, senior, and member price types differently. A summary by discount name tells you the total, but not whether the promo mostly landed on adult tickets or on kids who were nearly free anyway. That split matters when you’re deciding whether to run it again.
2. When was the visit, not when was the sale?
Advance sales make this tricky. A discount sold in February for an April program shows up in February’s numbers if you filter by transaction date. If you’re evaluating an event, a holiday weekend, or a specific timed-entry slot, you want to filter by event date instead. Those are two different dates on the record, and it’s easy to pull the wrong one.
3. Are membership promos in there at all?
Discounts on membership sales processed in the back office (a staff-entered renewal at a promotional rate, a board-approved comp, a gift membership at a reduced price) don’t always flow through the same path as ticket discounts at the register or online. We’d suggest not assuming either way. Run a test: process a membership with a promo in a sandbox or on a known test constituent, then check whether it appears in the discount report you normally use. If it doesn’t, you’ll need a separate membership query to capture it.
Build it from queries instead
The most dependable approach is an ad-hoc query you control, rather than a fixed report. A rough plan:
- Start from sales or revenue line items, not orders. Discounts and price types live at the item level. Querying at the order level tends to roll them up and lose the detail you need.
- Add the fields that answer your question. Typically: discount or promotion name, discount amount, price type, quantity, program or event name, event date, transaction date, and sales channel (daily sales, advance sales, web, group sales).
- Filter by event date when you’re judging an event, and by transaction date when you’re reconciling deposits. Save two versions of the query so nobody has to remember which filter to change.
- Build a separate membership query for membership transactions with a discount or promotional rate applied, including membership program, level, transaction date, and amount. Keep it separate from tickets; combining the two in one query usually produces confusing duplicates.
- Check the totals against a report you trust. Pick one closed month and make sure the query’s discount total matches what finance already reconciled. If it doesn’t, find out why before anyone uses the numbers.
Field names and availability vary depending on the query view you start from, and we can’t promise every field above sits on every view. If you can’t find event date or price type on the view you picked, try a different sales-related view or ask Blackbaud support which one exposes both.
Make the discount names do some of the work
A lot of reporting trouble starts at setup. A few habits that pay off later:
- Name discounts so they sort and filter well. Something like “2027-Spring-MemberPreview-20pct” tells you the season, purpose, and value without opening the record.
- Create a new discount for each campaign instead of reusing “Promo Code 1” with new dates. Reuse makes it nearly impossible to separate this year’s results from last year’s.
- Limit which price types a discount applies to if your setup allows it, so the data reflects what you actually intended to discount.
- Give staff a short list of approved back-office membership promos with clear names, rather than letting them adjust prices by hand. Manual price changes are much harder to find later than a named discount.
Turning the query into something people read
Once the query is right, the remaining work is presentation. Most teams export to a spreadsheet and build a pivot table: price type down the side, event date or week across the top, discount amount in the cells. That layout answers the “which tickets, which days” question at a glance.
The weak point is the export itself. Someone has to run it, download it, and paste it in, and that tends to slip once the person who built it gets busy. If the report is something you check every week during a promo, it’s worth automating.
That’s where Data Bridge can help: it syncs Altru query results to Google Sheets (and other tools), so a pivot built on top of your discount query stays current without anyone re-exporting it.
Quick answers
Why don’t my discount totals match between two reports?
The most common cause is one filtering by transaction date and the other by event date. Refunds and exchanges are the next thing to check.
Can I see discounts by price type for group sales?
Often, yes, if the group sales items carry price types in your setup. Confirm by finding a known discounted group order in your query results. Include the sales channel as a column so you can separate group from individual sales.
