Accountants and Altru tend to talk past each other on scheduled programs. The finance office asks, “How much did we earn from the October workshops?” Altru answers most naturally with, “Here’s what we sold in October.” Those are two different numbers, and a query built for one will quietly give the wrong answer to the other.
Before you build anything, get clear on which question you’re answering. Then the query itself is fairly straightforward.
Two questions that look like one
Sales by transaction date tells you what came in the door during a period: payments taken at the desk, online, and through group sales. This is what ties to your deposits and your posted revenue batches.
Revenue by event date tells you what was earned during a period: tickets for events that actually took place. If you sell a summer camp session in March, the cash arrives in March but the program happens in July. Many organizations treat that money as deferred until the event runs, and the accountant needs a list of future events with tickets already sold to book that liability correctly.
Ask your finance contact which one they want, or whether they want both. Usually it’s both: one report to reconcile cash, one to recognize revenue.
Building the event-level query
Start an ad-hoc query from a source centered on scheduled program events rather than on revenue. Query source names vary a bit by Altru version and permissions, so if you don’t see an obvious program event source, check with your Altru administrator or Blackbaud support rather than forcing it through a revenue source. Starting from events matters because each row should be one event (or one event and price type), not one payment.
Useful output fields for an accountant:
- Program name and program category
- Event date and start time
- Event capacity and tickets sold, if available in your source
- Price type (adult, child, member, and so on)
- Ticket quantity and amount, summed per event
- Any GL-related fields your organization uses, such as the account or designation the program revenue posts to
Filter on event date, not sale date. For a monthly close, that’s the first through the last day of the month. For a deferred revenue snapshot, filter for event dates after the period end, combined with a sale date on or before the period end.
Group the results so finance can use them
Accountants rarely want ticket-level detail. Summarize by program and event date, or by program and month, and include a total. If your query tool can’t summarize the way you need, export the detail and pivot it in a spreadsheet, but keep the saved query itself simple so it’s easy to rerun each month.
Things that throw the totals off
Expect your event-based total and your posted revenue to differ. Most of the gap usually comes from a short list of causes, and documenting them saves a lot of back and forth:
- Refunds and exchanges. A ticket refunded in a later month may still show against the original event, or may show as negative revenue in the refund month. Test a known refund in your query and see where it lands.
- Discounts and comps. Make sure you’re pulling the amount actually charged, not the list price. Comped tickets will inflate attendance without adding revenue.
- Combination tickets and packages. When one purchase covers more than one program, Altru splits the price across components. Confirm how those splits appear in your query output before handing it over.
- Taxes and fees. Decide with finance whether totals should include sales tax or service fees, and filter or exclude those fields to match.
- Cancelled or rescheduled events. Tickets moved to a new date can change which period the revenue belongs to. Rerun last month’s query after a reschedule and compare.
If you can’t tell whether a field reflects the amount paid or the list price, test it: sell a discounted ticket to a test event in a sandbox (or use a known transaction), then check what the query returns.
Reconciling with the general ledger
The cash side should tie to your posted revenue batches for the same date range. Run a revenue query filtered on transaction date, totaled by program or GL account, and compare it to what posted. Differences there usually point to unposted batches, adjustments, or revenue entered outside of program sales.
The event side won’t tie to the GL directly, and that’s expected. Its job is to show the accountant how much of the cash already received belongs to future events, so they can make a deferral entry. Give them the deferred list as of each period end and keep each month’s export, since you can’t easily recreate an “as of” snapshot later once refunds and exchanges have changed the underlying records.
Make it repeatable
- Save both queries with clear names, such as “Finance: program revenue by event date” and “Finance: program sales by transaction date.”
- Write a short note listing the filters, what’s included, and what’s excluded (tax, fees, comps). Store it where finance can see it.
- Agree on a run date each month, after the last batches for the period have posted.
- Keep a copy of every period’s export, labeled with the date it was run.
Getting the data to finance without manual exports
Once the queries are right, the remaining chore is exporting and sending them each month. Data Bridge from Social Good can sync an Altru query to Google Sheets, so finance can open a sheet that refreshes from the saved query instead of waiting on an emailed export. You’d still want to keep dated copies for period-end snapshots.
Quick answers
Should the accountant’s report use sale date or event date?
Sale date to reconcile cash and posted revenue; event date to recognize earned revenue and calculate deferrals. Most finance teams need both.
Can I give the accountant access to run the query themselves?
Possibly, depending on your Altru security roles and licensing. Talk with your Altru administrator about a role limited to running saved queries before sharing credentials.
