Finance wants a simple grid: payment methods down the side (cash, check, credit card, other), revenue types across the top (admissions, memberships, donations, events, store), totals in every cell. It sounds like one report. In Altru it usually turns into a query, an export, and a pivot table, and the numbers only tie out if you decide a few things before you build anything.
This guide covers those decisions, how to build the query, and the traps that make the grid disagree with your deposits.
First, agree on what “revenue type” means
People use the phrase loosely, and Altru has several fields that could fit. Before building anything, ask whoever wants the report which one they mean:
- Application type: what the money was applied to, such as a membership, a donation, an event registration, or a sales order (daily sales or advance sales tickets and merchandise). This is the most common meaning.
- Transaction type: payment versus pledge versus recurring gift. Useful for development, less so for a cash-by-tender report.
- Designation, revenue category, or GL account: what the money funds or where it posts in the general ledger. Finance often means this even when they say “revenue type.”
Get the answer in writing, with a sample of the layout they expect. Building the wrong cross-tab cleanly is still building the wrong cross-tab.
Check the standard reports before you build
Altru ships with daily sales, deposit, reconciliation, and revenue reports, and some of them break totals out by payment method. Whether any of them crosses payment method against your chosen revenue type exactly the way finance wants depends on your version and configuration, and we would rather not guess. Run the candidates for a single day you already know well and compare. If you are unsure whether a built-in option exists, Blackbaud support can confirm quickly, and that answer may save you the rest of this article.
Build the query
When no standard report fits, a revenue query is the reliable route. Start from the revenue source view (not constituents), and add the application-level details so each row represents one piece of a payment applied to one thing.
Output fields to include
- Revenue date (or posting date, if finance works from posted batches)
- Payment method
- Application type, and designation or GL account if needed
- Application amount, not just the total payment amount
- Revenue ID or lookup ID, so you can trace odd rows
- Constituent name, optional, for spot checks
Filters to set
- A date range, ideally one you can change at run time
- Transaction type of payment, so pledges and unpaid commitments do not inflate the cash picture
- Exclude or separately flag refunds and reversals, depending on how finance wants them shown
Field names in the query designer vary a bit by version, so search the field list for “payment method” and “application” rather than looking for an exact label.
The traps that break the totals
One payment, several applications
A guest buys two tickets and a membership in one transaction. That is one payment with two applications. If your query outputs the total payment amount on each application row, the cash total doubles. Always sum the application amount.
Split tender
The harder case is the reverse: one order paid partly in cash and partly by card. Altru records the payment methods, but it does not necessarily say which dollars of cash went to tickets and which went to the membership. If finance needs every cell to be exact, agree on an allocation rule (for example, prorate by application amount) and apply it in the spreadsheet. Test a few split-tender orders in a sandbox or on a known day so you can see how your data actually lands before relying on it.
Refunds and voids
Refunds may appear as separate negative revenue or as adjustments, and they may not carry the same payment method as the original sale. Decide whether the report nets them out or lists them on their own row, and say so in a footnote on the report.
Date mismatches
Your deposits are built from batches. A sale on the 31st that posts on the 2nd lands in different months depending on which date you filter on. Use the same date basis finance uses for reconciliation.
Turn rows into the grid
Export the query results and build a pivot table: payment method as rows, revenue type as columns, sum of application amount as values. Then reconcile one day against your daily sales or deposit totals. If that day matches to the penny, save the query and the pivot layout and reuse them. If it does not, the difference almost always traces back to one of the traps above, and the revenue IDs in your output make it findable.
Once it ties out, write down the definitions you settled on: which date, which revenue type field, how split tender and refunds are handled. The next person who runs it, or the auditor who asks about it, will need that more than the spreadsheet.
Keeping it current without weekly exports
The manual export works, but it means someone remembers to run it and rebuild the pivot. Data Bridge syncs Altru query results to Google Sheets, so the same payment-by-revenue query can feed a sheet where the pivot table refreshes from current data. The query design and the allocation decisions above still matter just as much; this only removes the export step.
Quick answers
Why doesn’t my cash total match the deposit?
Usually because the query sums payment amounts instead of application amounts, uses a different date than the batch, or handles refunds differently than the deposit does.
Can I do this with smart fields instead?
Smart fields summarize values onto constituent or other records, which is good for “lifetime giving by member” but awkward for a period cross-tab like this. A revenue query is the better fit.
