How Khalti Settlement and Payouts Work
A Khalti payment feels instant. The customer taps, the screen turns green, your dashboard ticks up. But the money is not in your bank yet - it is sitting in a merchant balance, waiting for a payout. Understanding the gap between "paid" and "in the bank" is the difference between a business that can prove its cash position and one that only guesses at it.
This article walks through how Khalti settles to your bank: the timing, the fees, how refunds get carried into the next payout, and how to actually read the report you download.
Paid, settled, and the space in between
A Khalti transaction moves through two distinct events, and they are almost never the same moment.
- Capture. The customer pays. The money lands in your Khalti merchant wallet. This is what your dashboard "success" count reflects.
- Payout. Khalti sweeps your accumulated wallet balance to your linked bank account, minus fees. This is what your bank statement reflects.
Between capture and payout, the money is real but immobile - it belongs to you, it just is not spendable. Every reconciliation problem in the wallet world starts here, because merchants treat the capture number as their bank number and the two drift apart daily.
Track two separate figures every day: your captured total (from Khalti) and your settled total (from the bank). The difference is your in-transit balance - money you have earned but not yet received. It should shrink to near zero over a normal payout cycle.
How the T+? timing actually works
Merchants always ask the same question: when does the money arrive? The honest answer is that it depends on your agreement with Khalti, your bank, and the calendar.
- The payout schedule is set on your merchant account - often daily or on a fixed cycle. Payments captured before a cutoff go into the next payout batch; payments after the cutoff roll to the batch after.
- Bank posting adds its own lag. Even once Khalti releases a payout, inter-bank transfers clear on banking days. A Friday-evening capture can realistically land in your bank the following week.
- Public holidays matter more in Nepal than most gateways admit. A cluster of Dashain or Tihar holidays can stack several days of captures into one large payout once banks reopen.
So "T+?" is not a fixed number. It is a cutoff plus a banking-day count plus whatever holidays fall in between. What you can rely on is the ordering: captures accumulate, a cutoff closes the batch, and the batch settles net of fees. If you know your cutoff, you can predict which day's sales land in which payout - and that is enough to reconcile.
Fees, and why Khalti is easier to audit
Khalti deducts a service fee before it pays you. The rate depends on your merchant category and negotiated terms, so do not assume a single number - confirm yours in your merchant dashboard or agreement.
The useful part: Khalti's developer documentation exposes per-transaction data, including fee information on lookup. That means you are not left guessing at an effective rate. You can compute the fee you expected on each transaction and compare it to the fee Khalti charged, transaction by transaction. When those two disagree, you have found either a rate change or an error - and either way it is worth knowing. We go deeper on this in payment gateway fees in Nepal compared.
Effective fee rates drift. A category reclassification, a promotional rate that expires, or a rounding rule can move your real cost by a fraction of a percent - invisible on any single transaction, but real money across a month of volume. Audit computed-versus-charged fees, do not just trust the headline rate.
Refunds and netting: why a payout comes up short
Here is the scenario that confuses every new Khalti merchant. You refund a customer on Tuesday. The customer is made whole immediately. Then the next payout lands and it is short by roughly that refund amount, with no obvious debit line explaining the gap.
This is netting. Rather than reverse the original payment as a standalone visible debit, Khalti carries the refund forward and subtracts it from a later payout batch. The money leaves your books as a quiet reduction inside a settlement, not as a clean refund line. If your bookkeeping expects every refund to appear as its own reversal, a netted payout looks mysteriously short.
The fix is not to hunt for a missing debit. It is to model the netting: when you issue a refund, open an expectation for that amount, then watch which payout batch absorbs it and close the two against each other. We cover the full mechanics in Khalti refunds and netting.
Reading a Khalti report line by line
When you export your Khalti transactions, work through it in this order:
- Status. Filter to completed and refunded. Pending and initiated rows are not money - they are intentions that may or may not have captured. Treat them as noise until they resolve.
- Amount and fee. For each completed transaction, note the gross amount and the fee. The net (gross minus fee) is what contributes to a payout.
- Timestamp against your cutoff. Sort by capture time and mark where your payout cutoff falls. Transactions above the line belong to this payout; below the line, the next one.
- Refunds. Flag every refund. Each one is a future deduction you will need to match against an upcoming payout, not a same-day event.
- The payout total. Sum the net of the transactions in the batch, subtract any netted refunds, and that number should equal the credit on your bank statement. If it does not, the leftover is a residual - a question to answer, not a rounding error to bury.
That last step is the whole game. A settlement you can decompose into its transactions plus fees minus refunds is a settlement you can prove. One you cannot is a liability hiding in plain sight.
Why this is worth automating
Doing the above by hand once is educational. Doing it every morning, across hundreds of transactions, with fee rates that drift and refunds that net days later, is where spreadsheets quietly fail. A missed cutoff or an unmatched refund does not announce itself - it just leaves a payout that "looks about right."
RakamHQ ingests your Khalti report and your bank statement, decomposes each payout into the transactions, fees, and netted refunds inside it, and names any residual instead of absorbing it. The point is simple: prove where every rupee went, before you start your day rather than after month-end.
Frequently asked
How long does a Khalti payout take to reach my bank?
There is no fixed number. It is your payout cutoff plus banking-day clearing plus any public holidays. Captures before the cutoff go in the next batch; the batch then settles net of fees, and inter-bank posting adds its own lag - so a Friday-evening sale can land the following week.
Why is my Khalti payout smaller than my captured sales?
Three reasons usually stack: service fees deducted before payout, timing where late captures roll to the next batch, and netting where a refund is subtracted from the payout rather than shown as a separate debit.
What is netting on Khalti?
Netting means a refund is carried forward and deducted from a future payout instead of appearing as its own reversal. The customer is refunded immediately, but on your side the money leaves as a quiet reduction inside a later settlement.
Can I audit the fee Khalti charges me?
Yes. Khalti's developer documentation exposes per-transaction fee data on lookup, so you can compare the fee you expected against the fee charged, transaction by transaction, and catch any drift.
Keep reading
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