Report types

Loyalife organises reports into nine categories under Reports & Analytics. Each category has its own tab. Reports can be generated on-demand for a custom date range, or scheduled to run automatically at a set frequency.

​

Report frequencies

All report types support these scheduling options:

​

Report views

Within each category, three sub-views exist:

---

​

Transactional reports

Tracks every points activity event in the program — every credit and debit entry on the points ledger. When to use:

• Audit point accrual to verify rules are applying correctly
• Investigate a disputed transaction for a specific member
• Reconcile total points issued for a period against Rule Engine activity
• Identify unusually high-value transactions for fraud review

​

Transaction categories

When setting up a Transactional report, the Transaction Category filter narrows the output to a specific type of ledger movement. Selecting a category excludes all other movement types from the report.

---

​

Credit By Accrual

Points are credited each time the Rule Engine evaluates a submitted transaction and a matching earning rule fires. The transaction can arrive via the real-time API or from a TXN batch file uploaded over SFTP. How it works:

1. A transaction is submitted with the member’s Relation Reference, transaction amount, transaction type, and any custom attributes.
2. The Rule Engine checks every active rule group the member belongs to.
3. For each rule whose IF conditions are satisfied, the THEN reward (fixed points, multiplier, or percentage) is calculated and posted.
4. One credit entry per matching rule is written to the ledger, tagged as Credit By Accrual.

Use cases:

• Reviewing which transactions triggered which rules during a specific period
• Reconciling points issued against transaction volume
• Auditing accrual activity for a specific member or transaction type

Produced by: Rule Engine → Configuring rules, Data processing (TXN file), Insert Transaction API

---

​

Debit By Redemption

Points are debited each time a member exchanges their balance for a reward. Loyalife validates the member’s available balance before processing the redemption — if the balance is insufficient, the redemption is rejected and no debit entry is created. How it works:

1. Member initiates a redemption through the mobile app (Plum marketplace, partner catalogue, or cash-equivalent redemption).
2. Loyalife confirms the balance covers the redemption amount.
3. Points are debited and the reward is fulfilled.
4. The debit entry is tagged as Debit By Redemption with the reward type in the Narration field.

Use cases:

• Tracking total redemption volume and value over a period
• Identifying which reward categories are most popular
• Reconciling points redeemed against fulfillment records

Negative balance: Redemption is blocked if the member’s balance is less than the redemption amount. Debit By Redemption entries cannot result in a negative balance. Produced by: Plum marketplace, On-behalf redemption, Redeem Points API

---

​

Credit By Bonus

Bonus credits cover all point grants that originate outside the standard Rule Engine accrual flow. The ledger Narration field identifies the specific source. Use cases:

• Measuring the total bonus points distributed by campaigns vs. tier upgrades vs. referrals
• Auditing manual point adjustments made by admins
• Reconciling bonus file upload outcomes against the BNS file record count

Produced by: Broadcast campaigns, Triggered campaigns, Tiers, Referrals, Member profile manual adjustment, Data processing (BNS file)

---

​

Debit By Bonus

Debit bonus entries cover point deductions that are corrections or reversals rather than redemptions. These are always admin-initiated and recorded as a manual debit in the member’s transaction history. Negative balance: Unlike redemptions, Debit By Bonus entries are not blocked when the debit amount exceeds the member’s available balance. If an admin enters a debit larger than the current balance, the balance goes negative. A negative balance is visible in the member’s profile and in reports. This is intentional — it allows corrections for over-credited points without being constrained by the current balance. Use cases:

• Reviewing all point deductions applied by admins during a period
• Auditing accrual reversals linked to dispute resolutions
• Identifying members with negative balances caused by correction debits

Produced by: Member profile manual adjustment (debit direction), Maker-Checker approved debit transactions

---

​

Debit By Expiration

Points are debited automatically when they reach their scheduled expiry date. The expiry policy — period, schedule, and scope — is configured in Program Settings. Expiry runs as a system batch process; no admin action is needed. How it works:

1. Each credit entry on a member’s ledger carries an expiry date, calculated at the time the credit is posted based on the program’s expiry configuration.
2. On the scheduled expiry run, the system identifies all point batches whose expiry date has passed.
3. Any unexpired balance within those batches is debited. The entry is tagged as Debit By Expiration.

Use cases:

• Measuring how many points expired in a period versus how many were redeemed (liability conversion efficiency)
• Forecasting redemption pressure ahead of large expiry events (use with Projected Expiry report)
• Identifying members whose balances dropped to zero due to expiry — candidates for re-engagement

