What You Owe Your Members
A member buys a laptop at GS-KV-01 for RM 4,800 and earns 4,800 GSPTS. GadgetSphere has taken
RM 4,800 of cash and has also handed over RM 48 of future merchandise that it will have to supply
when the member comes back. The sale is not worth its face value: it is worth RM 4,800 less
whatever those points will cost to honour.
That is the whole idea, and it is why points are a promise to a customer rather than a marketing expense. A marketing cost is spent and gone. A point is an obligation that sits on your balance sheet until it is redeemed or it dies. It is the same shape as a gift voucher you sold, and an auditor will look at it the same way. This page is for whoever signs GadgetSphere’s management accounts: it is the month-end routine that puts that obligation on the books, the checks that tell you the number is right, and the questions to settle with your auditor.
Finance carries this, because the product does not
Nothing in the points chain posts a journal. The point-reward and point-redemption documents
carry no amount and no quantity, and the journal posting engine has no entry for them at all.
Awarding 4,800 points writes membership records and touches no GL account. There is no points
liability account, no deferred revenue, no accrual and no breakage income. Redeeming reaches the
ledger only as part of the bill it is spent on — a settlement line or a MEMBER_POINT_DISCOUNT
discount line — and that posting belongs to POS General,
not to this module.
One fact explains why no posting could simply be switched on: a member’s points belong to the member, not to a company. The same card earns and spends in every company of the tenant, so a journal would first need somebody to decide which company’s books carry each point. That decision is part of the procedure below.
So the liability is a procedure a person runs, every period, outside the product. It needs someone who can carry a judgement — the group finance manager, or whoever signs the management accounts — because half of it is an estimate. The clerk who exports the figures is not the person who should choose the breakage rate.
Three figures that should agree, and which one you value
BigLedger keeps a member’s points three ways, and each answers a different question.
| Figure | What it is | What it is good for |
|---|---|---|
| Transaction lines | Every earning, spending, expiry and adjustment, signed, with its date and — for points from a document — the company and branch of the bill | The movement in a period, by type; who earned and who spent |
| Stored balance | One running total per member and point currency, for the whole tenant | What the till offers the member today |
| Lots | One per earning, with the points still unspent and an end date | What is still owed, and when each part of it lapses |
Value the liability from the lots. They are the only figure that says when the obligation releases: group them by end date and you have the next twelve months’ expiry profile, which is the breakage release you can plan for. Take them through the lot query in the membership API and use the remaining points on each lot, not the member’s Points Expiry tab — its Balance Amount column shows each lot’s original points, so a lot the member has half spent still shows in full there.
Take the stored balance as well, because it is what members can actually spend. The two differ for reasons that matter to the number you book, and the next section is how to tell which reason you are looking at.
The month-end procedure, and who runs it
Run it on the last day of the month, at the same hour each time, before the period locks. All three figures move continuously, so a figure taken on the 2nd belongs to a different month.
Step 1 — take all three at the same moment. Export the live lots, the stored balances and the month’s transaction lines, and group each by member and point currency. If an expiry run is scheduled that day, take the figures after it has finished.
Step 2 — prove them against each other. For each member, the sum of their lines should equal the stored balance, and both should equal the unspent points on their live lots. Most members agree. The ones that do not fall into a handful of patterns, and When the three figures disagree, below, says what each means for the liability. Do this before you value anything: a balance the product has zeroed, or a negative balance netted against everybody else’s, understates what you owe.
Step 3 — decide what to do with points past their end date. A lot whose end date has passed
stays live until an expiry run removes it, and the till goes on offering those points in full.
For example, a member holding a lot that ended on 31 March can still spend it at GS-PEN-01 in
June. At GadgetSphere, 1.1 million of the 12.4 million GSPTS outstanding sit in lots that ended months
ago. If no expiry run is scheduled, members can still spend them, and in substance you still owe
them: keep them in. If you intend to schedule the run, the release belongs to the period in which
it actually runs, not the period the points were due to lapse.
Step 4 — value what is left. Points × your redeem rate gives the gross obligation: 12.4 million
GSPTS at 100 points to RM 1 is RM 124,000. That is the face value of the promise. How you carry
it — as revenue you have not yet earned, or as the cost of the goods you will hand over — is
a choice with consequences (Deferred revenue or a provision), and your auditor’s to agree.
Step 5 — take off breakage. Apply the share you have established will never be redeemed (see program design). If your evidence says 35% of an award cohort is never spent, RM 124,000 becomes RM 80,600, and the 35% is a number you can defend from your own transaction-line history rather than a rule of thumb. Write the assumption down in the file with the journal. It will be the first thing asked about. Do not count the same lapse twice: if Step 3 left lapsed lots out because an expiry run is coming, the breakage rate must not cover them as well.
Step 6 — post the movement, not the balance. The accrual already on the books is last month’s figure; this month you post the difference. Last month’s RM 78,200 against this month’s RM 80,600 is a RM 2,400 increase to the liability; reverse it when the liability falls.
Step 7 — tie it out. Points earned, less points spent, less points expired, plus or minus adjustments, over the same dates, must explain the change in the lot total. The transaction lines give you each by type. If the balance moved and your sales did not, an earning rule changed — ask the programme owner which, because nobody was told. Adjustments matter more than they look: the birthday gift, storefront points and manual corrections all arrive as adjustments, and leaving them out makes the tie-out fail by exactly that amount.
When the three figures disagree
| What you see | What happened | What it means for the liability |
|---|---|---|
| Stored balance zero; lines and lots positive | An expiry run zeroed the stored total and the rebuild queued behind it has not landed | Value from the lots. Ask BigLedger support to run the points recalculation for that member (Membership Admin has no button for it), so the till is right too |
| Lines and stored balance agree; lots lower | A bill that earned points was voided: the void removed its lots and left its lines and the stored total | The till still offers the voided points, so until somebody takes them back with an adjustment the member can spend them. Decide whether you owe them, and tell the programme owner |
| Lots higher than the stored balance | Usually, after a lot’s end date and before any expiry run, the member spent more than their in-date lots held. Spending draws only on in-date lots, so the lapsed lot was left whole | Value from the stored balance. When the expiry run comes it will expire points the member has already spent, and your release will be overstated by that amount — a known issue, reported to engineering |
| Stored balance below zero | Usually the case above, after the expiry run came | Treat it as zero. A member who owes you points does not reduce what you owe somebody else, so never let a negative row net off the total |
| All three agree, but some lots ended in the past | No expiry run has come | Step 3 |
| Lots ending on 31 December 9000 or 9999 | Points written with no end date: a price set with no validity period, an adjustment with no Valid Date To, an import row without validity, or storefront points | A permanent obligation with no release date. Value it without an expiry release, and change the earning rule if it was not meant |
The first and fourth rows are the ones that move a total silently. A zeroed balance hides a member from a stored-balance total, and a negative one subtracts from it — which is why Step 2 is done member by member rather than on the grand totals.
Deferred revenue or a provision
There are two defensible ways to carry the promise, and they give different numbers from the same lots. Which one applies is your auditor’s call; what follows is what each needs from BigLedger and what it costs you.
Deferred revenue. You treat the points as part of what the member paid for, and hold back that share of each sale until the points are spent or lapse. On GadgetSphere’s figures the liability is a little under the RM 80,600 above: sharing the RM 4,800 between the laptop and the points the member is expected to spend leaves the points slightly less than their face value — on a programme that gives back 1%, the difference is well under 1%.
Cost: revenue moves out of the month of the sale into the month of redemption, so your sales figure and your revenue figure stop matching; and you need a selling-price allocation and a breakage estimate you can defend every month. Under MFRS 15, and under MPERS for a private entity, award points are usually treated this way, as a separate promise to the customer.
A provision for the cost of honouring them. You recognise the whole sale as revenue and set aside what the merchandise members will take will cost you. If your cost is 82% of the shelf price, the same lots give RM 80,600 × 82% = RM 66,092. Cost: it is simpler and keeps revenue on the day of the sale, but it is the older treatment, and some groups keep it for management accounts only; agree it with your auditor before it reaches statutory accounts.
Either way the lot figure, the breakage assumption and the release at expiry are the same work. The choice changes the line the journal hits and the size of the number, not the procedure.
When points expire, you stop owing them
An expiry does not post either. The expiry line reduces a membership balance and writes nothing to the ledger, so the release of the liability is the same manual journal, in the opposite direction, in the period the expiry actually ran — not the period the points were due to expire.
Those are two different dates, and the gap between them is entirely in your hands: the run is the
points-expiry job (MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSOR in the Scheduler applet’s
processor list), it picks up every lot whose end date has passed, and it runs only when a Scheduler
clock runs it. A tenant is created without that clock. If nobody scheduled it or ran it by hand,
nothing has ever expired, your liability has only ever gone up, and the release you were expecting to bank this year
does not exist. One more thing to look for in that list: the processor named as the points-expiry
reminder runs the same expiry and sends no reminder — a known issue, reported to engineering — so a
clock for it is an expiry clock.
Whoever configures the tenant answers this in one look at the Scheduler; finance should ask them before relying on a breakage release, and ask again if expiry lines stop appearing.
Two smaller facts that change the number:
- “No end date” is a date in the year 9000. Points written without a validity get an end date of 31 December 9000 (storefront points, 31 December 9999), so they are found by end date, not by an empty one. Fixing them going forward is a change to the earning rule; the existing lots can be dated one at a time on the member’s Points Expiry tab (Point Expiry Edit writes the lot’s start and end date), or replaced by an adjustment that the member may notice.
- Which date the movement sits on. A points figure for a period can be read on the document date, the award date or the lot’s validity start, and they are not the same. Pick one, say which in the working paper, and use it every month.
Work out which company in the group owes it
A member’s balance has no company on it, and neither do the lots. The stored balance is one row per member and point currency for the whole tenant. The member record does have a company and a branch, but the award does not read them: a document from any company in the tenant earns points for any member. The points from a bill carry the company and branch of the bill they came from.
So in a group like GadgetSphere a card issued by GS is live in GSO and GSD too: points are
earned per company and held per tenant. A member can earn in the retail company and spend in the
online one, and across the groups we can see that happens in practice. Nothing in the product turns
it into an intercompany balance: when GSO honours a promise GS made, no entry says so.
The record you need does exist. Every time points are drawn from a lot — spent or expired — a contra row pairs the
line that used them with the earning line of the lot they came from. A redemption in GSO against a
lot earned in GS is one such pair, and the points on it, at your redeem rate, are what GSO gave
away on GS’s behalf. Group finance builds the settlement from those pairs, by company and month.
Two traps in building it:
- Expiry lines carry no company. To know whose liability an expiry released, follow its contra row to the earning line, which has one. Summing expiry lines by company gives you nothing.
- Some earnings carry no company either — points written by something other than a bill can arrive without one. Put them in a named bucket rather than dropping them, or the companies will not add back to the tenant.
The check that it was done right: the three companies’ figures sum to the single tenant-wide lot total. If the group has never done this, the first sign is an auditor asking which entity’s balance sheet the liability belongs on. The same fact settles a reporting question that looks unanswerable: points outstanding by branch is not available from the balance and has to be built from the lines.
How you know you got it right
Three checks, each a few minutes with the exports in front of you:
- The members reconcile. After Step 2, every member either agrees on all three figures or sits in a row of the disagreement table with its treatment noted. None is unexplained.
- The movement explains itself. Earned less spent less expired, plus adjustments, equals the change in the lot total, and the RM movement you posted is that change valued and breakage-adjusted the same way as last month.
- The companies add back.
GS,GSOandGSDsum to the tenant total, with any company-less points in their own named line.
If all three hold, the number is defensible. If the second fails by a round figure, look first for a month of adjustments you left out.
How this fits with the rest of membership
- What must exist first. Points reach a member only when the company’s points rule names the document your branches finalise; a rate row tells you what a point is worth; and the expiry clock in the Scheduler decides whether any of this liability ever releases (Membership in Depth → How the pieces depend on each other).
- What it makes possible. It lets you keep a balance sheet that carries the promise, plan the breakage release from the lots’ end dates, and settle between the group’s companies on evidence.
- The sibling. Points from the till, from the commission scheme run and from the web store are the same liability with different lots: web-store points are written to end in the year 9999 and never release, so a group that sells online carries a permanent slice.
- What breaks elsewhere when it is wrong. Change the redeem rate and every outstanding point is revalued overnight — the liability moves without a single sale, and so does what the till offers. Switch on an expiry clock for the first time and a year of lapsed lots releases in one run; agree with finance which month that lands in before it is switched on.
- What it pairs with. Program design for the breakage estimate, and the reports page for the queries.
What you settle with your auditor, and not with us
- Which treatment applies and how it is presented — deferred revenue or a provision, gross or net of breakage. What is certain is that the obligation exists and the product does not carry it.
- Whether points expire at all under the law you trade in. The product will expire them the moment you schedule the run; whether you are entitled to is a question for whoever approved your terms.
Related documentation
- Program design — read this next: pricing the promise, and estimating the breakage this procedure depends on.
- Reports — the queries this procedure is built on.
- Points expiry — the lot model and the run.
- Point currencies and balances — line, lot and balance, and which of the three the number came from.
- Walk the chain — when one member’s points look wrong.