“How much did this donor give in 2023? And 2022?” Your development director asks it at every appeal planning meeting. Altru can answer it, but not with one smart field that rolls forward. The approach that holds up is a small set of fixed-year smart fields, built once and added to each January.
Below is how to set that up, what to decide before you build anything, and where the approach stops working.
Why one “prior year” smart field isn’t enough
A smart field is a stored, precalculated value on the constituent record. You define it once, Altru processes it on a schedule, and the result shows up in queries and on records without recalculating each time. That’s what makes smart fields useful for giving totals: a query that pulls lifetime or yearly giving for 30,000 constituents runs much faster against a smart field than against raw revenue.
The catch is the date filter. Revenue-based smart fields let you limit the calculation to a date range, and depending on your Altru version you may see relative options such as this year or last year alongside a specific start and end date. Relative options are handy for “current year” and “last year,” but they usually don’t go further back than that. And whatever “last year” means today, it shifts the moment the calendar turns, so last January’s report and this January’s report won’t line up.
Before building, open the smart field setup in your own database and check which date options are actually offered. If you’re unsure how a relative option is defined (calendar year or fiscal year), ask Blackbaud support or test it against a constituent whose giving you already know.
The fixed-year approach
Past calendar years never change. Giving in 2022 is finished. So instead of one moving field, build one smart field per year with a hard-coded date range:
- Giving CY2022: January 1, 2022 to December 31, 2022
- Giving CY2023: January 1, 2023 to December 31, 2023
- Giving CY2024: January 1, 2024 to December 31, 2024
- Giving CY2025: January 1, 2025 to December 31, 2025
Then keep one relative field (current year to date, if your options allow it) for the year in progress. Each January, add a fixed field for the year that just closed. That’s a five-minute task once a year, and the historical fields never need editing again.
A few build notes:
- Name them consistently. Put the year at the end in the same format every time so they sort together in the query field list. Include “CY” or “FY” in the name so nobody mixes calendar and fiscal totals.
- Use the same filters on every year. If CY2023 counts only donations and CY2024 also counts membership revenue, year-over-year comparisons are meaningless.
- Process them after you create them. A new smart field is empty until it runs. Schedule the processing job (nightly is common) so the current-year field stays fresh. The closed-year fields barely change, but late adjustments and refunds do happen, so keep them on the schedule too.
Decide what “giving” means first
This is where most prior-year totals go wrong. Altru holds donations, membership payments, ticket sales, event registrations, and pledge payments as revenue. Before you build, agree with development on:
- Which revenue types count. Many organizations count donations and pledge payments, exclude ticket sales, and track membership separately. Some count the full membership amount as giving; others count only the portion above benefit value.
- Payments versus commitments. If a donor pledged $5,000 in 2023 and paid it in 2024, which year does it belong to? Pick one and filter accordingly.
- Calendar or fiscal year. If your board reports on a July-to-June year, build fiscal-year fields instead (or both, clearly labeled).
- Soft credits and households. Decide whether a gift made through a household or a donor-advised fund should appear on the individual’s total. Check how the smart field options handle this in your database rather than assuming.
Write the answers down and keep them with the smart field definitions. The next admin will need them.
Putting the fields to work
Once the fields are processed, they behave like any other constituent field in queries. Some uses:
- LYBUNT lists (gave last year but not this year): Giving CY2025 greater than zero and current-year giving equal to zero.
- SYBUNT lists (gave some year but not this year): any prior-year field greater than zero and current year equal to zero.
- Upgrade targets: donors whose CY2025 total is higher than CY2024, for a “thank you for increasing your support” segment.
- Multi-year donor recognition: constituents with giving above zero in each of the last three or five fields.
Output the yearly fields as columns side by side and you have a giving history grid you can export, sort, and hand to a gift officer.
Where this approach stops working
The fixed-year method gets clumsy if you need ten or more years of history: that’s a lot of fields to keep track of. For deep history, a revenue query grouped by constituent and year, run occasionally, is often simpler than maintaining dozens of smart fields. Smart fields also show only one number per field. If you need gift counts, largest gift, or first gift date by year, those are separate fields, so build only the ones someone will actually use.
Getting the totals out of Altru
Many teams end up exporting the yearly giving query to a spreadsheet for pivot tables or board charts, then repeating the export every month. Social Good’s Data Bridge syncs Altru queries to Google Sheets and email tools such as Mailchimp, so a giving-by-year query built on these smart fields can feed a shared sheet or a LYBUNT email segment without manual exports.
Quick answers
Can one smart field show giving for any prior year I choose?
Not that we’re aware of. Each smart field stores one value with one date range. Use one field per year, or a query when you need ad hoc years.
Do fixed-year fields need to be updated each year?
No. Their date ranges stay the same. You only add a new field for each year as it closes.
