Why loyalty points liability still lives in a spreadsheet

Because most loyalty platforms treat accounting as an export, not a feature. They grant, expire and redeem points in real time, then hand finance a flat file of balances. Finance rebuilds the deferred-revenue liability, the breakage estimate and the IFRS 15 and ASC 606 disclosures by hand every period — in a spreadsheet whose logic no engineer owns and no auditor can trace back to the events that created the balance.

What does the loyalty platform actually hand finance?

A loyalty engine is very good at one thing: keeping a running points balance per member and moving it up on earn, down on redeem, and out on expiry. What it exports is that balance — a number, or a flat file of numbers. What it does not export is the general-ledger consequence of the balance. Every unredeemed point a brewer's trade-loyalty or consumer-rewards programme has issued is deferred revenue: consideration collected for a performance obligation not yet satisfied. That liability has to sit on the balance sheet, be re-estimated every close, and tie out to the penny.

The gap between the two is where the spreadsheet lives. As the widely circulated loyalty financial-reporting checklist from actuarial vendor Kyros puts it:

Deferred revenue, breakage estimates, liability updates, and ASC 606 and IFRS 15 disclosures all have to tie out, and most finance teams are doing it with spreadsheets.

The same checklist reduces the period-end liability to a deceptively small formula: Liability = Outstanding Points × (1 − Breakage) × Cost Per Point. Three inputs. The platform supplies the first, more or less. The other two — the breakage rate and the cost per point — are estimates finance has to defend to an auditor, and neither of them lives in the loyalty system.

Why is loyalty a revenue-recognition problem, not a marketing one?

Under IFRS 15, a points programme is not a discount. When a customer earns points on a purchase, the seller has given them a material right — an option to acquire future goods at less than standalone price — and that right is a separate performance obligation (paragraphs B39–B43). Part of the original transaction price has to be carved out and deferred until the points are redeemed or expire. The standard has been mandatory for annual periods beginning on or after 1 January 2018; the US equivalent, ASC 606, has bound public entities for periods beginning after 15 December 2017. This is not an emerging issue. It is closing on a decade of settled practice.

Breakage — points that will never be redeemed — is the part that turns accounting into forecasting. IFRS 15 does not let you book the windfall all at once. You recognise expected breakage as revenue in proportion to the pattern of actual redemptions, and only recognise the remainder when the likelihood of redemption becomes remote. So the liability is not a snapshot; it is a running projection that has to be re-derived every period from redemption behaviour. That is a modelling job, and the audit question is increasingly about the methodology behind the breakage assumption, not just the number it produced.

Where does the spreadsheet actually break?

Four places, reliably:

• Reconciliation. Each period, the transactional earn, redeem and expiry detail has to reconcile to the single outstanding-balance figure feeding the liability. When the export is a balance rather than the underlying events, that tie-out is a manual detective exercise, not a query.
• Breakage drift. The breakage rate is a formula cell copied forward from a workbook built years ago. The behaviour it models has moved; the cell has not. Nobody re-derives it, because re-deriving it means reassembling redemption history the platform no longer keeps in queryable form.
• Ownership. The workbook was built by someone on a revenue-recognition project who has since moved on. It has no tests, no version control and no lineage back to source events. It is load-bearing and unmaintained at the same time.
• Audit trail. When the auditor asks why the liability moved 6% quarter on quarter, the honest answer is often a chain of manual steps nobody can replay. The number is probably right. Proving it is the expensive part.

This is the same failure mode we see on the returnables side of the business, where brewers end up rebuilding empties and deposit liability in their own SAP Z-tables because the standard product stops at the physical move and leaves the financial one to them. It is also the same class of cost as the storage math nobody does upfront: invisible at selection time, structural by year three.

Why is this a cross-vendor gap rather than a bad product?

Because the shape of the problem fights the shape of the platform. A loyalty engine models a member's points as a mutable balance — a single row it increments and decrements. The accounting answer is a projection over history: to state the liability, and to defend the breakage curve underneath it, you need the full ordered stream of earn, redeem and expiry events, not the current total. A balance is a lossy summary of that stream. Once the events are discarded or archived beyond easy reach, the accounting truth cannot be reconstructed inside the platform, so it gets reconstructed outside it — in the spreadsheet.

That is why bolting a reporting module onto the loyalty product rarely closes the gap, and why the module you buy this year may not be the module you have next year: the export interface is the stable contract, and everything downstream of it behaves like a platform whose modules move faster than the team maintaining them. The vendors are not negligent. They optimised for the marketing job — earn and burn — and treated the general ledger as someone else's system of record. For a standalone loyalty SaaS that is a defensible boundary. For a brewer whose points liability shows up in audited group accounts, it is a boundary drawn in the wrong place.

What would actually close it?

Model the liability as a projection over the same event stream that grants the points, not as an export downstream of a balance. If every earn, redeem and expiry is an immutable event on a shared bus, the outstanding balance, the breakage curve and the IFRS 15 disclosure all become read models derived from one source — reproducible, testable, and replayable in front of an auditor. That is a deliberate event-sourced architecture choice, and it is the single design decision that moves loyalty accounting out of the workbook.

The pressure here only goes one way. Trade-loyalty schemes are getting larger and more automated, redemption is moving real-time, and audit scrutiny of breakage methodology is tightening rather than relaxing. A liability recalculated by hand once a quarter cannot keep pace with a programme that changes members' balances thousands of times a day. The brewers who treat loyalty points as an accounting event stream from the first line of code will spend the next few years shipping features; the ones who treat it as an export will spend them defending a spreadsheet.