How this instrument works
Currency has a smallest unit — the cent — but the arithmetic that produces a price rarely respects it. Split a $50 bill four ways and each share is $12.50 exactly, but split it three ways and each share is $16.666... dollars, a figure no register can charge. Round to the nearest cent finds the closest multiple of $0.01 to that raw figure, and it does the job with one small trick: round(x × 100) ⁄ 100 — multiply by 100 so the cents digit becomes a whole number, round that whole number the ordinary way, then divide by 100 to put the decimal point back where it belongs.
That scale-round-rescale move is the same one behind rounding to the nearest ten or the nearest whole integer: only the scale factor changes, from 100 down to 10 or down to 1. Cents sit two decimal places in, so 100 is the number that turns $19.987 into 1998.7, an ordinary decimal that ordinary integer rounding already knows how to handle. The general-purpose rounding sheet, which takes the number of decimal places as its own input, reproduces this exact result when set to two places; this page just fixes that choice for currency and drops the extra field.
The one place this identity gets interesting is the exact tie: an amount sitting precisely halfway between two cents, like $5.005. This calculator rounds ties up, to $5.01, the convention called round half up. Many programming languages default instead to round half to even, sending that identical amount down to $5.00 to avoid a statistical bias toward higher numbers across millions of transactions — and binary floating point adds a second trap, since a decimal like 5.005 usually cannot be stored exactly in memory at all. Both effects together are why Python's round(5.005, 2) famously returns 5.0, not 5.01, surprising anyone who assumes ties always round away from zero.
- Type the raw figure — before rounding, any number of decimal places — into the Amount field.
- The sheet multiplies by 100, rounds to the nearest whole number, and divides by 100 the instant you type.
- Read the answer in Rounded to the nearest cent; it always carries exactly two decimal places, ready to post as a real price.
- Test a suspected tie by entering an amount ending in exactly 5 ten-thousandths of a dollar, like 5.005, and compare the result against the FAQ below.
Worked example — a $19.987 wholesale unit cost
A supplier invoice lists a per-unit wholesale cost of $19.987 — three decimal places, the kind of figure that shows up in bulk pricing but can never appear on a customer's receipt. Scale it up: 19.987 × 100 = 1998.7 cents. The digit right after the decimal point is 7, past the halfway mark of 5, so 1998.7 rounds up to 1999. Divide back by 100: 1999 ⁄ 100 = 19.99. The Amount field returns 19.99 in Rounded to the nearest cent — the price a cash register can actually charge.
Multiply that unit cost across an order of 40,000 units and the gap between rounding correctly and simply truncating to $19.98 comes to $4.00 lost on one line item — small alone, systematic across a full ledger. The scale-round-rescale route shown here stays exact for any amount, because round(x × 100) only ever touches whole numbers once the scaling is done; nothing about the extra decimal places in 19.987 survives to cause a surprise later.
Questions
Why does rounding to the nearest cent matter if the underlying amount is already in dollars?
Currency only exists in whole cents once it changes hands — a price tag, an invoice line, or a bank ledger entry cannot display $19.987. Any calculation that produces a longer decimal, such as a percentage split, a per-unit cost, or a currency conversion, has to be forced onto the $0.01 grid before it becomes a real transaction, and round(x × 100) ⁄ 100 is the standard way to do that without disturbing the digits that do matter.
What happens to an amount that lands exactly on a half-cent, like $5.005?
This engine rounds it up, to $5.01, following the round-half-up convention: an exact midpoint always moves to the higher cent. Some systems instead use round-half-to-even, or banker's rounding, which would send that same $5.005 down to $5.00 because 500 is the even neighbor of 500.5 cents. Both are legitimate conventions; they only disagree at the single point exactly between two cents.
Why does a language like Python sometimes turn 5.005 into 5.0 instead of 5.01?
Two effects stack up. Python's round() defaults to round-half-to-even rather than half-up, so it already prefers 5.00 at an exact midpoint — and binary floating point cannot store 5.005 exactly in the first place, so the value actually held in memory is closer to 5.00499999999999989, which rounds down before the halfway question even arises. Scaling to whole cents first, then rounding with a half-up rule, sidesteps both traps.
Is round(x × 100) ⁄ 100 the same technique used to round to the nearest ten or the nearest whole number?
Yes, it is the identical scale-round-rescale move aimed at a different place value. Rounding to the nearest ten divides by 10 before rounding and multiplies back by 10; rounding to the nearest integer skips scaling altogether, since whole numbers are already the target grid. This sheet fixes the scale factor at 100 because currency's smallest unit is the cent; a general-purpose rounding sheet that takes the decimal-place count directly reproduces all three as special cases.
What if the amount already ends in a whole number of cents, like $10.00?
Nothing changes: $10 scales to exactly 1000 cents, an integer with no fractional part, so rounding leaves it at 1000, and dividing by 100 returns 10.00 unchanged. The formula is idempotent on any amount already sitting on the cent grid — running it a second time on an already-rounded result never moves the number again.
How is rounding to the nearest cent different from just truncating to two decimal places?
Truncating drops every digit past the hundredths place regardless of its size, so $19.987 would become $19.98, always down and never up. Rounding instead compares the discarded digits to the halfway point: 0.987's third decimal, 7, is past 5, so the true nearest cent is $19.99. Truncation is cheaper to compute but biased low across many transactions; rounding stays centered around the real value.