Negative balance: Not possible. Only points that were previously credited can expire. The expiry debit can equal but never exceed the available balance of the relevant credit batch. Produced by: Program Settings → Points & Expiry configuration (see Advanced configuration)

---

​

Debit By Cancellation

Points are debited when a qualifying transaction is cancelled after points have already been credited for it. The debit claws back only the points that were awarded for the cancelled transaction — other accruals on the member’s account are unaffected. How it works:

1. A transaction is submitted and points are credited (Credit By Accrual).
2. The transaction is subsequently cancelled — either by the merchant, the partner system, or via an admin action.
3. Loyalife posts a matching debit entry tagged as Debit By Cancellation, netting the member’s balance back to its pre-accrual state.

Use cases:

• Reconciling cancelled orders that resulted in points being temporarily credited then reversed
• Auditing cancellation activity to detect abnormal cancellation patterns
• Verifying the balance impact of a specific cancellation event for a member dispute

Negative balance: Not expected under normal operation — the debit is bounded by the points credited for that transaction. A negative balance would indicate the original credit was already partially or fully consumed before the cancellation debit posted.

---

​

Debit By Reversal

A previously accrued points credit is reversed and removed from the member’s balance. This is distinct from a cancellation — reversals are typically driven by data corrections, fraud findings, or administrative decisions rather than a transaction-level cancel event. How it works:

1. An accrual event was previously posted (Credit By Accrual or Credit By Bonus).
2. An admin or system process determines the credit was incorrect.
3. A reversal debit is posted, reducing the balance by the reversed amount.

Use cases:

• Auditing how many points were reversed in a period and by which admin
• Identifying members whose balances were reduced by reversals
• Reconciling reversal activity against dispute resolution records

Negative balance: Possible if the member’s balance at reversal time is lower than the reversal amount — for example, if the member redeemed points between the original credit and the reversal. A negative balance resulting from a reversal is valid and expected in these cases.

---

​

Credit By Reversal

Points are credited back to a member’s account when a prior debit — such as an expired points debit or an incorrectly applied debit — is itself reversed. This restores the balance to its state before the erroneous debit. How it works:

1. A debit entry was previously posted (any debit category).
2. The debit is determined to be incorrect or requires reversal.
3. A credit entry is posted, tagged as Credit By Reversal, restoring the reversed amount.

Use cases:

• Tracking corrections made to erroneous debit entries
• Auditing admin-initiated balance restorations
• Verifying that a specific debit has been fully offset by its reversal credit

---

​

Debit By On Behalf Redemption

Points are debited when an authorised agent completes a redemption acting on behalf of a member. The mechanics are the same as a standard redemption — balance is checked, points are debited, reward is fulfilled — but the entry is separately tagged so on-behalf activity is distinguishable from self-service redemptions in reports. How it works:

1. An agent with the On Behalf Redemption permission launches a marketplace session on a member’s profile.
2. The agent selects and completes a redemption.
3. The debit is posted as Debit By On Behalf Redemption with the agent’s identity recorded in the audit trail.

Use cases:

• Measuring the volume of redemptions assisted by support or relationship managers
• Auditing which agents are performing on-behalf redemptions and for which members
• Separating self-service redemption behaviour from agent-assisted behaviour in analytics

Negative balance: Not possible — the same balance validation that applies to self-service redemptions applies here. Produced by: On-behalf redemption

---

​

Credit by Point Purchase

Points are credited when a member purchases points directly using currency — for example, topping up their balance via a payment. This is separate from earning points through transactions; the member is explicitly buying points. Use cases:

• Tracking revenue generated from point purchase transactions
• Identifying members who actively buy points to reach redemption thresholds
• Reconciling purchased points volume against payment gateway records

---

​

Credit Transfer

Points are transferred into a member’s account from an external source — for example, from a partner programme, a migration event, or a peer-to-peer transfer where this member is the recipient. Use cases:

• Auditing inbound point transfers from partner integrations
• Reconciling balance migrations from a legacy loyalty programme
• Reviewing peer-to-peer transfer receipts (paired with the sender’s Debit entry)

---

​

Redemption Reversal

Points are restored to a member’s account when a completed redemption is reversed or cancelled after the fact — for example, a voucher that was never fulfilled, or a redemption that was found to be erroneous. How it works:

1. A redemption was completed and a Debit By Redemption entry was posted.
2. The redemption is subsequently reversed — either by the fulfilment partner, a support action, or a system correction.
3. A credit entry is posted, tagged as Redemption Reversal, restoring the debited points.

Use cases:

