A Guide to Loyalty Program Financial Reporting

LOYALTY FINANCIAL REPORTING

In this article you will find Best Practices for Financial Loyalty Reporting and FAQs.

Best Practices: Monthly Financial Report Vault and Schedulable Financial Reports

Below are tips for financial reporting for  loyalty programs with ASC 606 and IFRS 15. *Alpine IQ is not a financial advisor, please seek your own counsel to assure that you are in compliance.

Loyalty Financial Reports can be found under Settings : Loyalty Settings : Points Reports. The AIQ – Recommended Best Practices for Loyalty Financial Reporting is to utilize these reports exclusively to designate the financial liability from outstanding point balances.

USE CASE: These reports will show you the actual, usable loyalty point balances during the timeframe in which the reports are run. These are the ONLY reports in Alpine IQ that will display the true financial liability from outstanding points for the timeframe provided.

MONTHLY FINANCIAL REPORT VAULT: These are automatically created and report on the previous months data . Please compile these reports month over month to understand the financial liability of outstanding loyalty points across a larger time frame (than one month).

• Per Persona: You can report points based on each customer based on what they specifically redeemed, earned, etc. These records are not attached to a store and provide global liability.
• Per Store: You can also report points based on where the actions taken by the custom occurred (accrued points, redeemed points, etc.) as our system will attempt to assign a Persona’s points accrued / redeemed / expired to a store location to provide store level liability.
  • When a customer accrues points due to them doing something not tied to a specific store, those points are assigned to an “Unknown” row in the reports downloaded on a per store basis. These can be considered global liabilities.
  • Depending on your POS, some redemptions are “Groupon style” and rely on proper in-store SOP’s to align with Alpine IQ’s reports. Depending on your organization’s settings, it’s possible to have users redeem points without being at a store location. The opposite is also true with “Groupon style” redemption where if SOP’s aren’t followed properly, a clerk could simply give a customer a discount manually but they don’t actually collect the “coupon” by redeeming it with the customer. Most Alpine IQ clients leverage modern point-of-sale infrastructure which has Alpine IQ built in to redeem natively (AKA a Tier 3+ integration). Being natively integrated solves these discrepancies but it’s important for us to mention it in this article. 

SCHEDULABLE FINANCIAL REPORTS: These reports are identical to the Monthly Financial Report Vault Reports, however, they can be scheduled at different intervals beyond monthly (like the MONTHLY FINANCIAL REPORT VAULT)

Frequently Asked Questions

1. How do members earn points?
   1. Transactions: [Total spent on transactions] * [Point Accrual ratio]
   2. Visits: [number of visits (max applicable)] * [point per visit]
   3. Gifts / Boosts: When a customer falls into an audience or is sent a specific campaign there are options to boost additional points to the members’ loyalty accounts.
      1. Example: “When a customer abandons an online shopping cart, send them a message to come back and complete the order and gift them 100 points to incentivize it.”
   4. Points Multiplier: When a customer falls into an audience, they can receive a points multiplier on points accrued due to money spent on transactions or visits made while they are actively in the audience.
      1. Example “Purchase X brand name, get 2x points”, “Shop during 3-6pm and get 3x happy hour points”)
   5. Manual Adjustments: When staff member manually adds or subtracts points from an account.
   6. API-driven Integration Partners: Various integration partners you may have connected to your accounts.
      1. EX- Virtual clerk tools gifting points in exchange for customer reviews, flat csv files imported into your database with new points values, etc.
   7. Block Adjustments: When a customer’s points have a negative value, Alpine IQ deploys a ‘block adjustment’ to automatically adjust that user’s points back to 0. This is to protect you and your end consumers from a negative customer experience. You may turn off Block Adjustments by asking your account rep.
      1. Reasons Block Adjustments may occur:
         1. Bad merges resulting in a redemption made on an account that does not have the requisite number of points after the bad merge was corrected.
         2. Negative points adjustment by staff member or audience multiplier
         3. Changes to point accrual / point expiration settings which recalculates all historically accrued points for members. This causes some users to show that they accrued fewer points despite already having redeemed the requisite points before the point accrual logic was changed (example below)
      2. Example:  A clerk enters dummy information which causes two different members to incorrectly merge into one account. Persona 1 had 100 points, Persona 2 had no points, so the merged Persona resulted in 100 points. While this ‘merged Persona’ existed, Persona 2 redeemed the 100 points. Later, when the ‘merged persona’ is unmerged, Persona 2 now has “-100” as they redeemed a “100 point discount” without having the requisite number of points. A block adjustment would be applied here to get the member back to 0.
      3. Example: The original point accrual ratio is 100 points for every $1 spent and was live for 6 months. After 6 months of implementation, the point accrual ratio is changed to 1 point for every $1 spent. Upon changing the point accrual start date, all historically accrued points are re-accrued under the new point accrual ratio. This means members no longer had the requisite number of points to make the redemptions that already occurred. This would push them into the negatives. A block adjustment would be applied here to get the member back to 0.
