Loyalty Program Software Problems: The 7 That Cost Real Money, and How to Avoid Each One

Why does the rewards catalogue always get built before the ledger?

Loyalty projects are funded by marketing, and marketing can see tiers, badges, a rewards catalogue and a member app. Nobody can see a ledger. So the first release ships with a points column on the member record that gets incremented and decremented, and everyone is happy until the first serious dispute.

This is specific to loyalty because points are money. Under IFRS 15 and ASC 606 points issued with a sale are a separate performance obligation, so part of the revenue is deferred until they are redeemed or expire. A stored balance cannot be replayed, cannot survive a duplicated message, cannot explain itself to a customer on the phone and cannot be reconciled to a deferred revenue figure. You have given a marketing feature custody of a balance sheet number.

Retrofitting is the expensive part. Adding an append only ledger after two years of stored balances means the opening balance for every member is an assertion rather than a derivation, because the history that would justify it was never recorded. The fix is a scope decision made in the first design session: the ledger is release one, and earn, burn, adjust, expire, transfer and reverse are all events carrying an idempotency key, an actor and a reason code. Balances are derived, never stored. The rewards catalogue can ship with three hardcoded rewards and nobody outside the project will notice.

What goes wrong when you migrate historic member balances?

Importing balances is a morning's work. Importing the history that justifies them is the project, and this is where loyalty migrations fail in public. Members open the new app, see a statement that starts at zero and tier progress that has reset, and your service desk absorbs the difference.

Two specific traps sit underneath. The first is expiry. If your old programme expires points per earn event and you import a single lump balance, you cannot expire it correctly. You either never expire it, in which case the liability only grows, or you expire the whole balance on one arbitrary date, which is a customer service event with a press cycle attached. The second is duplicates. The same person exists three times in the old programme under three email addresses, and merging them at migration either creates a windfall or destroys balances that a member can prove they earned.

The fix: import transaction history far enough back to cover both your tier qualification period and your longest expiry window, not just the balance. Model a member merge as an explicit ledger event that preserves the pre merge balances, so a bad merge can be reversed rather than argued about. Then run the old and new programmes in parallel for a full billing cycle with daily balance comparison, and only switch the customer facing surfaces once that comparison is clean.

Why do point of sale and ecommerce integrations break after launch?

The till integration passed testing against one point of sale software version. Your estate runs three. A store update rolls out in April, the message format shifts slightly, earn stops in 200 stores, and you find out in June from a complaint.

Retry behaviour is the second failure. Tills differ in how they handle a timeout, and a till that retries without an idempotency key on the source transaction awards twice. Refunds are the third. Ecommerce platforms commonly send a refund as a new transaction with a new identifier, so unless you link the reversal back to the original earn event, points come off the current balance instead. That is how members end up negative, and it is also how a fraud pattern hides, because a buy and return cycle stops looking like anything.

The fix is three things and none of them is clever. One integration contract per source, with the idempotency key taken from the source transaction identifier rather than generated by you. Contract tests run against every point of sale software version in the estate, treated as separate integrations in the plan and the budget. And a daily reconciliation job comparing transaction counts in the point of sale and ecommerce systems against events landed in the ledger, so a silent stop is a next morning alert rather than a quarterly discovery.

What happens when points liability accounting is not covered?

Finance needs a report showing opening balance, issued, redeemed, expired, adjusted and closing balance, reconciled to the ledger, with every manual adjustment attributable to a named person. Most loyalty platforms produce a dashboard instead, and a dashboard is not evidence.

The thing that actually breaks the reconciliation is the associate override. A member is standing at a till being told they have not reached the reward they can see on their phone, so the associate adds points. That adjustment has no reason code, no approval and no link to a transaction, and there are thousands of them a year across an estate. Breakage is the other half of the problem. Your breakage assumption determines how much deferred revenue you can recognise, and a rate set years ago and carried forward is exactly what an auditor will challenge.

The fix: build the liability report as a first class output in release one, not as a phase three reporting item. Derive breakage from your own cohort redemption curves, split by tier, channel and earn reason, because points earned in a promotion behave nothing like points earned on a normal basket. Give every adjustment a mandatory reason code and an actor. And settle your expiry policy before launch, because a programme with no expiry has a liability that only ever moves in one direction.

Should you build custom or configure what you already own?

A large share of retailers reading this should configure and stop there. If your programme is essentially single channel, your earn rule is a percentage of spend, your points outstanding are commercially small and nobody in finance is arguing about the liability, then Antavo will run it properly for a fraction of a build, and building a ledger to operate a stamp card is a poor use of capital. Punchh is well suited to restaurant and convenience operators who want its app experience. Salesforce Loyalty Management is the sensible answer if the group is already committed to Salesforce, with transaction cost and latency at till volume as the constraint to model before you sign.

Talon.One deserves a separate note, because it is frequently framed as a competitor to a build and should not be. It is a strong rules engine, and the sensible architecture in many groups is Talon.One evaluating what should happen while you own the ledger, the wallet, the statements and the reconciliation.

Build when two or more of these hold. Balances already differ by channel and your service desk reconciles them by hand. The liability is material enough that the audit conversation has become uncomfortable. Earn rules change weekly, which is normal in grocery and fuel and outruns a vendor configuration cycle. Your till estate is old, mixed or intermittently offline. Or you run partner earn, where each partner is a settlement relationship rather than an integration.

How do hidden costs get into the quote?

Five items account for most loyalty overruns, and all five are visible before signature if you ask.

• Point of sale estate counted as one integration. Three till software versions is three integrations, three test cycles and three rollout windows, not one with variations.
• Migration priced as a data load. It is a history reconstruction plus a parallel run plus a duplicate resolution exercise, and the parallel run is real project cost that people delete to hit a date.
• Partner earn priced as an application programming interface. Each partner brings settlement, reconciliation and a dispute process, which is accounting work wearing an integration label.
• Multi country priced as translation. Points with monetary value attract different tax and consumer protection treatment by market, and that needs local advice rather than a template.
• Finance sign off missing from the plan entirely. Agreeing the breakage method, the offline redemption policy and the adjustment controls takes real meetings and usually causes real rework.

The fix: make the quote name the till software versions in scope, state how many months of transaction history are being imported, and carry an explicit line for the finance workshop and the parallel run.

What separates a loyalty build that works from one that fails?

The builds that hold up share a small number of decisions. One append only ledger, with every channel reading the same derived balance rather than caching its own. Idempotency keys sourced from the originating transaction so a retry is harmless. Refund reversals linked to the original earn event rather than deducted from the current balance. Offline till behaviour agreed with finance in writing before launch, covering earn queuing, redemption decline and reconciliation on recovery. A liability report treated as a deliverable rather than a dashboard.

Two questions separate teams who have done this from teams who have not. Ask what happens when the same point of sale message arrives twice, and expect idempotency keys inside thirty seconds. Ask what the till does when the loyalty service is unreachable, and expect a specific answer about queuing earn and declining redemption while the sale completes, rather than a promise of uptime.

Then settle ownership before kickoff. The member ledger is the record of a promise you made to millions of customers and it carries a balance sheet liability, so the repository, the cloud accounts and the data must be yours. At Digital Heroes the client owns the code from the first commit, and any arrangement that parks your points ledger inside a supplier platform hands them the upper hand at every renewal.