Cashback Rounding Precision Automation: A Cent Lost Every Time, Always the Same Way

Ordinary decimal fractions — one that ends cleanly at two or three places, the kind money is denominated in — frequently have no exact representation in the binary floating-point format nearly every programming language uses by default for a plain number. The classic, well-known example is that `0.1 + 0.2` does not equal `0.3` in most languages; the same underlying fact applies just as much to a single value like 0.615, which a calculator or a spreadsheet would round up to 0.62 without hesitation, but which a computer's own floating-point hardware stores as a value fractionally smaller than 0.615 — meaning a rounding function operating on that stored binary value rounds DOWN, producing a result a person doing the identical math by hand would never arrive at.

A calculation being written correctly, in the sense that its formula matches the intended math exactly, is a separate question from whether the number TYPE performing that calculation can represent every intermediate value exactly. Standard floating-point numbers trade exactness for a wide range and fast hardware arithmetic — a trade that is invisible for the overwhelming majority of everyday values, and specifically visible for currency, because currency depends on EXACT decimal values (never an approximation "close enough" for other purposes) and because a rounding function's own decision of which way to round depends entirely on which side of a threshold the stored value falls on — a question floating-point representation can silently get wrong even when every other part of the calculation was written with complete accuracy.

Centriu Loop's cashback-launch flow previously computed a sale's cashback amount as `(saleValue * percentage) / 100`, a plain floating-point calculation, then rounded the result to two decimal places with `Number(value.toFixed(2))` before applying an existing cap. That rounding step is the specific point of failure: `toFixed(2)` rounds against the number's own stored BINARY value, not the decimal value a person reading the formula would expect — and for specific combinations of sale value and percentage, those two are not the same number. The fix's own code comment documents a concrete, worked case: a R$ 12,30 sale at 5% genuinely computes to R$ 0,615, which should round up to R$ 0,62 under ordinary rounding rules — but 0.615, stored as a standard binary floating-point value, is actually approximately 0.6149999999999999911182, a value just fractionally below the halfway point, so the rounding function rounded it DOWN to R$ 0,61 instead. One cent, lost, on that specific combination of inputs, every single time it recurs — never randomly, because the same inputs always produce the identical binary approximation.

The fix replaces the entire calculation with integer arithmetic from the very first step. A sale's value in reais is converted to whole cents using `Math.round(reais * 100)` — a conversion the fix's own documentation confirms is exact for any value carrying at most two decimal places, because a single rounding step at that specific point corrects the tiny representation error before it can propagate any further. The cashback percentage, which the database stores with two decimal places of its own precision, is converted to hundredths of a percentage point (7.25% becomes 725) using the identical technique. From there, the entire multiplication happens in pure integers — cents multiplied by hundredths-of-a-percent, divided by ten thousand — with no floating-point division anywhere in the chain, and the final integer-cent result is converted back to a currency value only once, at the very last step, purely for display and for what gets written to the database.

The corresponding database function that actually applies and records the movement performs the equivalent calculation using PostgreSQL's own exact `numeric` type, with an explicit half-up rounding rule specified directly in the SQL rather than left to a default — so the two independent implementations, one in application code and one inside the database, are guaranteed to agree on every cashback amount by the shared design of the calculation itself, not by coincidence or by one side simply trusting the other's arithmetic.

A shopkeeper doing the math on a R$ 12,30 sale at 5% cashback by hand, or on an ordinary calculator, arrives at R$ 0,615 and rounds it up to R$ 0,62, the way rounding rules normally work. Before the fix, Centriu Loop's own system, computing the identical formula, silently arrived at R$ 0,61 instead — not because anyone made an arithmetic mistake, but because the number 0.615, stored as an ordinary binary floating-point value, is not quite 0.615. After the fix, the same sale computes entirely in integer cents and correctly produces R$ 0,62, matching the shopkeeper's own calculator exactly.

Centriu Loop's cashback calculation now runs entirely in integer-cent arithmetic, on both the application side and the database side, eliminating a class of one-cent rounding discrepancy that previously recurred silently and systematically on specific combinations of sale value and percentage — always in the same direction, for the same inputs, and invisible to a review of the formula itself.

This automation covers specifically how Centriu Loop calculates a cashback amount from a sale's value and percentage. It does not cover the separate database-level guarantees this pillar's other Loop pages document — that a balance can never go negative, that the ledger is append-only, or that an exact-balance redemption is correctly accepted — each of which addresses a different, independent mechanism inside the same broader cashback engine.

Performing a monetary calculation in an ordinary floating-point number type and rounding the final result is simpler to write and is correct for the overwhelming majority of specific input values — which is exactly what makes the defect easy to miss during normal testing. It becomes silently incorrect specifically when a particular combination of inputs produces a decimal value whose nearest binary floating-point representation falls on the wrong side of the rounding function's own threshold. Converting every value to an integer unit (cents, in this case) before any arithmetic happens removes the ambiguity entirely, because integer arithmetic has no equivalent representation gap to fall into — the only version of the two that is correct for every possible input, not merely the overwhelming majority of them.