How to allocate one payment across multiple invoices without the cents going missing

A general trade distributor running snacks and packaged food out of a single depot had a collections routine that worked fine for years: the field rep visits a store, the store owner hands over cash or a UPI transfer, the rep marks invoices paid, everyone moves on. It broke the week a large supermarket account started paying in lump sums instead of invoice by invoice. The store's accounts team would transfer one round number — say ₹18,000 — against whatever was outstanding across four or five open invoices, and leave it to the distributor to sort out which invoice that money actually covered. Nobody upstream cared how it got split. The distributor's ledger cared a great deal, because "sort out which invoice" turned out to be a harder problem than it sounded.

The split that never quite adds up

The obvious approach is to apply the payment proportionally: if an invoice is 40% of the total outstanding, it gets 40% of the payment. That's a perfectly reasonable rule, and it's also where the trouble starts. Take four open invoices for ₹12,400.00, ₹9,860.00, ₹6,940.50, and ₹1,999.50 — a total outstanding of ₹31,200.00 — against a payment of ₹18,000. Each invoice's share works out to a number with more decimal places than a rupee amount can actually hold: ₹7,153.846..., ₹5,687.179..., ₹4,006.089..., and ₹1,152.884... Round every one of those to the nearest paisa, the way any sane display would, and you'll find the four rounded amounts sum to ₹18,000.01 or ₹17,999.98 — never, reliably, exactly ₹18,000.00.

For a single payment that's a rounding curiosity. For a distributor doing this dozens of times a day across hundreds of accounts, it's a slow leak. The office ledger and the bank statement stop matching by a few paisa on any day with a split payment, and a few paisa a day becomes real money and real hours at month-end reconciliation. Worse, some of that drift gets attributed to specific invoices — an invoice can show as "settled" while carrying a phantom one-paisa balance that never quite clears, so it keeps appearing on aging reports and collection call lists for stores that have, as far as anyone can tell, actually paid.

Where the real cost shows up

The supermarket account was the one that exposed it, but once the depot's accounts lead went looking, the same drift was buried across every account that had ever made a split payment — going back over a year. Some invoices sat at a balance of ₹0.01 or ₹0.02 indefinitely, too small to chase, too present to ignore, because they kept the invoice open in every collections report. A separate handful had drifted the other way: rounding had over-allocated by a paisa, so an invoice showed fully paid when a paisa of it technically wasn't, which meant the GST filing for that period reconciled against a total that didn't match the sum of the invoice-level entries it was built from — the exact mismatch a tax auditor is trained to flag.

The accounts lead's first instinct was to round differently — round up instead of down, or always round the last invoice in the list to whatever makes the total match. That's closer to correct, but "whichever invoice happens to be last" is arbitrary, and an arbitrary rule that happens to work today breaks the moment someone changes the sort order of the invoice list for an unrelated reason.

The fix: round every invoice, then patch the remainder deliberately

The actual fix is a two-step allocation, and it's a known pattern from anywhere money gets divided into whole units — it's the same method used to assign parliamentary seats fairly, usually called the largest-remainder method:

1. Calculate each invoice's exact proportional share of the payment, then round every one down to the nearest paisa. Summing these will always leave a small leftover — the payment minus the sum of the rounded-down shares.
2. Hand out that leftover, one paisa at a time, to the invoices whose un-rounded share had the largest fractional remainder — the ones that got shorted the most by rounding down. Once the leftover is exhausted, stop.

In the example above, that leftover is exactly ₹0.02, and it goes to the two invoices whose true share was closest to the next paisa up — not to the largest invoice, not to the first one in the list, and not by an arbitrary tie-break buried in whichever database query happened to run first. Every run of the same inputs produces the same result, the four allocated amounts always sum to exactly ₹18,000.00, and no invoice is ever left holding a fractional-paisa balance that can't be explained.

The second piece is doing this arithmetic in integer paisa from the start, not floating-point rupees. A percentage split done in floating point can produce a value like 7153.845999999998 instead of 7153.846, and which way that rounds depends on which library touches it — the same class of bug that causes invoice totals to disagree with the sum of their own line items. Convert the payment and every balance to integer paisa before doing any division, and the largest-remainder allocation becomes exact integer arithmetic with no ambiguity left in it.

What to check if your reconciliation keeps drifting

If your books show open invoices sitting at balances of a paisa or two that never clear, or your accounts team can't explain why a GST filing is a few rupees off from the invoice-level totals it was built from, this is worth checking before anything else:

• Find out whether split or partial payments are allocated by a percentage formula, and if so, whether that formula rounds each invoice independently — that's the exact bug pattern above.
• Check whether the sum of the allocated, rounded amounts is verified against the actual payment received at the moment of allocation, not just trusted.
• Confirm the allocation logic runs on integer smallest-currency-units, not decimal or floating-point rupees.
• Look for a documented, deterministic tie-break rule for handing out leftover paisa — "largest remainder first" or equivalent — rather than an implicit one based on list order.
• Pull a sample of invoices with sub-rupee outstanding balances and check whether they cluster around accounts that pay in lump sums against multiple invoices — that correlation confirms the diagnosis.

iotoms allocates split payments using the largest-remainder method against integer-paisa balances, so a single UPI transfer against five open invoices always sums to the exact amount received, with no invoice left carrying a phantom fractional balance for a collections team to chase.