pandas round() — round numbers without breaking the total

$ import pandas as pd

sales = pd.DataFrame({
    "region":     ["Yanbu", "Jubail", "Riyadh", "Dammam"],
    "orders":     [128, 94, 211, 57],
    "revenue":    [1234567.8912, 842110.4567, 2100333.0105, 456789.9876],
    "margin_pct": [18.4567, 12.0032, 21.9999, 9.4444],
})

report = sales.round({"revenue": 2, "margin_pct": 1})
print(report.to_string(index=False))
print("dtypes:", report.dtypes.astype(str).to_dict())
print("orders with decimals=2:", sales.round({"orders": 2})["orders"].tolist())

region  orders    revenue  margin_pct
 Yanbu     128 1234567.89        18.5
Jubail      94  842110.46        12.0
Riyadh     211 2100333.01        22.0
Dammam      57  456789.99         9.4
dtypes: {'region': 'str', 'orders': 'int64', 'revenue': 'float64', 'margin_pct': 'float64'}
orders with decimals=2: [128, 94, 211, 57]

This is the form that goes into every report function I write: one dict, one call, and a spec a reviewer can read. Money to 2, a percentage to 1, the region label and the order count untouched — and untouched means untouched: the labels are still 'Yanbu', not a rounded copy, and the int64 order counts keep their dtype. The last line is the trap that bites in code review. Asking for decimals=2 on an integer column changes nothing at all, and pandas does not warn: [128, 94, 211, 57] comes back as int64, so if you expected 128.0 you were about to do arithmetic on ints pretending to be rounded floats. If you genuinely need a float column, say so with astype — round() will not convert it for you.

$ import pandas as pd

lines = pd.DataFrame({
    "sku":        ["VLV-A12", "VLV-B07", "FLT-C31", "GTX-D44", "PMP-E19", "GTX-D45"],
    "qty":        [4, 9, 3, 7, 2, 5],
    "unit_price": [19.995, 4.445, 8.885, 2.225, 33.335, 6.665],
})
lines["amount"] = lines["qty"] * lines["unit_price"]
lines["printed"] = lines["amount"].round(2)

print(lines[["sku", "unit_price", "amount", "printed"]].to_string(index=False))
print("printed lines add up to:", round(lines["printed"].sum(), 2))
print("raw sum, rounded once  :", round(lines["amount"].sum(), 2))
print("difference             :", round(lines["printed"].sum() - lines["amount"].sum(), 2))

total = round(lines["amount"].sum(), 2)
lines.loc[lines["amount"].abs().idxmax(), "printed"] += round(total - lines["printed"].sum(), 2)
print("printed lines now add up to:", round(lines["printed"].sum(), 2))
print(lines[["sku", "printed"]].to_string(index=False))

    sku  unit_price  amount  printed
VLV-A12      19.995  79.980    79.98
VLV-B07       4.445  40.005    40.01
FLT-C31       8.885  26.655    26.66
GTX-D44       2.225  15.575    15.58
PMP-E19      33.335  66.670    66.67
GTX-D45       6.665  33.325    33.33
printed lines add up to: 262.23
raw sum, rounded once  : 262.21
difference             : 0.02
printed lines now add up to: 262.21
    sku  printed
VLV-A12    79.96
VLV-B07    40.01
FLT-C31    26.66
GTX-D44    15.58
PMP-E19    66.67
GTX-D45    33.33

The two-cent invoice, reproduced with three-decimal unit prices — the kind you get from a per-unit price times a quantity. Six rows, both numbers correct, and a 0.02 disagreement between the column the customer adds up (262.23) and the total pandas reports (262.21). Nothing here is a bug: round() decides each line on its own merits, and the sum of the raw floats carries its own drift. The four-line fix at the bottom is the pattern I use for anything that has to balance on paper — take the total from the unrounded values, then post the residual cents onto one designated line (here the largest, picked with idxmax) so the printed column adds up to the printed total. The residual is computed with round(total - sum, 2) rather than by assigning a constant, because that is what makes the code survivable when the data changes.

$ import numpy as np
import pandas as pd
from decimal import Decimal, ROUND_HALF_UP

pallets = pd.Series([0.5, 1.5, 2.5, 3.5, 4.5])

print("input           :", pallets.tolist())
print("pandas round()  :", pallets.round().tolist())
print("total           :", pallets.round().sum(), "vs", pallets.sum())
print("np.floor(x + .5):", np.floor(pallets.to_numpy() + 0.5).tolist())
print("Decimal HALF_UP :", [int(Decimal(str(x)).quantize(Decimal("1"), rounding=ROUND_HALF_UP)) for x in pallets])
print("Decimal default :", pd.Series([Decimal("2.5"), Decimal("3.5")]).round().tolist())

