A board member asks a simple question: “What has the Hendersons’ family given us over the years?” You open the constituent record and find two answers. One list shows gifts the person paid themselves. Another shows gifts they were credited for, like the membership their spouse bought or the sponsorship that came through their family foundation. Neither list alone tells the whole story, and Altru does not stack them into one view for you.
There is no setting that merges revenue history and recognition history on the record itself. What you can do is build a combined view outside the record, with a clear rule for how to count each line. This guide covers why the two are separate, how to put them together, and the double-counting trap to avoid along the way.
Why Altru keeps them apart
The two histories answer different questions:
- Revenue history is about money. Who paid, how much, on what date, to what designation. This is what finance reconciles and what lands in batches and deposits.
- Recognition history is about credit. Who gets acknowledged for a gift, even if someone else’s card was charged. Household members, spouses, a company’s contact person, or the person behind a donor-advised fund can all receive recognition for a payment they didn’t make.
Keeping these separate protects your financial totals. If every recognition line were treated as revenue, one $500 gift with two recognized household members could show up as $1,500. So the split is deliberate. The cost is that development staff, who mostly care about relationships, have to look in two places.
Decide what “combined” means before you build anything
Most of the trouble with a merged view comes from not agreeing on this first. Pick one of these, and write it at the top of whatever report or spreadsheet you build:
- Relationship view (deduplicated). Show every gift the person either paid or was recognized for, but list each gift only once. If they paid and were also recognized, it appears one time. This is usually what a board member or gift officer actually wants.
- Side-by-side view. Two columns per gift: amount paid by this constituent, amount recognized to this constituent. Totals are reported separately and never added together.
- Household view. Roll everything up to the household and drop individual recognition entirely. Good for “what does this family give,” less good for stewardship of individuals.
Whatever you choose, the rule is the same: never sum paid amounts and recognition amounts into one total. That number is wrong by design.
Building the combined list
Option 1: one revenue query with recognition fields
Start with a revenue-based query and look for recognition-related fields in the field list, such as the recognized constituent and recognition amount. If your query view exposes them, you can filter on “constituent is the payer or constituent is a recognition recipient” and get both sets of gifts in one output, with a column showing which role the person played.
I can’t promise every Altru database surfaces recognition the same way in queries. Test it with a constituent you know well, one who has both paid gifts and recognition-only gifts, and check that the row count matches what you see on their record. If you can’t find the fields, ask Blackbaud support which query view exposes recognition credits in your version.
Option 2: two queries, joined in a spreadsheet
This is the dependable fallback. Build one query of revenue where the constituent is the payer, and a second of recognition credits for the same constituents. Include the revenue ID (or another unique transaction identifier) in both. Export both, then:
- Stack them into one sheet with a “Role” column (Paid or Recognized).
- Remove duplicates by constituent plus revenue ID, keeping the “Paid” row when both exist.
- Sort by date to get a single, readable timeline.
That revenue ID is what makes the deduplication reliable. Without it, you’ll be matching on date and amount, which breaks the first time someone makes two equal gifts on the same day.
Option 3: smart fields for summary numbers
If the goal is a total on a list rather than a gift-by-gift history, smart fields can calculate per-constituent summaries like lifetime giving. Check whether your available smart field types include recognition-based totals as well as revenue-based ones. If both exist, add them as two separate columns in your query. Again, report them side by side, not added together.
Keep the recognition data clean
A combined view is only as good as the credits feeding it. A few habits help:
- Agree on when staff should add recognition manually and when to rely on household or relationship defaults.
- Spot-check gifts from companies, foundations, and donor-advised funds. These are the ones most likely to be missing a recognized individual.
- Clean up duplicate constituents. If a donor exists twice, their recognition can be split across both records and your combined history will look thinner than it is.
Quick answers
Can I make the constituent record show one merged history?
Not that I’m aware of. The record keeps the two lists separate. A saved query or report is the practical way to get one combined view.
Which number goes in a gift officer’s briefing?
Usually the deduplicated relationship total, labeled as such, with paid giving shown separately for anyone who needs the financial figure.
Will recognition changes alter my revenue totals?
They shouldn’t. Recognition affects credit, not the payment amount. If revenue totals move after you edit recognition, look closer before you trust either number.
