A check arrives in the mail covering a family membership renewal and a gift to the annual fund. It was prompted partly by a spring appeal letter and partly by a conversation at a member event. Someone in development enters it in Altru as a back office payment. Three months later the board asks, “How much revenue did the spring appeal bring in?” and nobody can agree on the number.
This is the core problem with back office revenue in Altru: the real world gives you payments with more than one origin, and a single revenue record wants one tidy answer. Below is how to think about it, what you can do inside Altru, and how to build reports that hold up when finance and development compare notes.
First, decide what “source” means at your organization
Half the arguments about this report are really arguments about vocabulary. In Altru conversations, “source” can mean at least four different things:
- Where the money was entered: back office revenue versus daily sales, advance sales, group sales, or online web forms.
- What prompted the gift or purchase: an appeal, a mailing, an event, a solicitation.
- What the money is for: a membership, a donation designation, an event registration, a pledge payment.
- How it was paid: check, credit card, cash, stock, grant.
Each of these lives in a different part of the revenue record, and each one answers a different question. Before you build anything, write one sentence for your team that says which of these you mean when you say “source.” If development means “appeal” and finance means “channel,” no query will satisfy both.
Where a single back office payment runs out of room
The “what is it for” side usually handles multiple parts well. One payment can typically be applied to more than one thing, such as a membership and a donation, and each application keeps its own amount. That split is your friend for reporting, because the dollars for each purpose are recorded separately.
The “what prompted it” side is where people get stuck. Attribution fields on a revenue record are generally built around one answer per transaction or per application, not a weighted list of influences. If you need to credit one check to two appeals, or to an appeal and an event, Altru may not give you a clean native way to do that on a single record. We’d suggest confirming the exact behavior in your own environment, ideally in a sandbox or with Blackbaud support, before you design a process around it. Configuration varies, and it’s better to know your limits than to assume them.
Practical ways to record multi-source payments
There’s no perfect answer here, but these approaches are common and defensible. Pick one and use it consistently.
1. Primary source, with notes
Assign the payment to the source that most directly caused it, usually the appeal or solicitation the donor responded to. Put any secondary influence in a note or an attribute on the revenue record. This keeps totals clean (no double counting) and still leaves a trail for anyone researching the gift later.
2. Split by application
When a payment covers different purposes that clearly came from different efforts, such as a renewal that came from a renewal notice and a gift that came from an appeal, record each part as its own application and attribute each one separately if your setup allows it. You’re not inventing a split. You’re recording the split the donor actually made.
3. Track “soft” influence outside the revenue record
Sometimes the second source is really a relationship touchpoint: a tour, a gala conversation, a board member’s call. That often belongs on the constituent record as an interaction or attribute, not on the revenue. Your appeal report stays honest, and your major gifts team still sees the history.
Whatever you choose, avoid entering the same dollars twice to give two sources credit. It inflates totals and creates reconciliation headaches that surface at year-end.
Building the report itself
Once the data entry rule is settled, the report is mostly a query exercise:
- Start from revenue, not constituents. Build a revenue query (or a revenue application-level query, if you need purpose-level amounts) filtered to your date range.
- Include the field that separates back office from other channels, so you can show back office alongside daily sales and online sales rather than mixed into them.
- Add your chosen source field (appeal, mailing, or whatever your definition sentence says), plus designation and application type.
- Add any attribute you use for secondary influence as a separate column. Report it as context, never added into the totals.
- Reconcile against batches. Back office revenue usually moves through batches, so compare your query total for a period to the committed batch totals. If they don’t match, you’ve found a filter problem before the board does.
Save the query with a clear name and a description that states your source definition. The next person to run it will thank you.
Combining sources across tools
Many organizations end up reporting in a spreadsheet anyway, because leadership wants back office, online, and admissions revenue side by side with targets that don’t live in Altru. The usual pain is the manual export: someone runs the query, downloads it, pastes it into a workbook, and the numbers go stale by the next meeting.
That’s the part our Data Bridge handles. It syncs Altru query results to Google Sheets and other tools, so a revenue-by-source query can feed a shared sheet without repeated exports. It doesn’t change how Altru attributes revenue, so the data entry rule above still matters most.
Quick answers
Can one back office payment be credited to two appeals?
Not cleanly as a weighted split on one record, as far as we know for most setups. Test it in a sandbox or ask Blackbaud support to confirm for your configuration. The common workaround is a primary appeal plus a note or attribute.
Should back office and daily sales revenue be reported together?
Report them side by side, not blended. They’re entered by different people for different reasons, and keeping the channel visible makes it much easier to track down errors.
