Points Expiry

A member of GadgetSphere earns 120 GSPTS at GS-KV-01 on 3 March 2026, on a price set whose points last 365 days. On 3 March 2027 those 120 points, or whatever is left of them, are due to go. Not the member’s whole balance, and not “points older than a year”: that one batch. They actually leave the member’s card only when a scheduled sweep runs, and until then the till still offers them.

This page is for three people: whoever owns the loyalty programme and decides how long points last, whoever answers members who ask where their points went, and whoever in finance releases the liability when points die. It explains where each expiry date and figure comes from, what the sweep does, what goes wrong around it, and how to prove it is working.

Each lot carries its own end date

Every earning creates a lot with a start date, an end date and a balance. The dates are copied from the point line’s valid-from and valid-to, which are set where the points were earned:

Earned from	Where the validity comes from
A sales document line	The line’s point start and end dates, set by the Pricebook Point treatment that priced it: Validity Period (Days) counted from the moment the points were worked out, so every sale gets its own end date. When the item’s pricing-scheme entry has points switched on, the entry sets them instead: the sale plus the entry’s Validity Period days. That field defaults to 0, and on a line scanned at the till 0 means the points end the moment they are earned; the same entry added through the line panel gets 365 days
A Commission Scheme points run	Document date plus the treatment’s Validity Period (Days), which defaults to 0. Zero means the points end on the document’s own date
A manual adjustment	Valid Date From / To on the Add Point Adjustment form
A CSV upload	The validity columns of the point-transaction template
A birthday gift	The validity in months on the scheduled gift (12 if left empty)
A storefront order	None: the storefront points job writes every line valid to 31 December 9999, so those points never expire

A line saved with no dates at all is given an end date of 31 December 9000, so it never expires either. A Point treatment whose validity was left empty is not certainly one of those: the server’s fill-in pass awards nothing for it, and what the till records for the points it works out itself has not been established from the code. If your terms promise that all points expire, these are the places that promise quietly fails.

There is no expiry rule to configure in Membership Admin and no per-currency or per-class expiry setting. If you want SILVER members’ points to last longer than STANDARD members’, that is a different price set with a different validity, not an expiry policy.

Why it is built this way. A lot per earning is what lets a programme promise “points are valid for 12 months from the day you earn them”, which is what most retail terms say, rather than one cut-off date for everybody. When a member spends, the points come out of the lot that ends soonest, so a member never loses old points while newer ones sit untouched.

What this makes possible. Because the validity belongs to the price set, not the programme, one member can hold points with different lives side by side. A weekend promotion at GadgetSphere can give double points on wireless audio from a price set with a 30-day validity, while everyday points last a year. The bonus encourages a quick second visit, and if it is not used it goes in a month without touching the member’s ordinary points. A goodwill gesture works the same way: an adjustment with a 60-day Valid Date To is a voucher-like gift that cleans itself up.

Where each figure on the member comes from

Every figure about expiry that you see on a member is either stored on the lot when it was created or written by the sweep. Nothing on these screens is worked out again when you open them.

Figure	Kept where, and set when	What changes it later
End Date on the Points Expiry tab	On the lot, copied from the earning line’s valid-to when the lot was created	Point Expiry Edit changes it on the lot only. A recalculation of the member rebuilds the lot from the line and puts the original date back
Balance Amount on the Points Expiry tab	The lot’s original points, not what is left	Nothing. A lot the member has half spent still shows its full amount, so these figures do not add up to the till balance
Next Expiry Date Check	A copy of the end date, made when the lot was created	Not changed by Point Expiry Edit. The sweep reads End Date, so after an extension trust End Date
An `EXPIRY` line’s Points on the Point Transaction tab	What was left in the lot when the sweep ran	Nothing. It is a permanent line
An `EXPIRY` line’s Transaction Date	The moment the sweep ran, not the lot’s end date	Nothing. The end date is kept on the line’s validity, which neither the tab nor its detail view shows
The balance the till offers	One stored running total per member and point currency, which still counts a lot after its end date until the sweep removes it	Each new point line; the sweep sets it to zero for a moment and a queued rebuild then sums the member’s lines back into it

Once a lot has been swept it leaves the Points Expiry tab. After that, Membership Admin shows the expiry line and the earning line, but not the dates that link them.

Schedule the sweep, or nothing expires at all

Expiry is one batch job, MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSOR, which you schedule in the Scheduler by choosing it in the Select Processor list. The list is BigLedger’s own and the sweep is always in it, but it is not one of the clocks a new tenant is given. If nobody creates and activates a clock for it, nothing expires on its own, however carefully your price sets are dated. Across the groups we can see, almost none has such a clock, and a large share of the points still on members’ cards are already past their end date, waiting for a sweep.

When it runs, the sweep:

