ROUND Function in Excel: Syntax, Arguments and Examples

The ROUND function in Excel looks tiny on paper. Two arguments, one output. Yet it's behind more silent spreadsheet bugs than almost any other formula in the application. A purchase order that under-bills by a penny on every line. A pricing sheet that shows clean numbers on screen and ragged ones in the export. A bonus calculator that adds up to one dollar more than the sum of its parts.

This guide is a deep-dive on =ROUND alone — not the seven cousins (ROUNDUP, ROUNDDOWN, MROUND, INT, TRUNC, FLOOR, CEILING). For an overview of those, head to our how to round numbers in Excel primer. Here, we're going to live inside the parentheses.

You'll see what each argument actually does, how the function decides to go up or down, why negative digits are the most useful trick most users never discover, and the half-dozen gotchas that turn a clean model into a debugging nightmare. By the end, you should be able to read any ROUND formula in any spreadsheet and predict the output without testing it.

Start with the official syntax. The Microsoft signature reads =ROUND(number, num_digits). Both arguments are required. number is the value you want to round — a literal, a cell reference, or another formula's output. num_digits is an integer that tells Excel how many places to keep.

If num_digits is positive, ROUND keeps that many decimal places. =ROUND(3.14159, 2) returns 3.14. =ROUND(3.14159, 4) returns 3.1416. Easy.

If num_digits is zero, ROUND returns the nearest whole number. =ROUND(3.6, 0) returns 4. =ROUND(3.4, 0) returns 3. Also easy.

Now the interesting case — num_digits can be negative. That's where most people stop reading the documentation, which is unfortunate because that single feature is what makes ROUND so much more powerful than it first appears. We'll get to that in a moment.

How does Excel decide which way to round when the next digit is exactly 5? The answer is "away from zero." This is sometimes called arithmetic rounding or round half up for positive numbers and round half down for negatives. Either way, the rule is consistent: a tie pushes the result further from zero.

So =ROUND(2.5, 0) returns 3, not 2. =ROUND(-2.5, 0) returns -3, not -2. =ROUND(0.25, 1) returns 0.3. =ROUND(-0.25, 1) returns -0.3. The midpoint is always pushed outward.

This is different from banker's rounding, which rounds the midpoint to the nearest even digit (so 2.5 would round to 2, and 3.5 would round to 4). Banker's rounding is preferred in some statistical and financial contexts because it removes bias from large datasets — but Excel's built-in ROUND does not implement it.

There's a persistent myth on forums that =ROUND uses banker's rounding under the hood. It doesn't. Never has. The myth comes from VBA's older Round() method, which does use banker's rounding and behaves differently from the worksheet function. If you need banker's behavior in a worksheet, you'd build it with a custom formula or call Power Query's Number.Round with rounding mode 2.

Back to negative num_digits — the killer feature. Setting num_digits to -1 rounds to the nearest ten. -2 rounds to the nearest hundred. -3 rounds to the nearest thousand. The pattern continues for as many zeros as you need.

So =ROUND(1547, -1) returns 1550. =ROUND(1547, -2) returns 1500. =ROUND(1547, -3) returns 2000. =ROUND(1547, -4) returns 0 — because 1547 is closer to zero than to ten thousand.

Why does this matter? Three real cases. First, executive summary numbers. Finance teams rounding revenue to the nearest hundred thousand for a board deck reach for =ROUND(value, -5) rather than dividing by 100,000 and rounding manually. Second, chart axis labels — analysts producing clean ticks at every 5,000 use =ROUND(raw, -3) as a helper column. Third, statistical disclosure control — researchers and government agencies publish anonymized counts rounded to the nearest 5 or 10 to prevent identification of small subgroups, and the entire output column is =ROUND(count, -1).

One subtle behavior — when ROUND would return zero because the input is too small relative to the target rounding, the function still returns 0, not an error. =ROUND(45, -3) returns 0. Some users expect an error or N/A. There isn't one.

The first argument — number — accepts more than just literal numbers. You can pass a cell reference (=ROUND(A1, 2)), a range that gets coerced to a scalar in a single-cell context, the output of another function (=ROUND(SUM(B1:B10), 0)), or a text string that Excel can interpret as a number (=ROUND("3.14159", 2) returns 3.14).

If the text isn't parseable as a number — like "abc" — ROUND returns #VALUE!. If you pass a blank cell, Excel treats it as zero, so =ROUND(A1, 2) where A1 is empty returns 0. That last behavior catches people who expect blank to propagate as blank — it doesn't, because ROUND coerces empty to 0.

