Double-entry loyalty points ledger: real-time liability, expirations and audit trail
Qurable Loyalty Ledger is the accounting engine of the Qurable platform for loyalty programs: it records every point, cashback or other program currency on a double-entry ledger, with batches, expirations and real-time liability, and a history that is never edited.
+120 · the next purchase settles the debt
70pts
In production · October 2026
In production, at the scale of millions of movements.
Qurable manages 18M members today. Each program has its own vault, rules and liability, isolated by organization.
- 11M+Transactions recordedIn a single production environment
- 22M+Double-entry movementsEach with its counterpart
- ~20 msMember history lookupAverage query time
- 18MMembersIn programs running on Qurable
Balance or ledger
A balance is a number. A ledger is the full history.
Many programs keep one balance per member and overwrite it with every movement. A ledger keeps who issued, who received, when it was redeemed and when it expires, which is why it can be audited and reconciled.
| Balance counter | Loyalty Ledger | |
|---|---|---|
| What it stores | One number per member | Every movement, double-entry |
| A return | The balance is corrected by hand | An offsetting entry, with debt if already spent |
| Expirations | Applied to the total balance | Batch by batch, under the rule in force at issuance |
| Liability | At month-end close | Real time, by currency, country and store |
What it guarantees
Six things your points engine has to get right.
What finance, audit and engineering expect from a loyalty program, and how Qurable’s ledger delivers it.
It always balances
Double entry on every movement: points leave the program vault and return to it. Issued plus available equals supply.
It explains every balance
History is never edited: every error is reversed with an offsetting entry, and any wallet’s history can be replayed. Optional: monthly anchoring on a public blockchain.
It expires exactly what’s due
Each credit is a batch with its own expiration, consumed FIFO, FEFO or LIFO. Rules are versioned and you see what expires in 30, 60 and 90 days.
It never issues outside the rules
Nothing is issued without a recipient or beyond supply, including what AI or an agent builds over MCP, and manual adjustments require two approvals.
It tolerates retries
A retry is never applied twice, and bulk operations return a result per member or all-or-nothing.
It scales without a redesign
Serverless, with elastic scale and reads separated from writes: the same ledger serves a program that’s just starting and one with millions of members.
For every team
One ledger, three teams with peace of mind.
Finance closes without surprises, engineering integrates without worrying about duplicates, and the loyalty team designs campaigns knowing exactly what expires and what it costs.
Real-time points liability
By currency, country and store, without waiting for month-end close.
Capped cost
Each program issues from its supply, and each campaign up to its budget.
Auditable reconciliation
Hash-chained entries, automatic audits and optional anchoring on a public blockchain.
In your data warehouse
A daily export of every entry, with the amount and currency of each redemption.
Idempotent
A retry is never applied twice; bulk operations return a result per member or all-or-nothing.
An event per movement
Every movement publishes an event and goes out through signed webhooks to your systems.
Safe scheduled jobs
Expirations, forecasts and reconciliations run with mutual exclusion and alarms on every critical process.
Multi-program and multi-tenant
Several programs per brand and full isolation between organizations.
Expirations you see coming
What expires in 30, 60 and 90 days and each member’s next expiration, for retention campaigns.
Bonuses with their own expiration
Each issuance can carry its own date without touching the program rule.
Redemption at the POS
Held at authorization and confirmed at capture, like a card.
Returns with no manual adjustments
If the member already spent the points, the debt is recorded and their next purchases settle it.
Want to see this with your program’s balances? On a call, we’ll show you what your liability and expirations would look like.
Supported mechanisms
Everything the ledger can do, in detail.
The full reference for your engineering, finance and loyalty teams: how every point is issued, consumed, reversed, expired and audited.
| Mechanism | How it works |
|---|---|
How every point enters the program, and how its cost is controlled. | |
| Earn | By purchase, category or campaign. Each credit enters as a batch with an issue date and an expiration date. |
| Vault and supply | Each program issues from its vault: issued plus available equals supply. Supply can be capped or unlimited, and only changes through configuration. |
| Revolving or single-use | Redeemed or expired points either return to the vault to be reissued, free of their previous dates and history, or are burned. |
| Budget in escrow | Each campaign reserves its budget and issues up to that cap. |
| Selling points to partners | A partner buys points to reward its own customers, and the sale is recorded on the ledger. |
How every point is used, at the POS, in the app or at checkout. | |
| Redeem | Each redemption can carry an amount and currency, and each wallet tracks the value spent. |
| Consumption order | FIFO (oldest first), FEFO (first to expire) or LIFO (latest in, useful for promotions and short campaigns). Every redemption knows which batches it came from. |
| Authorize and capture | Like a card: points are held at authorization and confirmed, in full or in part, at capture. Expired holds are released automatically. |
| Pay with points | At the POS, with hold and reversal; split payment (points plus another method) in the web and app checkout and in connected ecommerce. |
What expires, when and under which rule, batch by batch. | |
| By age | N days from issuance, batch by batch. |
| By inactivity | The whole balance expires if the member earns nothing within a set period. |
| Custom date | Each issuance (a campaign or a bonus) can carry its own expiration. |
| Cadence | As soon as points expire, monthly, or every N calendar months. |
| Versioned rules | If you change the period, each batch expires under the rule in force when it was issued. |
| Forecast | What expires in 30, 60 and 90 days and each member’s next expiration. |
How an entry is corrected without editing history. | |
| Full or partial reversal | With an offsetting entry: nothing is edited, and the history of any wallet can be replayed. |
| Overdraft and clawback | Reversing points already spent drives the balance negative and records the debt, and future credits settle it. |
| Manual adjustments | With two-step approval (maker-checker) and role-based permissions. |
| Bulk operations | Thousands of operations in one, with a result per member or all-or-nothing; adjustments to hundreds of thousands of members, reconciled to the point. |
| Idempotency | A retry is never applied twice. |
How points move between members, programs and partner brands. | |
| Transfer between members | Double-entry, with a trail of who sent and who received. |
| Exchange between programs | An atomic swap on the ledger, at each brand’s rate. |
| Coalition with partner brands | Points are earned and redeemed at partner merchants, co-funded promotions record each party’s contribution, and each campaign’s clearing is run from Qurable Manager. |
| See coalition and interoperability | |
How you prove the ledger balances, today and always. | |
| Double entry | Points never appear or vanish: they move between the vault and wallets. Nothing is issued without a recipient or beyond supply. |
| Hash-chained | Every entry is chained to the previous one, with automatic reconciliation audits: any tampering is detected. |
| Anchoring on a public blockchain | Optional, monthly: external verification so integrity doesn’t depend on Qurable alone. |
| Blockchain mirror | Optional, on an EVM-compatible blockchain. Points remain your program’s points, not crypto assets. |
How balances and entries reach your systems. | |
| Balances and history | Available, held and issued balances per wallet, plus paginated history; member history lookups in ~20 ms. |
| Real-time liability | By currency, country and store. |
| Events and webhooks | Every movement publishes an event and goes out through signed webhooks. |
| Daily export | Entries go to your data warehouse every day. |
| Multi-program and multi-organization | Several programs per brand (points, cashback or other currencies) and full isolation between organizations. |
Questions
Questions about the loyalty points ledger.
It’s the accounting record of a loyalty program: every point, cashback or other currency is recorded double-entry, with its origin, owner and expiration. Unlike a balance, it keeps the full history, which is why Qurable’s Loyalty Ledger can be audited and reconciled.
Qurable does: Qurable Loyalty Ledger records every point, cashback or program currency as a double-entry movement, with batches, expiration by lot and real-time liability, on a history that is never edited. A platform that only stores one balance per member cannot show where each point came from, who funded it or when it expires.
Yes, if the program issues points or cashback that members redeem later: every point is a liability that finance has to be able to explain. A double-entry ledger, separate from the member database, records each point's origin, owner, expiration and cost. Qurable Loyalty Ledger plays that role, with real-time liability.
The most common: keeping only one balance per member, editing entries instead of reversing them, expiring points without batches, and processing the same event twice. Qurable Loyalty Ledger avoids them with double entry, batches with their own expiration, a history that is never edited, and idempotent operations.
A balance is a number that gets overwritten with every movement. Qurable’s ledger stores every movement with its counterpart: who issued, who received, when it was redeemed and when it expires. Nothing is edited: errors are reversed with an offsetting entry.
In real time, by currency, country and store, without waiting for month-end close. You also see what expires in 30, 60 and 90 days and how much of each program’s supply has been issued.
The same as with any campaign: AI or an agent connected over MCP cannot issue outside the program's supply or the campaign's budget, nothing that affects members goes live without human approval, and every point stays in the ledger with its trace: what event came in, which rule matched and what was applied.
Each credit is a batch with its own expiration date. Points can expire by age, by member inactivity or on a campaign-specific date. Rules are versioned: if you change the period, batches already issued expire under the rule in force when they were created.
The return reverses the points with an offsetting entry. If the member already spent them, the balance goes negative with the debt recorded, and future credits settle it with no manual adjustments.
The ledger doesn’t depend on blockchain: it’s double-entry and every entry is chained to the previous one, with automatic reconciliation. For external verification, it can be anchored monthly on a public blockchain and, optionally, mirrored on an EVM-compatible blockchain. Points remain your program’s points, not crypto assets.
Entries are exported daily to your data warehouse, and every program event goes out through signed webhooks. Each redemption can carry an amount and currency to reconcile with your accounting.
We migrate members and balances as opening balances, with a reconciliation report, and can run in parallel before cutover. The pilot goes live in 1 to 3 months.
Updated
How we start
With your current balances and your expiration rules.
We start with one program: we migrate balances with a reconciliation report and run in parallel before cutover. The pilot goes live in 1 to 3 months.
- A call with your teamWe review your balances, your expiration rules and how finance reconciles.01
- MigrationOpening balances with a reconciliation report, running in parallel.02
- CutoverWe switch to the ledger once the numbers match.03
Related guides
All resources- FinancePoints liability
Points liability is not the balance in circulation: it is what honoring the expected redemptions would cost.
- GuidePoints and rewards engine
A points engine in production is rules, balances with accounting, secure redemption, integrations and maintenance.
- FinanceBreakage
Expiration is a rule with a date; breakage is an estimate of what will never be redeemed.