input           : [0.5, 1.5, 2.5, 3.5, 4.5]
pandas round()  : [0.0, 2.0, 2.0, 4.0, 4.0]
total           : 12.0 vs 12.5
np.floor(x + .5): [1.0, 2.0, 3.0, 4.0, 5.0]
Decimal HALF_UP : [1, 2, 3, 4, 5]
Decimal default : [Decimal('2'), Decimal('4')]

Five half-pallets, and pandas books 12 instead of 12.5 — half of the ties went down, and they went down because the digit before them was even, not because anything is broken. This is banker's rounding (round-half-to-even), it is documented in the docstring, and it is what IEEE 754 calls roundTiesToEven; the idea is that a long column of ties does not drift upward the way always-round-half-up does. When the business rule really is 'half a pallet is a pallet' — half-up, the way a human was taught — you have to say so: np.floor(x + 0.5) is the arithmetic shortcut, and it is fine for a column of small positive counts, though the addition itself is a float operation and will not save you at the edges of float64. The Decimal version with ROUND_HALF_UP is the one I would sign my name under for money. The last line is the sting in the tail: Decimals do not fix it, because the default decimal context is also half-even — Decimal('2.5').round() gives 2 if you do not pass a rounding mode.

$ import numpy as np
import pandas as pd

prices = pd.Series([2.675, 1.005, 0.125])
as_object = prices.astype(object)

print("float64 column:", prices.round(2).tolist(), "|", prices.round(2).dtype)
print("object  column:", as_object.round(2).tolist(), "|", as_object.round(2).dtype)
print("python round() :", [round(x, 2) for x in prices])
print("the tie inside :", repr(2.675), "* 100 =", repr(2.675 * 100), "=> rint:", np.rint(2.675 * 100) / 100)

float64 column: [2.68, 1.0, 0.12] | float64
object  column: [2.67, 1.0, 0.12] | object
python round() : [2.67, 1.0, 0.12]
the tie inside : 2.675 * 100 = 267.5 => rint: 2.68

Same three numbers, same call, two different answers — and the dtype you happen to have decides which one you get. On a float64 column round(2) hands off to numpy, which scales by 100, rounds the scaled value and divides back; for 2.675 that product is exactly 267.5, a perfect tie, and half-to-even pushes it up to 268, so you print 2.68. An object column takes the other branch — a per-element call to Python's round() — which looks at the true stored value 2.67499999999999982 and correctly returns 2.67. This is the kind of thing that makes a price list disagree with a billing system. The last line is the mechanism in one sentence, and it is worth keeping in your head: the scaling by a power of ten is where the half-ness comes from, not the rounding itself. If a cent of accuracy is contractual, do not let a float64 column near the calculation — parse to Decimal at the boundary and round with an explicit mode.

$ import pandas as pd

meters = pd.DataFrame({
    "meter":   ["M-0412", "M-0413", "M-0414", "M-0415"],
    "site":    ["Yanbu", "Yanbu", "Jubail", "Jubail"],
    "flow_m3": [10481.7742, 9982.3361, 12150.9183, 10883.5507],
})

avg = meters.groupby("site")["flow_m3"].mean()
print("site mean, 1 decimal :", avg.round(1).to_dict())
print("site mean, thousands :", avg.round(-3).to_dict())
print("per meter, hundreds  :", meters["flow_m3"].round(-2).tolist())
print("dtype after round(-2):", meters["flow_m3"].round(-2).dtype)

site mean, 1 decimal : {'Jubail': 11517.2, 'Yanbu': 10232.1}
site mean, thousands : {'Jubail': 12000.0, 'Yanbu': 10000.0}
per meter, hundreds  : [10500.0, 10000.0, 12200.0, 10900.0]
dtype after round(-2): float64

Negative decimals are the part of round() almost nobody uses, and they replace a whole family of divide-then-multiply hacks. round(-3) on a groupby result puts a flow total into thousands for an executive dashboard; round(-2) on the raw column snaps 10481.77 m3 to 10500 m3, which is how you plot a trend line without a legend full of decimals. Two practical notes. First, the call is a Series operation here — groupby(...).mean() returns a Series, and round() on it is Series.round, which takes an int only; if you want different places per site you are back to the dict form on a frame. Second, negative decimals round to the left of the point but they do not change the dtype: this stays float64, and it stays exactly as imprecise as it was. 12000.0 is not 12000 — for a report it does not matter, for a KPI store that is fed back into a calculation it does.