You build a query to total last month’s donations, run the same idea from a different source, and get two different numbers. Neither is broken. In Altru, the Revenue and Revenue Application query sources answer different questions, and picking the wrong one is the most common reason a revenue report “doesn’t match.”
Here is how to think about the two, when to use each, and how to avoid double counting when you need both.
The short version
- Revenue describes the transaction: one payment, one gift, one order total. Think “money came in, from this constituent, on this date, by this payment method.”
- Revenue Application describes where that money went: the portions of a transaction applied to a donation, a membership, tickets, a pledge, an event registration, and so on. Think “of that payment, this much was membership and this much was a gift to the annual fund.”
One payment can have several applications. A guest who buys two tickets, joins as a member, and adds a donation at checkout may show up as one row in a Revenue query and three or more rows in a Revenue Application query.
When Revenue is the right source
Start from Revenue when the question is about the transaction itself:
- Total cash received in a date range, for reconciling against a deposit or processor report.
- Payments by payment method (credit card, check, cash).
- Which constituents paid anything at all this quarter.
- Counting transactions rather than dollars by purpose.
The amount on a Revenue row is the transaction amount. If you sum it, you get what came in the door, regardless of how it was split.
When Revenue Application is the right source
Switch to Revenue Application when the question is about purpose:
- How much went to memberships versus donations versus admissions.
- Giving to a specific designation or campaign, when donors sometimes split a gift.
- Pledge payments, where you need to see that a payment was applied to an existing commitment rather than counted as a new gift.
- Development reports that should exclude the ticket portion of a mixed order.
The amount on an application row is only the applied portion. Summing it by application type or designation gives you the purpose-level breakdown that a Revenue query cannot.
The double-counting trap
The mistake that produces inflated totals usually looks like this: you start from Revenue, then add a field or filter from the application side (an application type, a designation) so you can narrow the results. Each transaction now repeats once per application, and the output still shows the full transaction amount on every repeated row.
Sum that column and a $150 order split across three purposes counts as $450.
Two habits prevent it:
- Sum the amount from the level you are reporting on. If your rows are applications, total the application amount, not the revenue amount.
- Check row counts against a known transaction. Pick one mixed order you understand well, run your query, and confirm the rows and dollars match what you expect before trusting the totals.
Things that make the two disagree on purpose
Even with a correct query, Revenue and Revenue Application totals can legitimately differ. Common reasons:
- Pledges. A pledge commitment and the payments applied to it can show up differently depending on which source you use and whether you filter by transaction type. Decide whether you’re reporting commitments or cash.
- Refunds and adjustments. Refunded orders and adjusted amounts may be reflected differently, and dates on adjustments may not match the original transaction date.
- Date fields. Make sure both queries filter on the same kind of date. A transaction date and a posting or deposit date can fall in different months.
- Filters on one side only. A filter on designation or application type excludes everything else in a mixed order, which is correct for a purpose report and wrong for a cash report.
Exact field names and how specific transaction types appear can vary with your configuration and Altru updates. If a number looks off and you can’t explain it, build a tiny test (one order with a ticket, membership, and gift) and compare both sources side by side. If something still doesn’t reconcile, Blackbaud support can confirm how a given transaction type is represented.
A simple way to choose
Ask what one row in your finished report should represent.
- One payment or one deposit line: use Revenue.
- One purpose, fund, designation, or membership sale: use Revenue Application.
- Both on the same report: build two queries, or carry the transaction identifier on the application query so you can group applications back into their parent transaction without summing the parent amount more than once.
Name saved queries so the grain is obvious, for example “Revenue (one row per payment) – FY donations” and “Revenue Application (one row per purpose) – FY designations.” Six months from now, whoever picks up the report will know which total to trust.
Getting the right query in front of the right people
Once the query is correct, the next problem is usually distribution: finance wants the cash view, development wants the designation view, and both end up in exported spreadsheets that drift. Data Bridge syncs Altru query results to Google Sheets and other tools, so each team can work from the query you validated instead of a copy exported last month.
