A Guide to Loyalty Program Financial Reporting

CFO’s often require credited actuarial opinions to showcase the liability of their loyalty programs. The goal is for the org to have clarity and peace of mind when liabilities are reported in financials.

Reporting loyalty programs with ASC 606 and IFRS 15 should not be difficult. We’ve compiled a list of tips for you to manage your programs and help direct your financial process. *Alpine IQ is not a financial advisor, please seek your own counsel to assure that you are in compliance.

Your reporting will also be based on your loyalty programs terms of use and individual mechanics you set within the Alpine IQ configuration settings. Disclosures often include:

  • Liability changes over time periods
  • Recognized rev in opening liability balances
  • When redemption’s/ rewards are given to satisfy the liability
  • Types of awards and sometimes even seasonality of those awards (tickets to concerts, lottery events, etc)
  • Estimates for timing of expiration of awards

You must manage these disclosures while also ensuring the performance of your loyalty program is positive. Keep in mind that over time your most loyal members will accumulate significant points causing them to push your breakage rate down.

  • Examine points earned, points redeemed, points expired, points gifted/ manually adjusted or multiplied via a promotional audience. Month over month points balances should stay stable unless your organization institutes time promotions, your member growth and return visits scales extremely quickly (additional redemptions will occur and point expiration will be delayed, however your CLTV will be much higher over time), quick expiration windows of points (90 days or less).

    Critical Note: Alpine IQ gives you several reports based on how you prefer to report/ model your program. You can download points reports for specific audience groups by date range or get automated balances monthly (See video). You may also access discounts + transactions they applied to via API assuming you are on a supported point of sale that sends Alpine IQ transaction ID’s (See Docu). If your point-of-sale does NOT send transaction ID or you leverage “Groupon style” redemption methodologies (i.e: Customer shows discount/ redeems via phone and not directly on the POS from a > Tier 3 integration) then you will not be able to tie redemption’s to exact sales within AIQ. Rather you would need to pull discount usage from your POS reporting directly and match it to UTC timestamps from redemption’s that occurred with your Alpine IQ ledger. This can be done by pulling redemption’s in our dashboard or via a downloadable CSV on the “Data analytics -> Member club (Tab in the report)”. This is also one of the main reasons you cannot remove “Purchase protection” from points expiration settings. Purchase protection is the act of resetting the number of days before points expire as long as the customer remains an active user by purchasing as a member during your expiration window. Alpine IQ enforces this methodology to avoid mass support and customer backlash for all redemption types on the platform and in the future of loyalty.

Here is an example of confusion that can occur at mass scale (Without purchase protection on points expiration):

DatePoints Notes
Jan 1stEarned 100Customer signs up and earns for the first time. These points are set to expire in 60 days On April 1st.
Jan 2ndRedeemed
100 and
earned 5
AIQ removes 100 points from their wallet but it does not know the transaction ID as these are married by your org for low tier level integrations.
April 1stCustomer record mergesCustomer record now merges with another older record that had 1000 points in it and some of the users purchases from February and the end of December. The user updated their phone/ email/ gov ID on their other account and they merge. Customer now has 1005 points total. (Note: It is common to have 3-15 merges per customer record over time in customer data platforms engaging with other tech stack items.)
April 2ndExpired 100 without customer coming to store.We now have expired 100 points earned on Jan 1st and they are now at negative -100 points. The consumer is confused and creates a support ticket + branding nightmare that drives your most loyal visitors away. Since AIQ has no idea which of the transaction ID’s to tie the Jan 1st redemption to. This is a simple example using only 1 customer merge and one UX path.

Here is an example a consumers experience (WITH purchase protection on points expiration’s):

DatePoints Notes
Jan 1stEarned 100Customer signs up and earns for the first time. These points are set to expire in 60 days On April 1st.
Jan 2ndRedeemed
100 and
earned 5
AIQ removes 100 points from their wallet and adds 5. They have 5 points as expected. The 60 day expiration timer now resets. If they do not make a purchase in the next 60 days, the 5 points will expire.
April 1stCustomer record mergesCustomer record now merges with another older record that had 1000 points in it and some of the users purchases from February. The user updated their phone/ email/ gov ID on their other account and they merge. Customer now has 1005 points total.
FUTURE EXPIRATION DAY60 days from the last purchase we have for this account, the customers points will be depleted to 0 as expected. Via this methodology you drive overall growth via avg basket size and control your liabilities via the types of rewards and discounts you offer at different tier levels. You can leverage the member club stats by order count table under (Data analytics -> Member club tab) to discover opportunities to improve retention.
  • Breakage estimates should allocate your redemption’s to points earned. When customers deplete their points for redemption, costs should be allocated to specific point earnings. However, FIFO (First-In-First-Out) reporting can be outdated for more modern programs running with points purchase protection. You should also not use FIFO when members can choose individual points to redeem from a specific order or for programs whose points expiration can vary by point (gifted, manually adjusted, multiplied points during time windows only for specific audience members, etc.)
  • Purchase protection for non FIFO based programs should be implemented to achieve high CLTV outputs from loyalty programs. Your main concern is around breakage balancing member loyalty and growing revenue. Ultimately estimating the percentage of open points that will never be redeemed. Liability = open points x (1-% breakage) x the projected cost of each point that is redeemed. This is a constantly updating calculation in quarterly financials. If your breakage forecasted is high then deferred revenue will be too low, requiring a material increase in program liability while the opposite will result in trapped revenue. Alternatively some programs will be projected using Fair-Value-Per-Point estimates in order to discover deferred revenue. This is also a dynamic estimate that changes based on tier/ reward levels available to members at any given time, currency exchange rate, inflation.
  • Accounting: Points earned should be placed in deferred revenue based on the value cost of the points with breakage used to calculate it. Redeemed points should be recognized as new rev which lowers your deferred liability. Points that expired wouldn’t be adjusted unless your deferred revenue incorporates point expiration estimates.

Please keep in mind that de-duplication of contact records can cause shifts in store by store liability. If a customers favorite store changes, the liability can be shifted to the new store. You can see edge case scenarios related to contact record CDP/ CRM operations via this article: https://support.alpineiq.com/how-customer-duplicate-merges-work