The finance director wants Saturday’s revenue split into cash, card, and check. The education manager wants only camp sales. Development wants donations by revenue category. All three go to the Total Revenue and Payments report first, because it’s the one everyone trusts, and all three find that it won’t break the numbers down the way they need.
Built-in Altru reports aren’t really meant to be edited. You can change the parameters they offer (date range, and depending on the report a few other choices), but you generally can’t add new filters, add columns, or regroup the output. So “customizing” this report usually means one of two things: getting more out of the parameters it already has, or rebuilding the view you need from a query. This article covers both.
Start by checking what the report already lets you choose
Before you build anything, run the report and look closely at its parameter screen and its output. The options you get can depend on your Altru version and on the security rights your login has, so two people at the same organization sometimes see different choices. Things to check:
- Which date options it accepts, and whether it reports by transaction date or deposit date. Mixing these up is a frequent reason the report “doesn’t match” a deposit.
- Whether payment method is shown as a subtotal anywhere in the output, even if you can’t filter on it.
- Whether you can export the results. If you can export to Excel, a pivot table will often answer a one-off question faster than any rebuild.
If you aren’t sure whether a filter exists, ask Blackbaud support or test it in your sandbox environment. Don’t assume it’s missing just because it isn’t on the first screen.
Rebuild the view you need with a query
For anything recurring, a query is the more durable answer. Altru’s query tools let you pick fields from revenue and payment records, set your own filters, and save the result for reuse. That covers most of what people want from a more flexible revenue report.
By payment method
Build a revenue query and include the payment method field alongside amount, date, and transaction type. Add a date filter, then either filter to a single method (for example, only checks) or leave all methods in and summarize the export. Save it with a clear name so front desk leads and finance run the same one.
By revenue category
Revenue category is normally tied to how your revenue is designated or coded, so the field you need may live on the revenue’s application or designation rather than on the payment itself. Expect to try a couple of field paths in the query designer before the totals look right. Compare your query total for a single day against the built-in report for that same day. If they don’t match, you’ve either pulled in a duplicate line (common when one payment covers several items) or excluded something like refunds or adjustments.
By program or section
Filtering to one program, class, or event section usually means starting from the sales or registration side and joining to revenue, not the other way around. Before you build this one, decide whether “section revenue” means what was sold for that section or what was paid in a given period. Those are different numbers, especially for deposits and installment payments.
Keep the numbers reconcilable
A custom view is only useful if finance believes it. A few habits help:
- Reconcile once against the built-in report. Pick a closed month and confirm your query total matches the Total Revenue and Payments report total. Write down any known differences (refunds, voids, write-offs) and why they happen.
- Use the same date logic every time. Decide on transaction date or deposit date and put it in the query name.
- Lock down who edits saved queries. One person changing a filter can quietly change everyone’s numbers. Keep a master copy that only an admin edits, and let others copy it.
- Keep the built-in report as the official total. Treat your queries as breakdowns of that total, not replacements for it.
When exporting becomes the job
Once the queries exist, the usual pain is the routine around them: run the query, export, paste into the finance workbook, rebuild the pivot, email it. Every week. That routine is where staff time adds up, and it’s where copy-paste mistakes creep in.
Our Data Bridge syncs Altru query results to Google Sheets and other tools, so a saved revenue query can feed a shared sheet that already has your payment-method or category summaries built on top of it. Altru still does the counting. The sheet just stops needing a weekly manual refresh.
Quick answers
Can I add a payment method filter to the built-in report itself?
Generally no. Built-in reports keep their own parameter sets. If you’re unsure about your version, confirm with Blackbaud support, but plan on a query for this.
Why doesn’t my query total match the report?
Usually it’s date logic (transaction vs. deposit date), payments split across several items being counted more than once, or refunds and adjustments being handled differently. Reconcile one day at a time until you find which.
Should I build one big query or several small ones?
Several small ones, each answering one question, are easier to check and less likely to be broken by someone else’s edit.