takes every lot in the tenant whose end date has passed and which still holds points. That covers every company, so one clock serves GadgetSphere, GadgetSphere Online and GadgetSphere Distribution together;
writes an EXPIRY line for what was left, zeroes the lot and removes it from the Points Expiry tab;
sets that member’s stored balance to zero for a moment, and queues a rebuild that sums the member’s remaining lines back into it. A points-discount redemption finalised in that moment is refused for insufficient points. Run it once a day while the tills are closed;
logs a lot that fails and moves on. That lot is still due, so the next run tries it again, and nothing tells you in between.

Two other processors in the same list have expiry-sounding names and do not do what their names say:

MEMBERSHIP_POINTS_EXPIRY_REMINDER_PROCESSOR runs the same sweep and sends no e-mail. Scheduling it as well as the elimination processor only runs the sweep twice. This is a known issue, reported to engineering.
The zero-balance status processor is not about expiry. It acts only on a point currency coded ACCESS, and writes INACTIVE into the member’s extra properties, not the member’s own status. For any other currency it does nothing.

Before you switch the clock on for the first time

The first run removes every lapsed lot the tenant has ever had, all in one night. On a tenant that has run points for a year or two without a sweep, members will wake up to lower balances. Finance will also see a release of points it may have stopped expecting. So the clock is switched on by decision, not by whoever happens to be in the Scheduler:

The programme owner decides the date, and members hear before it, through a campaign or a receipt message saying that points older than the stated validity will be removed from that date.
Finance is told the date, because the release belongs in the period the sweep actually runs. See what you owe your members.
Whoever runs the Scheduler checks the first run the next morning (see How you know the sweep is working).

Between the end date and the sweep, the till still offers the points

The sweep is a batch, not a check at the moment of sale. Between a lot’s end date and the next run, the stored balance still includes that lot. It is the figure the till offers and the figure the server checks a points-discount line against at FINAL. A member can therefore spend points that are already past their end date, and the till will let them. That is deliberate: the till does not refuse a paying member. But the spending itself draws only on lots whose end date has not passed, and that causes the problem.

Suppose a member holds 120 points in a lot that ended on 3 March and 800 in a live lot, and no sweep has run. On 10 March the till offers 920 and the member spends all of it. The spending draws the 800 from the live lot and finds no other live lot for the remaining 120, so the lapsed lot is left whole.

When the sweep comes, it expires those 120 points even though the member has already spent them. The member’s balance becomes −120, and finance releases 120 points that were actually redeemed. This is a known issue, reported to engineering. A sweep that runs every night keeps this window to a day, which is the practical defence. A first run after months without a sweep is where it shows up at scale.

Decide what the member is told, because nothing on a schedule tells them

No scheduled job warns a member that points are about to expire. The processor whose name says it does runs the expiry instead. A reminder e-mail does exist in the product, but the only way to send it is a direct call to the membership API, and everything about it is fixed in code:

	What it is
Who gets one	One e-mail per lot ending within the next month, including lots that have already passed their end date but have not been swept, sent to the e-mail on the member record
From	A fixed no-reply address at the platform’s own domain, not yours
What it says	A fixed English subject, “Your Points are Expiring Soon”, the lot’s end date, and the member’s whole balance as “points that you can redeem”. A member with 5,000 points and a 120-point lot ending can easily read that all 5,000 are going

It cannot be branded, translated or suppressed per member, and it keeps no record of having been sent: a member with three lots expiring gets three e-mails from one call, and a second call a week later sends them again.

So the notice is yours, and the programme owner decides it before the first lot expires. If your terms promise a warning, send it from your own marketing system, for example as a campaign to members with points ending next month, a line on the receipt, or a prompt at the till. Confirm it by reading one real notice in a member’s inbox, not by looking at the Scheduler. If a developer wires the API call instead, apply the same test, and try a member with several lots first.

Say what happened after points expire, and be willing to put them back

An expiry produces no letter, no receipt and no in-app message. The member simply has fewer points the next time they look. Two things follow that the product will not prompt you for:

Know how to answer “when did I earn these and when did they die?” before the first member asks. On screen, the member’s Point Transaction tab shows the EXPIRY line with the points and the day the sweep ran. It also shows the earning lines with their dates. The lot’s end date is gone from the Points Expiry tab once it has been swept, so work it out from your validity rule (an earning on 3 March 2026 with 365-day points ends on 3 March 2027). If the answer has to be exact, a developer can read the expiry line through the membership API. It carries the lot’s end date, and the records behind it lead back to the earning it came from.
Decide in advance what you do when the expiry was your fault. A price set dated wrongly, a commission scheme left at 0 days, a warning nobody sent, or a rate change that made redemption pointless: in each case the member lost points through your mistake. The person who answers member complaints should know, from your service policy, how many points they may restore without escalating. That limit is a policy, not a permission the product enforces.

