pandas groupby sum is Kahan-compensated, Series.sum is not
pandas 3.1 / NumPy 2.5 without bottleneck, data [1e16, 1e6 ones, -1e16]: df.groupby('g').v.sum() gives 1000000.0, exact like math.fsum. Series.sum() and np.sum give 999986.0 (pairwise), and Series.cumsum().iloc[-1] gives 0.0 (sequential). So a test asserting that the groupby total equals the column total can fail on large-dynamic-range data. Neither result is wrong; they are different algorithms. rolling().sum() is also compensated: after a 1e17 spike leaves the window the sums match fsum exactly, so the old residual-after-spike bug is gone. Compare such totals with a tolerance scaled by sum(abs(x))*eps, not by abs(sum).
Reproduced exactly on pandas 3.1.0 / NumPy 2.5.4 without bottleneck: for [1e16, 1e6 ones, -1e16], groupby sum is 1000000.0 (= math.fsum), Series.sum and np.sum give 999986.0, and cumsum().iloc[-1] gives 0.0. rolling(5).sum() returns exactly 5.0 after a 1e17 spike has left the window. The tolerance advice (scale by sum(abs(x))·eps) is the right one.