Skip to content

Expiry Rules

There is no expiry-rule screen in BigLedger. Each batch of points a member earns carries its own end date, set where the points were awarded, and points leave a card only when a scheduled sweep runs.

This page is the setup checklist, for whoever configures the tenant: where each validity is set, the clock that runs the sweep, the decisions to make before go-live, and the check a week later that something actually expired. How a lot, the sweep and the till’s balance behave, and how to put points back, are on Points Expiry.

Where to do this

Set a validity on every source that awards points; a source left empty or at its default is how a programme’s expiry promise quietly fails.

  • A price-book Point treatment — Validity Period (Days) in Pricebook, counted from the moment the points are worked out (at the till when the line is added, or on the server when it fills them in).
  • An item’s pricing-scheme entry with points switched on, which replaces the price book’s points on that line — its Validity Period days, counted from the sale. The 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 (Pricing Scheme Rewards).
  • A commission scheme treatment — Validity Period (Days) in Commission Scheme, counted from the document date. It defaults to 0, and 0 means the points end on the document’s own date, so the first sweep takes them.
  • A manual adjustment or an upload — Valid Date From / To on Add Point Adjustment, or the validity columns of the Upload Member Point Transaction CSV.
  • A birthday gift — the validity in months on the scheduled gift, 12 if left empty (Birthday Gift).

Any point line saved with no dates at all is given an end date of 31 December 9000 and never expires, and points from a storefront order are written valid to 31 December 9999, so those never expire either.

The clock: schedule MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSOR (its name in the processor picker) in the Scheduler. It is not one of the clocks a new tenant is given, so if nobody schedules it, nothing ever expires. What it does when it runs, and why once a day while the tills are closed, is under Schedule the sweep, or nothing expires at all.

The evidence: the Points Expiry tab on the member, and the EXPIRY rows on the Point Transaction tab.

Decide before go-live

  • One validity convention for every source. If the price book gives twelve months and a manual adjustment gives none, the member’s balance is a mix of lots that expire and lots that never do. Check every commission scheme’s Validity Period (Days) too: a scheme left at 0 awards points that expire the day they are earned.
  • How members will hear that points are about to expire. The product will not tell them: MEMBERSHIP_POINTS_EXPIRY_REMINDER_PROCESSOR runs the same expiry as the elimination processor and sends no e-mail, and the one reminder e-mail the product has is sent only by an API call. The notice is yours — a campaign, a receipt line, a till prompt — and it belongs in your programme terms (Decide what the member is told).
  • Whether zero-balance members should go inactive. For a retailer that is usually wrong (a member who spent everything is a good member). MEMBERSHIP_STATUS_UPDATE_ZERO_BALANCE_PROCESSOR only acts on a currency coded ACCESS, and writes INACTIVE into the member’s extra properties rather than the member’s own status, so leave it unscheduled unless membership is points-funded and your currency carries that code.
  • The date the clock is first switched on. The first run removes every lapsed lot that still holds points, however old, in one night; the programme owner picks the date, members hear before it, and finance is told (Before you switch the clock on for the first time).

Prove that something actually expired, a week after go-live

A registered processor is not a scheduled one, and a scheduled one is not one that has run. The distinction is invisible from every screen in Membership Admin: an expiry policy written into your price sets looks identical whether or not anything sweeps.

So whoever configures the tenant checks it deliberately — the morning after the first run, and again a week after go-live — and it takes two minutes. Find a member with a lot whose end date has passed — the Points Expiry tab lists the dates — and look for an EXPIRY row on their Point Transaction tab dated after the processor’s first run. No EXPIRY row means nothing is expiring anywhere in the tenant, whatever the policy says, and the consequences run further than a member’s balance: finance is carrying a liability that will never be released (what you owe your members), and any breakage estimate built on zero EXPIRY lines has no evidence in it.

Do it again the first time somebody asks why nothing has expired. It is the same two minutes and it is a different answer from “it is scheduled”. The monthly version of the check, with what a negative balance after a sweep means, is How you know the sweep is working.

What this is not

Expiry does not post anything. The EXPIRY line reduces a balance; no journal is written and no breakage income is recognised (What the accountant sees). Recognising the release is a manual journal somebody posts in the period the sweep ran — what you owe your members.

When it goes wrong

Points that never expire, points that expired the day they were earned, a schedule that shows a run while lapsed lots stay, and a member below zero after a sweep each have a row, with the cause and the fix, under When expiry goes wrong. A lot that has been swept cannot be revived; only a new adjustment with a proper end date restores the points.