On the first day of a new fiscal year, a lot of saved Altru queries quietly go stale. The “this year’s memberships” query still points at last year’s dates, the board revenue report needs new criteria, and someone spends the morning opening queries one by one to retype date ranges. The cause is simple: your fiscal year probably doesn’t match the calendar year, and the date filters in Altru queries are built mostly around calendar periods.
This article covers what Altru’s date filters handle well, where fiscal-year reporting runs into limits, and the setups that keep you from rebuilding queries every July (or October, or whenever your year turns over).
Fixed dates vs. relative dates
When you add a date field to a query’s criteria, you generally have two kinds of choices:
- Fixed values, such as “is between” two specific dates or “is on or after” a specific date. These are precise, but they never move. A query built for one fiscal year is wrong the day the next one starts.
- Relative (dynamic) values, such as today, this week, this month, last month, this year, or last year. These recalculate every time the query runs, which is what you want for anything saved and reused.
The relative options are where fiscal years get awkward. In most setups, “this year” and “last year” mean calendar years. Your organization’s fiscal year settings exist elsewhere in Altru (they matter for revenue and general ledger work), but that doesn’t mean every query date filter can use them. Open the operator list on a date field in your own database and check exactly what’s offered before you design anything around it. If you don’t see a fiscal-year option, assume you need one of the workarounds below. If you aren’t sure how an option behaves, run the query in a sandbox or ask Blackbaud support. Don’t wait until the board report is due to find out.
Workarounds that hold up
1. Calendar months, stitched together
A July–June fiscal year is just two calendar-year ranges glued together. For many reports you can make your criteria answer a slightly different question: for example, “this year” plus “last year” for a rolling view, or relative month options for monthly reporting. It isn’t a true fiscal-year filter, but for operational queries like recent sales or recent joins it’s often good enough, and it never needs editing.
2. A small set of fixed-date “FY” queries with a turnover checklist
For anything that has to match finance exactly, such as annual fund totals or membership revenue by fiscal year, a fixed date range is more honest than an approximate relative one. The key is to keep the number of queries small and make updating them routine:
- Name them consistently, for example “FY Current – Membership Revenue” and “FY Prior – Membership Revenue,” rather than putting the year in the name.
- Keep them in one query category or folder so they’re easy to find.
- Put a recurring calendar reminder on the first business day of the fiscal year to update the “between” dates on each one. The prior-year query takes the old current-year dates.
- Note in each query’s description which date field it filters on (transaction date, membership start date, expiration date, gift date). Mixing these up causes far more reporting disagreements than the fiscal year does.
Ten minutes once a year is a reasonable price for numbers that tie to the audit.
3. Filter broadly, label fiscal year downstream
Another approach is to stop asking the query to know about fiscal years at all. Pull a wider window, such as “this year” plus “last year,” or everything on or after a fixed date a few years back. Then assign fiscal year in a spreadsheet or BI tool with a simple formula: if the month is on or after your fiscal start month, the fiscal year is the calendar year plus one (or the same year, depending on how your organization labels it). This keeps the Altru query stable and puts the fiscal logic in one visible place that finance can check.
The weakness is the export step. If someone has to run the query and download a file every week, the spreadsheet is only as current as the last person who remembered to do it.
Small details that cause big discrepancies
- Which date you filter on. A membership sold in June that starts in July belongs to different fiscal years depending on whether you use the transaction date or the start date. Decide which one finance uses and match it.
- Advance sales. Tickets bought in one fiscal year for a visit in the next can be counted twice, or not at all, if one report uses the sale date and another uses the event date.
- “Through” dates. When you type a fixed end date, check whether a sale late on the last day of the year is included. Test with a known transaction.
- Fiscal year labels. “FY27” means July 2026–June 2027 to some organizations and July 2027–June 2028 to others. Write your convention in the query descriptions.
Keeping fiscal-year data current outside Altru
If you go with the third approach, the remaining problem is getting the query results out of Altru on a schedule. Social Good’s Data Bridge syncs Altru query results to Google Sheets and other tools, so a broad-window query can feed a sheet where a fiscal-year column is calculated automatically, without anyone running manual exports. The query stays simple, and the fiscal-year logic lives in the sheet where finance can see it.
Quick answers
Can I make a saved Altru query always show the current fiscal year?
Only if your date filters offer a fiscal-year option, so check the operator list in your own database. If they don’t, use fixed-date FY queries that you update at year-end, or label fiscal year after export.
Does changing a query’s dates affect reports or lists built on it?
Yes. Anything that uses that query as a source picks up the new criteria the next time it runs. Before you edit a shared query, check what depends on it.
