An auto-renewing member opens a notice that says their membership expires in May. It’s October, and they know they just renewed. Or the notice goes out three months early with a date that belongs to next year’s term. Either way, the member calls to ask whether they’ve been charged twice, and someone on staff has to explain a date nobody can explain.
The date in the notice is almost never random. It’s coming from a specific field, through a specific query or merge, at a specific moment. When it’s wrong, the cause is usually one of a handful of things, and you can find out which one with a single member record and a bit of patience.
Start with one bad notice
Before changing anything, pick one member who got a wrong date and line up three things side by side:
- The date printed in the notice.
- The membership record in Altru: current term start and expiration, any earlier terms in the membership history, and any renewal that’s already been processed.
- The query or data source behind the notice, run for that one constituent, so you can see exactly which row and which date field it returns.
If the query returns the same wrong date as the notice, the problem is in the query. If the query returns the right date and the notice still shows a wrong one, the problem is in the merge, the export, or the timing of when the notice was generated. That split alone saves a lot of guessing.
The usual causes
The renewal has already posted
With auto-renewing members, the payment often processes before the old term ends. Once it does, the membership record may already show the new expiration date. A notice built from “membership expiration date” then reports the next term’s end, which looks months (or a full year) off to the member reading it.
This is the most common reason a date looks “too far in the future.” It’s not wrong data; it’s a notice asking the wrong question. Decide what the notice is supposed to say. A pre-renewal reminder wants the date the current term ends. A post-renewal confirmation wants the new expiration. Those are different fields at different points in time, and one template rarely serves both.
The query returns more than one membership row
Membership queries can return one row per term, per membership, or per member on the membership (think households and dual memberships). If the merge or export takes “the first row” for a constituent, it may grab an older term or a future one depending on sort order. Check whether your query is filtered to the current or active membership only, and whether the expiration field you’re using comes from the membership itself or from a transaction or term record.
The output is generated well before it’s sent
If notices are built in a batch, exported, and then mailed or emailed days or weeks later, every date in them is a snapshot from the day of the export. Renewals that post in between won’t be reflected. Members who renewed after the export still get “your membership is about to expire” with their old date. Shortening the gap between pulling data and sending, or pulling closer to the send date, fixes more of this than any field change.
The selection window is too wide
A notice meant for members expiring next month sometimes uses a date filter that catches anyone expiring in the next several months. Those members get the right date, just far too early, which reads as an error. Check the range on the selection or query criteria against the timing your renewal policy actually promises.
Formatting and smart fields
Less often, the date is right but displayed wrong: a date-and-time field shifting across midnight, a month/day swap in an export opened in a spreadsheet, or a smart field that hasn’t been refreshed recently. If you use smart fields for expiration data, confirm when they last processed. A stale smart field can lag behind the real record.
What isn’t clear-cut
Exactly how Altru handles the expiration date on an auto-renewing membership at the moment payment posts, and which built-in fields reflect the current versus the upcoming term, can depend on your membership program setup. If you can’t tell from your own records, test it: process an auto-renewal for a test constituent in a sandbox (or a clearly flagged test record), then run your notice query before and after the payment. If the results still don’t make sense, Blackbaud support can confirm which field reflects which term for your configuration.
A setup that holds up
- Separate the notices. One reminder before the charge, using the current term’s end date. One confirmation after the charge, using the new expiration.
- Exclude members who’ve already renewed from the pre-renewal reminder, using whatever indicates a processed renewal in your data.
- Filter to one membership row per recipient, and know which household member gets the notice.
- Pull data as close to the send as you can.
- Spot-check five records every time you change the query or the template, including at least one household and one member who renewed early.
Sending from live query results
Much of the timing problem comes from the export-then-send gap. Email Designer sends automated, branded renewal emails directly from Altru queries without manual exports, so the date in the notice is whatever the query returns when the email goes out. It won’t fix a query that pulls the wrong field, so the checks above still come first.
Quick answers
Why does the notice show next year’s date?
Usually because the auto-renewal already posted and the template reads the current expiration field, which now holds the new term’s end.
Why do some members get the notice months early?
Check the date range in the selection criteria. A wide window catches members long before their term actually ends.
