Why Your Khalti Refund Reduced Next Week's Settlement

You issued a Khalti refund on Tuesday. The customer got their money back the same day. So far, so normal. Then next week's settlement lands and it is short by roughly that refund amount - with no obvious debit line explaining it. If you have ever chased that ghost, this article is for you.

The behaviour has a name: netting. And once you model it, the "short" settlement makes perfect sense.

Refund vs. reversal vs. netting

Three words that sound the same and are not:

• Refund - the customer gets their money back.
• Reversal - the original payment is undone as a standalone debit you can see.
• Netting - the refund is deducted from a future settlement batch rather than reversed on its own.

On Khalti, the merchant side typically nets. The customer is made whole immediately, but on your side the refund is carried forward and subtracted from a later payout. So the money leaves your books not as a clean "refund" line, but as a quiet reduction inside next week's settlement.

Why netting is actually sensible

Netting keeps the rails simpler and cheaper: instead of moving money back and forth for every refund, the provider just settles you the balance. The trade-off is that the merchant has to connect two events that are days apart - the refund, and the settlement that absorbs it.

That connection is the entire job. Do it, and your books are exact. Skip it, and you get a residual you cannot explain.

Tracking a refund to the exact payout

Here is the clean way to reconcile a netted refund:

• When you issue the refund, open an expected-netting record for that amount, tied to the original payment.
• Watch each subsequent settlement batch for a deduction that matches.
• When a batch absorbs it, close the record against that batch - now the refund has a home, and the settlement is no longer "short", it is correctly reduced.

Khalti helps here in a way eSewa does not yet: it documents a refund API (full and partial) keyed to the original payment, plus per-transaction fee data. So you can both initiate a refund programmatically and track it to the settlement it nets out of.

How RakamHQ handles it

RakamHQ models netting as a first-class state. When a refund is issued, it opens the expected-netting record automatically, then a watcher monitors your settlement batches and advances the refund to netted against the exact batch that absorbs it. The settlement that looked short is shown, in plain language, as reduced by refund #XXXX - with the evidence attached.

No ghost. No residual. Just a refund you can point to, all the way from issue to payout.