Points liability: the number your CFO sees before you do

Because it lands on the balance sheet before it shows up in your backlog. Every point a brewer's B2B loyalty programme issues is deferred revenue — a liability the CFO must carry and re-estimate every close. Engineering sees earn and burn events; finance sees one growing number that has to tie out across thirty markets, each with its own SKU-level earn rules. That reconciliation, not the earn logic, is the real project.

Why does the CFO see this before engineering does?

Because the two systems record different things. A loyalty engine records events: this retailer earned points on that case, redeemed some last week, has a batch expiring Friday. It is a fast, mutable ledger of member balances. The general ledger records an obligation — consideration collected for goods not yet delivered. When a retailer earns points on a purchase, the brewer has handed over a material right, an option on future product at below standalone price, and part of that sale has to be carved out and deferred until the points are redeemed or lapse. That deferred amount is a liability line in audited group accounts, and it grows every time the programme succeeds. The CFO watches it climb long before anyone in engineering connects a rising redemption rate to a balance-sheet figure.

The asymmetry matters because the order flow underneath it is not small. AB InBev's BEES platform, per its published full-year 2024 results, captured 49 billion US dollars in GMV and ran B2B digital across 28 markets, with 75% of revenues flowing through the platform. A points accrual sitting on even a low single-digit slice of that order flow is a nine-figure liability, not a rounding error an auditor waves through.

Why do per-market earn rules turn one number into a reconciliation project?

Because the single liability line is a sum of sums, and no two markets add up the same way. Earn rates are set per SKU to steer mix — a slow-moving lager earns more points than a fast one, because the whole point is to move the slow one — and that rate card differs by market, by season and by commercial priority. The redemption catalogue differs too, so the cost per point that converts an outstanding balance into money is not one constant but dozens. Add expiry rules that vary by jurisdiction, and the liability for one market is computed on entirely different assumptions than the liability for the next, even though both roll into the same disclosure.

This is the same fragmentation that makes a single promo answer to thirty legal regimes, and the same reason every OpCo rollout restarts from zero: the mechanic is shared, the parameters are local, and the parameters are where the accounting lives. Reconciliation stops being a query and becomes an investigation — assembling each market's earn detail, redemption history and breakage assumption, then proving they tie to the one figure the CFO signs.

Why is every earn mechanic a different liability?

Because the programme does not grant points one way; it grants them several, and each accrues differently. The most awkward is the challenge, where the platform pays a retailer points for completing a task — stocking a new SKU, hitting a promo target. Per the documented BEES retailer mechanics, points come with every purchase, with additional rewards for completing challenges, redeemable for discounts or free product. A challenge payout is not a discount on a sale that happened; it is consideration for a marketing action, and whether it nets against revenue or books as a separate cost is a judgement that has to be applied consistently across every market running that challenge.

No single row is the problem. The problem is that a live programme runs all of them at once, in different combinations per market, and the disclosure has to net them into one defensible figure. It is the same cost dynamic that makes most trade promotions lose money: the mechanic is cheap to trigger and invisible until it is booked.

Why doesn't the analytics module close the gap?

Because the module most suites hand you for this is a business-intelligence layer, not a ledger. In the Salesforce stack, points-liability reporting lives in Analytics for Loyalty, built on CRM Analytics — a dashboard engine sitting downstream of the transactional data. It has documented ceilings: per the CRM Analytics limits page, a single dataset supports up to 2 billion rows (as of September 2025), and the vendor's own Analytics for Loyalty limitations notes read as a list of things you design around, not through. Those are sensible numbers for dashboards. They are the wrong shape for an auditable liability, because a dashboard answers what the balance is now, while the accounting answers what the obligation is, on what assumptions, reconciled to which events, and defensible to whom. A BI layer summarises balances; it does not hold the general-ledger consequence, and it will not reconcile thirty markets' assumptions for you.

The way out is not a better dashboard. It is to treat the liability as a projection derived from the same earn, challenge, redeem and expiry events across every market — one event-sourced source of truth the disclosure reads from — instead of a spreadsheet re-stitched from per-market exports each close.

The pressure is one-directional. Trade-loyalty schemes are getting larger, more automated and more local at the same time: more markets, more challenge mechanics, more real-time redemption. Every one of those additions is another assumption feeding the same balance-sheet line, and audit scrutiny of how breakage and challenge costs are estimated is tightening, not relaxing. The brewers who wire loyalty as an accounting event stream from the first market will onboard the thirtieth with a config change. The ones who bolt reporting on afterwards will keep meeting their CFO at quarter-end, holding a number nobody can fully explain.