• Tracking how many redemptions were reversed in a period and the points restored
• Reconciling voucher fulfilment failures that required balance restoration
• Auditing reversal activity by support agents for disputed redemptions

Produced by: Admin reversal action on a member’s redemption, Reversal Points API

---

​

Member reports

Provides a snapshot and trend view of the member base. What’s included:

• Enrollment status and enrollment dates
• Activation dates
• Current tier for each member
• Current point balance per member
• Activity trends — active vs. dormant member counts over time

When to use:

• Identify dormant members for re-engagement campaigns
• Track program growth (new enrolments per period)
• Prepare a member count snapshot for stakeholder reporting

---

​

Communication reports

Monitors messaging performance across email, SMS, WhatsApp, and push notification channels. What’s included:

• Delivery status per message (delivered, failed, bounced)
• Open rates for email communications
• Click-through rates (where tracking links are used)
• Channel-level breakdown (email vs. SMS vs. WhatsApp vs. push)
• Campaign-level aggregates — total sends, delivery rate, engagement rate

When to use:

• Assess which message types or subjects get the highest open rates
• Identify delivery failures and clean invalid contact data
• Measure campaign communication effectiveness
• Compare channel performance (email open rate vs. push tap rate)

---

​

Liability reports

Tracks the total outstanding unredeemed points across the program — the current financial obligation to members. What’s included:

• Total unredeemed points balance across all active members
• Per-tier breakdown of liability
• Historical liability trend by month
• Points issued vs. points redeemed over time

When to use:

• Financial planning and accounting reconciliation
• Tracking changes in liability over time
• Assessing redemption pressure on the program
• Monthly close reporting for finance teams

---

​

Projected Expiry reports

Estimates upcoming points expiration, organised by month. What’s included:

• Points scheduled to expire each month, broken down by member group or tier
• Total expiry value per period
• Expiry distribution by earning date cohort

When to use:

• Forecast how many points will leave the ledger each month
• Plan a redemption-nudge campaign before a large expiry event
• Model the impact of changing your expiry policy

---

​

Administrative Data reports

System-level and operational logs for compliance and governance. What’s included:

• Audit trail — every administrative action with actor, timestamp, and before/after values
• User activity monitoring — logins, configuration changes, data access events
• Configuration change history — program settings, rule changes, tier updates
• Maker-Checker workflow history — all approvals and rejections with actors

When to use:

• Compliance and internal audit reviews
• Investigating unauthorized or unexpected changes
• Verifying separation of duties in approval workflows
• Preparing for regulatory audits

---

​

Logs

Detailed system activity history for technical and operational troubleshooting. What’s included:

• File upload history and processing status for TXN, CPD, and BNS files
• Records of rejected rows and the reason for rejection
• Error logs with error codes for failed processing
• API call logs (where enabled)

When to use:

• Diagnose why a TXN file upload processed fewer records than expected
• Identify which rows failed processing and why
• Verify file upload timing for SLA monitoring

---

​

Custom reports

Build personalised data views using SQL queries with complete control over fields, filters, and date ranges. Key capabilities:

• Write any SQL query against your Loyalife data schema
• Preview report results in real time without downloading a file
• Configure recurring schedules (daily, weekly, monthly)
• Generate one-time reports for custom date ranges on demand
• Control who can access each report via sharing settings

See Custom reports for full documentation.

---

​

Gamification reports

Tracks member participation and outcomes from gamification campaigns — scratch cards, spin-the-wheel, and other game mechanics. What’s included:

• Game participation events — who played, when, and which game
• Reward outcomes — points or vouchers awarded per play
• Campaign performance — total plays, win rate, points distributed
• Member-level game history

When to use:

• Evaluate the effectiveness of a gamification campaign
• Identify members who have played but not yet won (targeting opportunity)
• Calculate total points issued through gamification vs. standard rules
• Analyse engagement lift from game campaigns

---

​

Exported Data reports

Provides access to bulk data exports generated through the Loyalife export pipeline — member data, transaction history, segment outputs, and other large datasets. What’s included:

• Bulk member data exports (status, balance, tier, attributes)
• Transaction history exports
• Segment membership exports
• Custom data exports requested via the platform or API

When to use:

• Share full member data with an external analytics tool or CRM
• Extract historical transaction data for data warehouse ingestion
• Prepare large datasets for offline analysis that would be too large for in-portal custom reports
• Verify a bulk export completed successfully and download the output file

---

​

Report access control

Report visibility is controlled by the viewReports permission. All report categories use the same base permission — granular per-category access is controlled by your administrator.