Someone asks a simple question: “How many of our summer combo packages did we sell, and on which channel?” You open Altru’s query tool, start a sales order query, and twenty minutes later you have a result set where one package purchase shows up as three rows, the totals don’t match the revenue report, and you aren’t sure which date you filtered on.
Package reporting in Altru is very doable. It just takes a little more thought than a single-ticket report, because a package is one thing to the guest and several things to the database. This guide covers how to think about the data, how to build the query, and the mistakes that throw the numbers off.
Start with what a package looks like in the data
When a guest buys a package, Altru records one sales order. Inside that order, the package shows up as an item, and the package’s components (the timed admission, the film, the add-on program) are tied to it. Depending on how the package was built and which fields you pull, you may see the package itself, its components, or both.
That’s the root of most “my numbers are off” moments. Before you add a single filter, decide which question you are answering:
- How many packages were sold? You want one row per package purchased, not per component.
- How many people are coming to each component? You want component-level rows, usually tied to an event date.
- How much revenue did packages bring in? You want amounts, and you need to know whether your organization allocates package revenue across components or books it as a single amount.
Each of those is a different query. Trying to answer all three in one output is where double counting creeps in.
Building the query
- Use a sales order query as the base. Sales orders are the natural starting point because they carry the transaction date, sales channel (daily sales, advance sales, online), and the constituent if one was attached.
- Find the package fields. Browse the sales order’s item-level fields for anything package-related. Field names and where they sit can differ between Altru versions and configurations, so don’t assume a field means what its name suggests. If you can’t find package detail, ask Blackbaud support where it is exposed in your version before building a workaround.
- Filter on the package, not the component. Filter by package name (or a list of package names) so you only get orders that contain the package. Filtering on a component program will also pull in guests who bought that program on its own.
- Pick your date deliberately. Transaction date tells you when it was sold. Event or program date tells you when the guest will show up. Finance usually wants the first; operations usually wants the second. Label the column clearly so nobody reads one as the other.
- Add the sales channel and order status. Including channel lets you split online versus front desk sales. Including status (or excluding canceled and refunded orders) keeps refunds from inflating your counts.
- Check the row grain before you trust any totals. Run the query, pick one sales order you know well, and count how many rows it produces. If one package purchase returns several rows, you’re seeing components. Either remove the component-level fields or summarize so each order counts once.
Reconcile against something you already trust
Once the query looks right, pick a short date range and compare its totals to a standard Altru revenue or sales report for the same period. If the package count matches but revenue doesn’t, the difference is almost always in how package revenue is allocated, discounts, or refunds. Sorting that out on one week of data is far easier than on a full season.
Mistakes that skew package reports
- Summing component prices instead of the package price. Packages are often discounted relative to buying each piece. Adding up component prices overstates revenue.
- Counting quantity at the wrong level. A family package might include four admissions. “Packages sold” and “admissions sold” are both valid, but they are not the same number.
- Ignoring exchanges. If staff exchange a package for a different date, check whether your query shows the original, the replacement, or both.
- Mixing up package and membership add-ons. If a package was sold alongside a membership on the same order, a sales-order-level revenue total will include both unless you filter at the item level.
Save it once, reuse it often
Package questions tend to come back every season. Save the query with a clear name, note the date field and grain in the description, and consider making a couple of variations: one counted by package, one by component and event date. If your package list changes each year, keep the package names in one filter that is easy to find and update, rather than scattering them across several saved queries.
If you are unsure whether a particular field behaves the way you expect, test it against a handful of known orders, or try it in a sandbox environment if you have one, before the report goes to leadership.
Getting the results out of Altru
Many teams end up exporting this query to a spreadsheet every week so marketing or operations can see package sales without logging into Altru. If that export has become a routine chore, Data Bridge can sync an Altru query to Google Sheets and other tools, so the package report stays current without someone running it by hand.
Quick answers
Why does one package purchase show up as several rows?
Your query includes component-level fields. Each component becomes its own row. Remove those fields or summarize by sales order.
Should I use a ticket query instead?
If you care about attendance by event date, a query built around tickets or programs may be cleaner, depending on which query sources your Altru setup offers. For sales counts, channels, and revenue, the sales order is usually the better starting point.