You can also pass a boolean. TRUE coerces to 1, FALSE to 0. So =ROUND(TRUE, 0) returns 1. Rarely useful, but worth knowing if you have boolean columns flowing into a rounding step from a conditional formula.

Errors propagate, naturally. =ROUND(#DIV/0!, 2) returns #DIV/0!. Wrapping ROUND around a formula doesn't hide upstream errors — it just passes them along.

The second argument — num_digits — is also more flexible than the documentation suggests. It must be an integer in spirit, but Excel accepts decimals and silently truncates toward zero. So =ROUND(3.14159, 2.7) returns 3.14, the same as if you'd passed 2. =ROUND(3.14159, -1.9) behaves like num_digits = -1.

This isn't a recommended pattern. Future-you reading the formula will wonder what 2.7 was supposed to mean. But if you're feeding num_digits from another formula that might emit non-integer values, you don't need to wrap it in INT or TRUNC first — ROUND already handles it.

If num_digits evaluates to text that's coercible to a number, the same rules apply. =ROUND(3.14159, "2") returns 3.14. If the text isn't a number — =ROUND(3.14159, "two") — you get #VALUE!.

One more — if you reference a cell for num_digits and the cell is blank, Excel uses 0. =ROUND(3.14159, A1) with A1 empty returns 3. Same coercion logic as the first argument.

Nesting ROUND inside other formulas is where it really earns its keep. The most common pattern is =ROUND(arithmetic_expression, decimals), which forces a clean result for downstream calculations.

Take =ROUND(A1*1.0825, 2) for applying an 8.25% sales tax. The raw multiplication gives 24.36825 or some such; ROUND snaps it back to 24.37. Without the wrap, you carry the fractional cent through every subsequent step, and your line totals stop matching when an auditor adds them by hand.

Another common nest — =ROUND(SUMPRODUCT(prices, qtys), 2) for invoice totals. But pay attention here. This rounds the total, not each line. For sales tax and VAT compliance in many jurisdictions, you need to round each line then sum. That requires moving ROUND inside the array: =SUMPRODUCT(ROUND(prices*qtys, 2)). The two formulas can return different totals when line items have small fractional contributions. The difference is rarely more than a few cents on a single invoice — but it's enough that tax authorities specify which method to use.

ROUND inside IF statements is another frequent pattern. =IF(A1>1000, ROUND(A1, -2), ROUND(A1, 0)) applies one rounding scale below a threshold and another above. Useful for dashboards where small numbers want decimal precision and big numbers want clean hundreds.

You can nest ROUND inside itself, too, though it's almost always a sign that something else is off. =ROUND(ROUND(A1, 4), 2) rounds first to four decimals, then to two. Mathematically that should be identical to a single =ROUND(A1, 2) — but it isn't always, because the four-decimal intermediate can change which side of a midpoint the value sits on. This is called double rounding, and it's a known source of off-by-one-cent errors in financial systems that round at multiple stages. If you see double-nested ROUND in someone else's spreadsheet, flag it for review.

For lookup tables that drive variable precision per row, =ROUND(value, VLOOKUP(currency, decimals_table, 2, FALSE)) is a clean pattern. Each row uses the appropriate decimal count without hard-coding. The earlier comment about non-integer num_digits being accepted means even VLOOKUPs returning something quirky won't break the formula.

One pattern people forget — ROUND on a date or time. Excel stores dates as serial numbers (days since 1900) and times as fractions of a day. So =ROUND(NOW(), 0) rounds the current date-time to the nearest whole day. =ROUND(time_value, 4) rounds a time to roughly the nearest minute (because one minute is 1/1440 of a day, which is about 0.0007 in serial form — four decimals captures that).

This works, but it's awkward. For time rounding specifically, MROUND with a time literal — =MROUND(A1, "0:15") — is far more readable. ROUND is the wrong tool when you want to snap to a non-decimal time multiple. Use ROUND on times only when you want decimal-place precision on the serial number itself, which is rare.

For more on choosing among Excel's rounding functions for time and other non-decimal cases, see our guide to rounding numbers in Excel. This article stays focused on ROUND.

Let's walk through the most common ROUND mistakes and how to spot them. First — confusing ROUND with cell formatting. Format Cells → Number → 2 decimal places changes what you see, not what Excel stores. The cell still holds 100.495 even when it displays "100.50". Any formula referencing it uses 100.495. If you need the actual stored value rounded, ROUND inside the formula is the only way.

Second — using ROUND when you meant ROUNDUP or ROUNDDOWN. ROUND uses arithmetic rounding (half away from zero), which means values just below the midpoint go down. Billing systems that want to guarantee no under-charge need ROUNDUP. Conservative estimators that want to guarantee no over-promise need ROUNDDOWN. Picking ROUND when business policy demands direction is a recipe for chargebacks or complaints.

Third — assuming negative arguments handle errors gracefully. =ROUND(value, -10) on small numbers returns zero. If your downstream formula divides by that result, you get #DIV/0!. ROUND won't warn you about extreme negative arguments.

Fourth gotcha — floating point representation. Excel stores numbers as 64-bit IEEE 754 doubles. Type 0.1 + 0.2 into a cell and the internal value is 0.30000000000000004, not 0.3. Most of the time this is invisible because Excel rounds the display for you. Once in a while it shows up as a sum that's a hair off from the obvious result, and users blame Excel for being broken.

The fix is simple — wrap the offending arithmetic in ROUND. =ROUND(0.1+0.2, 10) returns exactly 0.3. The 10 is generous; even =ROUND(0.1+0.2, 2) gives 0.3. The point is to throw away the binary float noise before it propagates.

This matters most when comparing computed values. =IF(A1+B1=0.3, "yes", "no") can return "no" if A1 and B1 are 0.1 and 0.2 due to that float artifact. Replacing the comparison with =IF(ROUND(A1+B1, 10)=0.3, "yes", "no") eliminates the bug. Same fix applies to comparing percentages, time differences, and any computed decimal you're testing for equality.

Fifth — text vs number coercion silently masking input problems. If a column you pasted from a PDF or Word document came in as text-formatted numbers, ROUND will happily coerce them and round each result. Looks fine. Then someone adds an apostrophe or a stray space character, and that cell breaks with #VALUE!. The fault isn't ROUND — it's data hygiene — but the error message points at the ROUND cell, leading hours-long misdirected debugging.

Wrap text-heavy inputs in =ROUND(VALUE(TRIM(A1)), 2) if you're not sure of the source. VALUE forces numeric coercion and TRIM strips whitespace. The cost is three extra function calls per row, which is negligible for any spreadsheet smaller than 50,000 rows.

Sixth — using ROUND where percentage display expects raw decimals. If A1 holds 0.255 and the cell is formatted as a percentage with one decimal, Excel displays "25.5%" — but =ROUND(A1, 2) returns 0.26, which displays as "26.0%". Round percentages by aligning the precision argument with the display intent: for one-decimal-percent display, use =ROUND(A1, 3) (three decimal places in raw form equals one decimal place in percent display).

Performance and recalculation behavior. ROUND is a deterministic, non-volatile function. It only recalculates when one of its arguments changes. This makes it cheap to use across thousands of rows; the spreadsheet won't churn through them on every keystroke.

Compare that to volatile functions like NOW, RAND, OFFSET, and INDIRECT, which recompute on every change to any cell in the workbook. If you nest a volatile function inside ROUND — =ROUND(RAND(), 2) — the whole expression inherits that volatility, and every cell of that formula recalculates constantly. For a workbook with 100,000 rounded random numbers, that's a measurable performance hit. The standard mitigation is to generate the random values once, paste them as values, and then round the static result.

ROUND itself is fast enough to ignore. A single ROUND call adds approximately 0.0001 ms in modern Excel versions. Even a million ROUND cells finish recalculating in well under a second. The function is essentially free.

A few advanced tricks worth knowing. ROUND combined with named ranges or LET makes complex formulas readable. Instead of =ROUND((A1*B1+C1*D1)*tax_rate, 2), you can use =LET(subtotal, A1*B1+C1*D1, ROUND(subtotal*tax_rate, 2)) in Excel 365. Same answer, far easier to audit.

For consistent rounding across an entire model, define a named formula. Formulas → Name Manager → New → Name: std_round, Refers to: =ROUND(value, 2). Now every cell that needs the model's standard precision calls =std_round, and if you ever change the policy from two to three decimals, you change it once.

For dashboards needing display rounding without altering underlying data, build a separate column for the displayed value: =ROUND(A1, 0) in column B, then reference column B for the visualization. Keeps the source data pristine and gives you a transparent rounding step that auditors can see.

For studying Excel function syntax at a deeper level, check the full Excel functions reference or our Excel formulas cheat sheet for printable tables covering every built-in function.

The ROUND function looks simple — and at the literal-syntax level, it is. The complexity lives in the corners. Negative arguments, floating-point noise, mid-formula nesting, text coercion, double-rounding bugs, currency-decimal mismatches. Master those corners and you'll be the person on your team who fixes the bugs everyone else can't find.