Track every refund to the exact payout it left from.
A refund on a Nepali rail rarely reverses on the spot - it is netted from a future settlement. RakamHQ executes Khalti refunds and tracks every refund to the batch that absorbs it.
Refunds are where books drift. The customer is made whole immediately, but on the merchant side the refund is often netted - deducted from a later settlement - so a payout looks mysteriously short with no obvious debit to explain it.
RakamHQ models netting as a first-class state. When a refund is issued it opens an expected-netting record, then watches your settlements for the deduction and closes it against the exact batch that absorbs it.
What you get
- Programmatic Khalti refunds, full and partial
- Refund role, reason code and per-day value cap
- Netting modeled as a first-class ledger state
- Each refund tracked issued → refunded → netted(batch)
- eSewa refund states detected from status polling
- Same-instrument enforced; cash-refund flows blocked
Refunds & netting, in detail.
Execution, safely
Where a rail supports it - Khalti today - RakamHQ can execute a refund, full or partial, but only behind a separate refund grant, a mandatory reason code, and a per-day value cap you set. Same-instrument is enforced, so cash-refund flows are blocked. Every step, from draft to provider result, is written to an audit trail.
Through the Khalti refund API
A refund goes out through the Khalti refund API against the original transaction, so money returns on the same instrument the customer paid with. RakamHQ records the provider's response, the resulting refund id, and the acting user, then holds the refund open until the deduction actually appears in a settlement. Nothing is assumed done on the request alone.
Netting, tracked to the batch
Issuing a refund opens an expected-netting record. A watcher then monitors subsequent settlements for the matching deduction and advances the refund to 'netted' against the specific batch it lands in. The short-looking settlement is shown as 'reduced by refund #XXXX' - no ghost, no residual.
The whole lifecycle, visible
Every refund moves through a lifecycle you can see: issued, refunded by the rail, then netted against the batch that absorbs it. eSewa refunds, often done in the portal, are picked up by status polling and slotted into the same states automatically. At any point you know where a refund sits and which future payout will carry the deduction.
The AI drafts, a human executes
The AI can draft a refund - the amount, the reason, the original transaction - but drafting is the only thing it may do. Execution needs an authenticated human with the refund role to confirm, so there is no path from model output to money leaving your account. The draft removes the typing, never the judgment.
FAQ
Refunds & netting,
explained
Common questions about refunds & netting. Want it run on your own data first? The concierge reconciliation is free.
That's netting - the rail deducted the refund from a future payout instead of reversing it. RakamHQ tracks the refund to the exact batch it was netted from, so it's never a mystery.
Get your free reconciliation.
Send us last month's eSewa report, Khalti export, bank statement and orders sheet. Within 48 hours we send back a one-page close - every payment matched, every fee computed, every settlement decomposed.
Files only · private upload link · nothing to install