Rounding is a business rule: what your fee calculation actually charges

A fee calculator's arithmetic is mostly correct, but the rounding step is where support tickets arise. This last step is actually a business rule that determines if the on-screen number matches the charged number, especially in fee-heavy products where discrepancies are more common than expected.

Rounding direction - half-up, half-even (banker's), ceiling, floor, truncation - varies by language and is influenced by ties and negative numbers, which often involve money when refunds are involved. However, this decision is not a technical choice, but a business decision that should be documented in the fee schedule alongside the rates, not hardcoded in the formatter.

If the rounding mode is stored in code while the rates are in the database, changing the rounding rule requires a deploy, and until that deploy, numbers are incorrect by a fraction of a basis point. Additionally, the order of operations also affects the result. Fees are often computed as amount * rate, then converted, rounded, and summed.

Each step is a potential rounding point, and early rounding may lose or invent money. It is crucial to keep full precision through the pipeline, rounding once at the boundary where the number becomes money, and per line item rather than summing first and then rounding, when charging per fill.

Floating point is not the enemy, but it can be a trap. For instance, 0.1 + 0.2 does not equal 0.3 because of the way floats handle precision. A subtler trap is mixing data types: applying a Decimal rate to a float amount can result in a float, eroding the precision that has been carefully preserved. To prevent this, parse amounts to Decimal from strings and never let a float enter the calculation.

Testing rounding is distinct from testing arithmetic. Traditional methods like assertEqual are insufficient, as they fail to catch the ties that often occur. Instead, test the tie case for each rounding mode, the negative case (since refunds round differently from charges under half-up), and the reconciliation case, ensuring the sum of rounded line items matches the reported total for a random batch of data. This final test uncovers real bugs by examining the invariant rather than individual numbers.

This issue is more critical than the rate itself. Users tend to compare rates and then scrutinize the total. If the rate is 0.08% but the total suggests 0.083%, the conversation shifts from rounding to trust. The fee page is where a trading product is most likely to be accused of wrongdoing, and rounding is usually the actual explanation.

Implementing a schedule with the rounding mode stored as data, using Decimal end-to-end, and reconciling per-line rounding against the total addresses the core issue. Previous notes in this series covered related problems, such as modeling fee schedules as data and maintaining consistency when changes occur infrequently. The key takeaway: rounding is a business rule, so store it with the rates, keep full precision until the money boundary, round per line item, reconcile the sum, and rigorously test the ties.