When the member’s complaint is a balance that fell rather than a date, walk the chain first: Walk the chain when a member says their points are missing.

How to put points back depends on whether the sweep has run:

Before the end date passes, Point Expiry Edit on the Points Expiry tab moves a lot’s end date. It needs the edit permission when your tenant locks point edits. The new date lives on the lot only. A later recalculation of the member rebuilds lots from the point lines and restores the original end date. For a lasting extension, post a negative adjustment for the points and a positive one with the new Valid Date To and a remark saying why. The deduction draws on the lot that ends soonest, which is usually the one you are extending.
After the sweep, expired lots cannot be revived. Only a new adjustment restores the points. Give it a Valid Date To and a remark that names the expiry it replaces, so the next person who reads the member’s history understands it.

What the accountant sees

Nothing posts. An expiry line is a membership record and writes no journal, the same as the points it removes (see points currencies). “Breakage” is a figure you work out from the EXPIRY lines over a period (membership reports), not something the module books.

That makes releasing the liability a manual journal in the period the sweep actually ran. That is not necessarily the period the points were due to expire, and if nobody scheduled the sweep it never happens at all. The procedure, and who runs it, is in what you owe your members.

When expiry goes wrong

What you see	Why	What to do
Lots on the Points Expiry tab with an End Date in the past, and no `EXPIRY` lines anywhere	No clock runs the sweep	Create an ACTIVE clock for the elimination processor (after the decisions above)
The Scheduler shows a recent Last Run Date but the lapsed lots are still there	Last Run Date means the clock fired, not that the sweep worked; or the clock is the reminder processor’s	Look for `EXPIRY` lines dated after that run; check which processor the clock names
A member’s points expired the day they were earned	A commission scheme with Validity Period (Days) left at 0	Set a validity on the scheme; restore the points with an adjustment
Points never expire for some members	Their lots end in the year 9000 or 9999: a price set with no validity, an adjustment or import without dates, or storefront points	Give every source a validity; existing lots keep their date until edited
A member’s balance went below zero after a sweep	They spent points after the lot’s end date and before the sweep (above)	Restore the difference with an adjustment and record why; run the sweep daily
A member shows 0 at the till straight after a sweep, with live lots on the Points Expiry tab	The rebuild queued behind the sweep has not landed	Wait for the queued rebuild; if it does not land, ask BigLedger support to run the points recalculation for that member (Membership Admin has no button for it)
An extension you made disappeared	A recalculation rebuilt the lots from the point lines	Extend with a pair of adjustments instead (above)
Members got several reminder e-mails at once	One e-mail per expiring lot, from a direct API call	Send your own notice instead, one per member

Read from the code and not yet seen on a live tenant: when the sweep expires one lot of a member who also holds a live lot, the expiry line appears to draw the same points from the live lot too. The till balance stays correct, but the live lot then ends short, and when its own end date comes, some of its points are left with no lot to expire them. This is a known issue, reported to engineering. If you see a member whose till balance stays above zero after all their lots have gone from the Points Expiry tab, that is the likely cause.

How you know the sweep is working

The Scheduler cannot tell you. Its Last Run Date is stamped when the job is queued, not when it finishes. Whoever owns the Scheduler checks the effect, once after the first run and then monthly, before finance closes the period:

Before the run, note a member whose Points Expiry tab shows a lot with an End Date in the past.
The morning after, open the same member. The lot has gone from the Points Expiry tab, and the Point Transaction tab has an EXPIRY line dated the night of the run for the points that were left in it.
Compare the till balance for that member with what you expect from their remaining lots and lines. A negative figure, or 0 against live lots, is one of the cases in the table above.

If step 2 fails, nothing is expiring anywhere in the tenant, whatever your price sets say, and the liability finance carries will never be released.

How expiry fits with the rest of membership

What must exist first. Points on members, which needs the company’s member-point configuration and a priced Point treatment (points setup); a validity on every source that awards them; and an ACTIVE Scheduler clock for the elimination processor.
What it makes possible. A till balance that matches what your terms promise, a breakage figure finance can stand behind, and short-lived promotional points beside ordinary ones.
Its sibling, and when to use which. Expiry rules is the setup checklist: where to put the validity and how to schedule the sweep. This page is the model behind it. Do not confuse points expiry with the Membership End Date on the member record. The sweep reads lots, never the member, so a card that has ended keeps its points until their own lots end.
What breaks if this is wrong. The till offers lapsed points; redemptions after the end date are expired a second time; finance carries a liability that is never released, or releases it all in one surprising month; and members lose points with no warning they would recognise.
What it pairs with in practice. Your own expiry notice, a service policy for restoring points, and the month-end liability routine in what you owe your members.