Cashback Expiration Automation: A Promise the Database Never Actually Knew About

Telling a customer their cashback carries a validity period is a real, meaningful commercial commitment — and honoring it requires the underlying system to be able to answer, precisely and consistently, exactly how much of a given balance is set to expire, and on what date. A system with no column recording an expiration date, no process that ever checks one, and no distinct event type representing an expiration when it happens cannot honor that commitment even if every other part of the product intends to — the promise exists in commercial material and nowhere in the data model built to fulfill it.

A commercial commitment like "your cashback expires after a set period" is often written and communicated well before the underlying system is built out to actually track and enforce it — the promise is simple to state, while implementing it correctly requires deciding, and encoding, a genuinely non-trivial set of rules: which specific credits are consumed first when a customer redeems, how a deadline is computed consistently regardless of time zone, and how to keep a fast, incrementally-updated balance provably consistent with the full transaction history behind it. Without deliberately building each of those pieces, a validity-period promise can persist in customer-facing material for a long time with nothing behind it actually capable of expiring anything.

Centriu Loop's own cashback ledger previously had no expiration mechanism of any kind. The fix introduces two new ledger movement types — one representing an expiration event, one representing a chargeback/reversal — and a full batch ("lot") model built specifically to make expiration deterministic.

Every transaction that creates usable credit becomes its own batch: a purchase-earned credit, a positive manual adjustment, or a positive chargeback correction. Each batch that originates from an ordinary purchase reward carries its own expiration timestamp, computed from a validity period configured per organization (zero days means no expiration at all, preserving today's behavior exactly for any organization that has not opted into the feature). That computation deliberately stores each organization's own configured time zone rather than relying on whichever database session happens to compute it — a credit's deadline is now a fixed, specific instant regardless of who or what checks it, closing a gap the fix's own testing caught specifically at the edge of a calendar day, where the date matched but the exact instant did not.

Consumption — a redemption, an expiration event, or a negative adjustment or chargeback — is applied against those batches strictly in order of expiration date, soonest first, with creation date and the batch's own identifier as tie-breakers. That ordering is deliberately the one that favors the customer: whatever credit is closest to being lost is always drawn down before credit with more time remaining, so a customer with a mix of expiring and non-expiring balance never loses value earlier than the actual deadline requires. A dedicated database view computes exactly how much of each individual batch remains, by combining that same ordering with the customer's own total consumption to date — turning "how much is about to expire, and when" into a single deterministic calculation rather than an estimate.

A second view independently re-derives a customer's ENTIRE balance directly from the full transaction history — recalculating from scratch, rather than trusting any running total — and a third, dedicated reconciliation view compares that freshly-derived balance against the separate, incrementally-updated total actually stored for fast lookups, on every customer, continuously. Any divergence between the two — which should mathematically never happen if every part of the ledger is working correctly — surfaces immediately as a non-zero difference, rather than silently accumulating as an unnoticed accounting drift. A dedicated regression suite proves the underlying invariant directly: the sum of every batch's own remaining value, minus total FIFO consumption, always equals the customer's own available balance.

Before the fix, a customer told their cashback would expire after a set period had no corresponding record anywhere confirming when, or even whether, that would actually happen — the database had no column for it and no process that would ever act on one. After the fix, every credit the customer earns is its own dated batch with a specific, time-zone-correct expiration instant, and a redemption always draws down the batch closest to expiring first — the exact behavior a stated validity period is supposed to guarantee, now genuinely enforced rather than only promised.

Centriu Loop's cashback ledger now enforces a genuine, deterministic expiration mechanism — FIFO consumption by expiration date, a time-zone-correct deadline per credit, and a continuous reconciliation check between the ledger's own derived and stored balances — closing a gap where a validity-period promise made in commercial material had no corresponding enforcement anywhere in the database.

This automation covers specifically Centriu Loop's own cashback expiration and balance-reconciliation mechanism. It is a distinct mechanism from this pillar's separate page on the ledger's own append-only write protection, which concerns whether a ledger entry can be altered or deleted after the fact — a different, foundational guarantee this expiration mechanism is built on top of, covered on its own page.

Describing a validity period in commercial material is the simplest way to communicate a policy, and it costs nothing to write. It delivers nothing on its own unless the underlying system can actually compute, per credit, exactly when it expires, and consume balance in the order that honors that deadline. Building an explicit batch model with a deterministic consumption order, plus a continuous, automatic check that the ledger's own two ways of computing a balance always agree, is the only version of the two that turns a stated policy into something the database itself can be trusted to enforce and verify, rather than something a team has to hope is true.