Rounding differences and where they come from

Almost every reconciliation has a residual too small to worry about and too persistent to ignore. It is rarely one cause. It is usually five or six, each contributing a few sen per transaction, and identifying them individually is what turns an accepted difference into a closed one.

The reason to bother is not the amount. It is that an accepted small difference is a place where a real error can hide indefinitely.

Where the sen actually go

Percentage fees on odd amounts. A proportional fee on an amount that does not divide cleanly has to be rounded, and the provider's rounding rule may not match your calculation. Multiply by every transaction and the divergence is systematic rather than random.

Tax on discounted lines. Tax calculated after an order-level discount that was itself allocated across lines involves two roundings, and reproducing both exactly is harder than it looks — see Shopify discounts, taxes and line-level allocation.

Currency conversion. Converting an amount and converting the sum of its parts give different answers. Which one your gateway did, and which one you did, decides the size of the gap — see currency conversion at checkout and who pays for it.

Payment rounding at the till. Malaysia rounds cash payments to the nearest five sen, so a store with any offline sales has a systematic difference between the invoice amount and the cash received. It is a real, expected difference and it needs its own treatment rather than absorption.

Partial refunds. Refunding part of a discounted order requires apportioning the discount, and the apportionment rounds.

Weight-based shipping and courier surcharges. Charged on rounded bands rather than on actual measurements, and the band boundaries are the provider's rather than yours.

Aggregation order. Rounding each line and summing gives a different total from summing and rounding once. Both are defensible; they are not equal.

Why they cannot simply be written off

Three reasons, and the third is the one that matters most.

They accumulate. A few sen on every transaction is a meaningful monthly figure at volume, and a meaningful annual one on any store doing real numbers.

They are systematic, not random. A rounding rule that differs from your provider's differs the same way every time, so the differences do not cancel out. They compound in one direction.

They provide cover. This is the real cost. A process that accepts a difference of up to some threshold will accept any error below that threshold, including a genuine one. A missing transaction, an incorrect fee or a duplicated refund of similar size passes through unremarked, because a difference in that range is expected.

An unexplained tolerance is a blind spot with a size you have chosen.

Getting rid of them, one cause at a time

The approach that works is to name causes rather than to tighten thresholds.

Take what the provider recorded. Do not recalculate a fee, a tax amount or a converted total that has already been stated. Their number is what happened; yours is an estimate of it. Reading rather than deriving eliminates several causes at once — this is the single highest-value change and it usually removes the majority of the residual.

Fix the rounding rule where you must calculate. Match the provider's direction and precision. Half-up and half-even give different answers, and consistency matters more than which one you pick.

Round once, at the end. Not at each intermediate step. Every intermediate rounding is a new small error.

Give the known ones their own account. Cash payment rounding is a real, explainable difference. Coded to a named account, it is a small explainable figure somebody can look at. Absorbed into revenue or into a tolerance, it is invisible and it is hiding whatever else lands there.

Measure the residual per transaction, not per period. A period total of a few ringgit tells you nothing. A consistent two sen per transaction tells you exactly where to look, because it points at a proportional calculation rather than a one-off.

What tolerance is actually for

Some tolerance is legitimate. The distinction is whether it is bounded and monitored or merely large enough to make the problem go away.

Set it as tight as your explained causes allow. If you have identified and eliminated your causes, the remaining tolerance can be very small.

Alert when the pattern changes. A residual that suddenly grows is a signal, and it is only a signal if the normal level is known.

Report the total, do not hide it. The monthly value of accepted differences should be a visible number. If nobody sees it, nobody notices it doubling.

Never let it exceed a real transaction. If your tolerance is larger than a typical order, a whole missing order fits inside it undetected. That is the line worth holding above all others — see keeping automated books healthy.

Rounding is not the interesting part of reconciliation. It is worth doing properly precisely so that it stops being where the interesting problems hide — see the exception queue and how to size it.

Common questions

Where do reconciliation rounding differences come from?

From several sources at once: proportional fees on amounts that do not divide cleanly, tax calculated after an allocated discount, currency conversion applied to a total rather than to its parts, cash payment rounding to the nearest five sen on offline sales, apportioned partial refunds, banded courier charges, and the order in which amounts are rounded and summed.

Why not just accept a small tolerance?

Because a tolerance accepts any difference below it, including a genuine error. A missing transaction, an incorrect fee or a duplicated refund of similar size passes unremarked, since a difference in that range is expected. An unexplained tolerance is a blind spot whose size you have chosen.

What is the single most effective fix?

Reading what the provider recorded rather than recalculating it. Fees, tax amounts and converted totals have already been stated by the party that applied them, so their figure is what happened while yours is an estimate of it. This removes several rounding causes simultaneously and usually most of the residual.

How should cash payment rounding be handled?

As its own named account rather than absorbed into revenue or into a tolerance. Rounding to the nearest five sen produces a real and explainable difference between the invoice amount and the cash received, and giving it a home makes it a small figure somebody can review instead of an invisible one that conceals whatever else lands there.

Related: decomposing a payout line by line · Shopify discounts, taxes and line-level allocation · the exception queue and how to size it