2. How do I verify the report?
   1. If you are on a supported point of sale that sends Alpine IQ transaction ID’s, you may also access the discounts and the transactions they were applied to via API (). Additional documentation.
   2. If you are on a supported point of sale that DOES NOT send Alpine IQ transaction ID’s, or you leverage “Groupon style” redemption methodologies (i.e: Customer shows clerk discount and redeems via phone and not directly on the POS from a > Tier 3 POS) then you will not be able to tie redemption’s to exact sales within AIQ.
      1. 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)”.
3. Why do some Personas have negative point balances?
   1. This is a bug that is being corrected and should not occur in future reporting
4. How are the columns in the report calculated?
   1. starting_points: any event prior to the start date of the report is put here
   2. legacy_points: legacy point values (raw file import, pos import)
   3. points_earned: from sales/collectibles/visits
   4. points_boosted: from boosts/multipliers/referral sales
   5. points_adjusted: manual adjustments
   6. points_redeemed: redemptions
   7. points_expired: any points that have expired.
   8. points_net: legacy+accrued+boosted+adjusted-redeemed-expired
   9. points_start: points_net+starting_points
   10. starting_points: any event prior to the start date of the report is put here
   11. legacy_points: legacy point values (raw file import, pos import)
   12. points_earned: from sales/collectibles/visits
   13. points_boosted: from boosts/multipliers/referral sales
   14. points_adjusted: manual adjustments
   15. points_redeemed: redemptions
   16. points_expired: any points that have expired.
   17. points_net: legacy+accrued+boosted+adjusted-redeemed-expired
   18. points_start: points_net+starting_points
5. How do I understand my Report URL?
   1. Example URL:
      1. https://lab.alpineiq.com/public/emailReports/1005-1005-2022-07-31-2022-08-30-rd.cs
      2. https://lab.alpineiq.com/public/emailReports/[Account Id]-[Account ID]-[Date Range]-[Date Range]-[report type]
