How do you round money in Python so a payment reconciliation job matches the ledger to the cent?

## The symptom A payment reconciliation job compares its own computed totals against a ledger and finds a handful of rows off by one cent — never many, never reproducible from the aggregate, and always on amounts that end near a half cent. That is the signature of rounding, and there are three independent causes worth separating. ## Cause one: the values were floats If an amount ever passed through a `float`, the decimal digits are already approximate and `round(x, 2)` rounds whichever side the stored binary value happened to land on. Worse, the fix people reach for first — wrapping it in `Decimal` — does not help if the float is the input: ```python from decimal import Decimal, ROUND_HALF_UP print(Decimal(2.675).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)) # 2.67 print(Decimal('2.675').quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)) # 2.68 ``` The constructor converts a float *exactly*, error and all. Money must become a `Decimal` at the point it enters the process — from the request body's string, from the database column, from integer minor units — and never round-trip through a float on the way. ## Cause two: the rounding mode was never chosen `quantize` uses the current decimal context's rounding when you do not name one, and that default is `ROUND_HALF_EVEN`. Half-to-even is the right statistical default and the wrong invoicing default: most tax and billing rules specify half away from zero. So `Decimal('2.5').quantize(Decimal('1'))` gives `2`, while the same call with `rounding=ROUND_HALF_UP` gives `3`. Pass the mode explicitly at every call site that rounds money. Setting it globally on the context is possible, but it makes the behaviour of a helper depend on where it is called from, which is precisely the ambiguity you are trying to remove; if you do change it, scope it with a context manager rather than mutating the process-wide context. The mode is a business rule. Write it down next to the code, because someone will ask which regulation it implements, and 'the default' is not an answer. ## Cause three: rounding happened at the wrong point, or twice Rounding each line and summing is not the same as summing and rounding once. With enough lines the two answers diverge by several cents, and the discrepancy grows with the batch size — a batch spanning seventeen line items can easily land a few cents apart from the same batch totalled the other way. ```python from decimal import Decimal, ROUND_HALF_UP CENT = Decimal('0.01') lines = ['12.345', '0.005', '7.125', '2.675'] per_line = sum(Decimal(a).quantize(CENT, rounding=ROUND_HALF_UP) for a in lines) once = sum(Decimal(a) for a in lines).quantize(CENT, rounding=ROUND_HALF_UP) print(per_line, once) ``` Neither is wrong in general; only one matches the ledger. Find out which the counterparty does, encode that decision in one place, and make every path go through it. The failure mode is that half the codebase rounds on write and the other half rounds on read, so the mismatch depends on which side of the boundary a value entered from. ## Making it stick * One module owns money. A single `to_cents(amount)` helper that takes a string or `Decimal`, quantizes with the documented mode, and returns a `Decimal` — with the raw `quantize` call appearing nowhere else. * Consider integer minor units as the storage type. Storing cents as an `int` removes rounding from every intermediate step and confines it to the two conversions at the edges; it is the simplest correct choice for a system that never needs fractional cents. * Watch for `decimal.InvalidOperation`. `quantize` raises it when the result would need more digits than the context precision allows, which turns a silently wrong total into a loud failure — but only if you do not swallow it. * Test the boundaries, not the middle. Fixtures that end in a half cent — and their negatives, for refunds — are where the off-by-one lives. Values that round unambiguously prove nothing. * Reconcile with exact comparison. Once both sides are `Decimal`, equality is meaningful and a tolerance window is no longer a substitute for correctness. ## What a strong answer sounds like Name the type boundary, the explicit rounding mode, and the single rounding point — in that order — and say that the mode is a business rule rather than a coding preference. Candidates who answer only 'use Decimal' have solved one of the three causes and will still be a cent out.