Loyalty liability, settlement and lineage on one ledger
Enterprise loyalty is financial infrastructure.
ReactorCX, the enterprise loyalty platform from Loyalty Methods, treats loyalty value as a ledger. Every accrual is recorded with its source rule, currency, brand, partner, timestamp and expiry; redemptions consume accruals in a configurable order; partner funding and settlement are calculated from the same lineage; and transaction-level records export to the general ledger. No estimated breakage, no black-box rollups.
Ledger
Member ledger · lineage view
| Entry | Balance Δ | Liability Δ | Funding | Audit ref |
|---|---|---|---|---|
| Earn · Brand A rule | + 250 | + 2.50 | Brand A | act-…41 |
| Earn · Partner-funded | + 100 | + 1.00 | Partner P | act-…42 |
| Burn · FIFO | − 200 | − 2.00 | Brand A | act-…57 |
| Expiry · lot 2025-03 | − 50 | − 0.50 | Brand A | sch-…08 |
| Adjustment · Member Care | + 20 | + 0.20 | Brand A | adj-…13 |
| Reconciled ✓ | 120 | 1.20 | settled to source | exported |
Every entry traces to an originating member activity
A points balance is a liability on the balance sheet.
A partner-funded offer is a receivable. A cross-brand basket is three sets of books. A misconfigured rule can create obligations faster than anyone notices. Marketing wants speed, IT wants stability, and finance wants a number it can defend. ReactorCX is built so the third does not have to wait for the first two.
Prior liability + earned − redeemed − expired = outstanding.
Each brand can produce the standard liability identity on its own books. One balance for the shopper. Separate books for every brand. Both are true at once, because the reconciliation happens at the line item, not the brand boundary. A platform that nets a mixed basket at the brand level has to guess at allocation, push the reconciliation into a spreadsheet, or accept that one brand is quietly subsidizing another's earn.
What ReactorCX records and controls
| Concern | What ReactorCX does | Where it surfaces |
|---|---|---|
| Accrual lineage | Each earn event is recorded as a separate accrual, tagged with the rule that produced it, the brand division that rule belongs to, and the member it credits. | Ledger, exports, execution log |
| Sub-balances and multi-currency | Points tag at the source and track as sub-balances inside one unified member wallet; multiple currencies per member. | Member State, Member Care Portal |
| Qualifying vs non-qualifying | Tier-qualifying and non-qualifying value tracked separately. | Tier evaluation, reporting |
| Burn order | Ordering rules decide which accruals are consumed first (for example FIFO) and tagging attributes redemptions to sources, partners, locations or promotions. | Redemption, settlement |
| Reversals | Points reverse against the exact accruals that produced them, at the brand that produced them. The original earn and its reversal both remain in the record; history is never rewritten. | Ledger |
| Expiry and breakage | Expiry per accrual lot with warning events from the Scheduler. Breakage is recorded from actual expiry lots; where the controller carries an expected-redemption-rate (ERR) reserve, it is computed alongside from the same lots and reconciled to actual expiry each period. | Scheduler, events, liability reports |
| Partner funding, escrow and settlement | Promotion funding allocation across parties, billing parameters on rules and partners, workflow-driven billing and reimbursement; date-relative co-marketing rules keep back-dated processing correct when rates change. | Partner wallets, settlement outputs |
| Financial guardrails | Per-day, per-week and per-offer limits; count limits; budget caps that deactivate an offer; cool-off periods. | Rules engine |
| Audit trail | Every transaction, rule execution and configuration change logged with full lineage; exportable for finance, compliance and reconciliation. | Execution log, exports |
| Ledger export | Raw granular records for finance systems to journal; bridging artifacts when ERP requirements call for them. | FeedXChange™, SQL, lake sync |
Sources: current ReactorCX enterprise-readiness and loyalty-engine pages. Capability level only; see the glossary for definitions.
How a mixed basket reconciles
One basket
Line items from Brand A, Brand B and a partner-funded offer in a single transaction.
Tagged line items
Each line carries its brand, partner, rule and currency.
Separate accruals
One accrual per source, each with its own lineage and expiry lot.
One member balance
The shopper sees a single wallet. Sub-balances stay attributable underneath.
Three P&L lines
Period close with no true-up. Each brand and partner books its own number.
Bring your chart of accounts. We will show the ledger against it.
Book a financial controls reviewWhat finance receives at close
- Liability by currency, brand, partner and lot age
- Expiry and breakage schedules from actual lots
- Partner settlement and reimbursement outputs
- Transaction-level exports for the general ledger
- An execution log that answers "why did this balance change" for any member
What ReactorCX does not do
It does not decide your revenue-recognition policy. Compliance with ASC 606 or IFRS 15 belongs to your controller; ReactorCX supplies the lineage that makes the policy auditable. Related: Partner Ecosystem and Analytics and Intelligence.
The detail your team will want to check
Expand what you need.
Pending, posted and the closePending versus posted, and what a close package containsTwo questions come up in every finance review: which balances are pending rather than posted, and exactly what arrives at period end.
Pending
An accrual that exists but has not vested: held in escrow until a return window closes, a stay is completed or a card transaction settles. It is on the ledger with its own state and is reported separately from posted liability, with its vesting date.
Posted
Vested and redeemable. Posted liability is what the balance sheet carries; it moves down by redemption, expiry and reversal, each a movement with lineage to the accrual it consumed.
Reversed, expired, redeemed
Each is a movement against a specific lot, never an edit to history. The roll-forward reconciles because every movement names the accrual it came from.
| Item | What it contains | Source |
|---|---|---|
| Liability roll-forward | Opening, plus earned, minus redeemed, minus expired, plus or minus adjustments, equals closing; by currency, brand and partner | Ledger |
| Pending balance and ageing | Escrowed accruals by vesting date and by the event that releases them | Ledger, escrow state |
| Expiry schedule | Posted lots by expiry month, forward twelve months, with the warning events already sent | Scheduler |
| Breakage | Actual expiry for the period alongside the ERR reserve where the controller carries one, with the variance | Ledger and reporting |
| Partner settlement | Funded lines billed at the contracted rate, one statement per partner, and the receivable or payable position | Partner wallets |
| Journal export | Transaction-level lines for the general ledger, with the bridging artefact the ERP needs | FeedXChange™, SQL, lake sync |
| Adjustments | Every manual adjustment with its reason, approver and the original activity it corrects | Execution log |
The package is assembled from the same records the member sees. Definitions in the ledger and lineage concept; accrual states in accruals, vesting and expiry.
Six terms finance will ask about
| Term | Definition |
|---|---|
| Points liability | The outstanding value of unredeemed, unexpired loyalty currency a program is obliged to honor, carried as a liability on the balance sheet. |
| Breakage | Loyalty value that expires or is forfeited unredeemed. ReactorCX records it from actual expiry lots; an ERR-based reserve, where policy requires one, is computed alongside and reconciled to actual expiry each period. |
| Qualifying points | Currency that counts toward tier status, tracked separately from non-qualifying currency. |
| Sub-balance | A tagged portion of a member's wallet attributed to a brand, partner, promotion or currency, kept inside one unified balance. |
| Burn order | The configurable rule that decides which accruals a redemption consumes first. |
| Partner settlement | The calculation and billing of amounts owed between a program and its partners, derived from the same tagged accruals and redemptions. |
Full definitions in the ReactorCX glossary.
Frequently asked questions
How does ReactorCX report points liability?
From accrual lineage: liability accrual and redemption lineage, breakage and expiration behavior, partner billing and settlement outputs, and reconciliation through exportable transaction-level data. Every liability number traces back to an originating member activity.
Can each brand in a multi-brand program keep its own books?
Yes. Brand-level rules stay independent, the member view stays unified, and cross-brand baskets reconcile at the line item to each brand's P&L.
How is partner settlement calculated?
From the same tagged accruals and redemptions, with billing parameters on rules and partners and date-relative co-marketing rules that keep back-dated processing correct when rates change.
Does ReactorCX estimate breakage?
It records breakage from what actually expired, lot by lot. Where the controller carries an expected-redemption-rate (ERR) reserve, ReactorCX computes it alongside from the same lots and reconciles the reserve to actual expiry each period, so the estimate and the actual are both in the record.
Can auditors trace a balance?
Every liability number traces to an originating member activity, and every rule execution is logged with what ran, why, and what data the platform used to decide.
Know that the numbers are right.
A Financial Controls Review walks your finance and audit teams through the ledger, liability reporting, settlement outputs and export formats on a program like yours.