6. What are merges?
   1. How do they occur?
      1. The Default Alpine IQ Merge logic merges Alpine IQ Personas that have the same phone number OR the same email on both Alpine IQ Personas.
         – https://support.alpineiq.com/how-customer-duplicate-merges-work
   2. Why do they occur?
      1. Merges occur due to Alpine IQ receiving multiple records of the same customer profile. Multiple AIQ Personas can result from multiple profiles being derived from various integrations (POS vs E-Comm, etc.) in addition to duplicate customer profiles being created from the same integration (multiple POS profiles, etc.)
   3. Why are merges important?
      1. Alpine IQ’s original goal was to act as the source of truth by providing you with meaningful data acquired from multiple tech platforms. In order for this data to be meaningful, it must be de-duplicated. In other words, your data must be clean and not redundant. This is accomplished via Alpine IQ’s merges. This way, you know you are looking at meaningful and valuable data.
      2. Merges also play an important role in loyalty programs as merges will change a Persona’s loyalty status and allow that customer to become a loyalty member and accrue points. Merges also make sure every loyalty customer is receiving ALL of their points, even if some points were accrued on another POS customer profile.
   4. How do merges impact reporting?
      1. Negative Point Balances
      2. Changes in point balances
      3. Changes in data allocation (fav store associated with points activity)
         1. De-duplication of contact records can cause shifts in store by store liability. If a customer’s 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.
   5. What are bad merges?
      1. Bad merges are defined as ‘Alpine IQ merges that occurred for two unrelated or individual Personas’. In other words, a merge in customer profiles occurred that should not have occurred.
   6. How do bad merges occur?
      1. Under AIQ default merging Logic, bad merges occur due to a phone number or email being associated with more than one individual account.
      2. Situations to avoid and common reasons why a phone or email would be incorrectly associated on more than one:
         1. The clerk is entering in ‘Dummy Contact Information’: instead of the clerk entering the correct contact info, or maybe to satisfy a customer that does not want to provide the required contact info, the clerk enters in a filler ‘dummy email’ or ‘dummy phone number’ that they use across multiple customer profiles (in POS, AIQ, or otherwise). Even though these customers are unique and unrelated to each other, they will all be merged together as they share the same email or phone number.
            1. NOTE- this can negatively impact customer experience as well as point balances and loyalty access will change as a result of merges. Entering in ‘dummy information’ is STRONGLY discouraged
         2. A couple uses the same contact info for individual loyalty accounts: Couples should be discouraged from using the same (home) phone number or email for their loyalty accounts unless they would like to share one account between the two of them.
   7. Can I change my merging logic?
      1. Under the Advanced section of Loyalty Settings, you can change the logic so that merges only occur if the [first + last name] match and [date of birth] match. Therefore merges are independent of phone numbers or emails collected.
      2. Please reach out to your CSM to discuss important edge cases in doing so:
         1. Promotes inaccurate data collection: With less motivation to collect accurate phone and emails, it is likely that messy / inaccurate data will be collected at a higher prevalence. This means marketing opt-ins and communications will likely be impacted if we are consistently collecting invalid phones / emails that cannot be leveraged for marketing opportunities.
         2. It is possible, while unlikely, for someone to have the same [first + last name] and [birthdate] as another Persona and therefore could be merged incorrectly despite following the implemented merging logic. 
   8. What is Purchase Protection?
      1. Purchase protection is the act of resetting the number of days before points expire, as long as the customer remains an active 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.
         1. Example: Points expire 30 days after the customer’s last purchase.
         2. Purchase protection for non FIFO based programs should be implemented to achieve high CLTV outputs from loyalty programs. 
      2. FIFO (First-In-First-Out) reporting can be outdated for more modern programs running than programs 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.
   9. How do I run Breakage Estimates with Purchase Protection?
      1. 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.
         1. Your main concern is around breakage balancing member loyalty and growing revenue and therefore estimating the percentage of open points that will never be redeemed. 
         2. 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. 
         3. 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.
         4.  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.
      2. 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

DO NOT USE: Audience Points Reports

Audience Points Reports show Personas who are currently in the audience at the time the report is run, regardless of the date range ran. This means the Audience Points Report will retroactively change as merges occur.

 The logic reflected in the Audience Points Report reflects the current logic in the account and does NOT reflect the logic in the account for the time frame in question. This means if the same, historical Audience Points Report is generated multiple times, the reports  will vary over time and have a variable outstanding point balances as logic in your account changes.

Because Audience Points Reports will inherently change over time, they are considered dynamic and should NOT be used to determine the financial liability from outstanding loyalty points .

Examples of Changes in Historical Audience Points Reports (and why they should NOT be utilized):

1. Change in Expiration Logic
   1. Loyalty Program begins Jan 1, 2022
   2. Expiration Logic is Changed on June 1, 2022 and applied retroactively
   3. However, from Jan 1 2022 through May 31st, 2022, that expiration logic was not implemented. Therefore, actual financial liability of usable loyalty points during Jan 1 2022 through May 31st, 2022 should NOT incorporate expiration logic as that logic did not exist at that time.
   4. However, Audience Points Report WILL incorporate the expiration logic from Jan 1 2022 through May 31st, 2022 as Audience Points Reports utilize the EXISTING logic for the historical timeframe and NOT the historical logic when reporting on the historical timeframe.
2. Merges
   1. In August 2022, I was incorrectly merged with an unrelated Persona as the clerk was using Dummy Contact Information when collecting contact information at check out. This resulted in me having 300 points for August 2022.
   2. However, in October, it was discovered that I incorrectly was merged with another unrelated individual. So, in October 2022 I was unmerged resulting in me having a remaining point balance of 200 points (as 100 points were a result of the ‘bad merge’ and were therefore removed once the bad merge was corrected).
   3. If the August 2022 report is regenerated after October 2022, my outstanding point balance will reflect my ‘un merged’ account with 200 points instead of the ‘merged account’ with 300 points that was seen the first time the report was generated. This would cause variable financial liability as a result of the variable outstanding point balances seen within the same report, generated at different times (pre Aug 202 VS post Oct 2022).

To get the latest updates on our suite of services, make sure to subscribe to our blog today!