How to Read Your eSewa Settlement Report (Without the Headache)

Every eSewa merchant has had this moment. Your dashboard says you collected a good day of sales. Then the bank credit lands and it is a single lump - smaller than you expected, with a cryptic narration like ESEWA STL. Which orders are inside it? What did the fee come to? And why does it not match the number in your head?

This is not a mistake. It is just how settlement works. Once you understand the three moving parts, an eSewa settlement stops being a mystery and becomes something you can prove to the rupee.

The two places your money lives

The first thing to internalise: a successful eSewa payment is wallet balance, not bank balance.

When a customer pays, the money lands in your eSewa merchant wallet. It reaches your bank only when a settlement moves it - net of fees. So at any moment your money is split across two places: what has settled to the bank, and what is still pooled in the wallet waiting to be swept.

What a settlement actually contains

A single bank credit is a batch. Inside it are many individual payments, collapsed into one number. To read it, you reverse the collapse:

• The period. A settlement covers a window of verified payments - often a day, sometimes several bundled together. The batch does not always tell you the exact window, so you infer it from the last settlement date to this credit's date.
• The gross. The sum of the payments inside the batch, before fees.
• The fee. eSewa's service fee, deducted from the gross.
• The net. What actually hit your bank. net = gross - fee.

If you can list the payments in the period, add the fee model, and watch them sum to the net credit, you have decomposed the settlement. Anything left over is a residual - and a residual is a question, not something to round away.

Why the number in your head is wrong

Three things routinely make a settlement smaller than expected:

• Fees. The most common. A 2-3% service fee on a busy day is real money, and it is easy to forget when you glance at gross sales.
• Timing. A payment made late in the day may settle in the next batch, not this one. The batch looks short until you realise the missing payment simply moved to tomorrow.
• Refunds. A refund can be deducted from a settlement rather than reversed on its own. (On Khalti this is called netting - it deserves its own article.)

Doing it by hand vs. proving it automatically

You can do this in a spreadsheet: export the wallet report, export the bank statement, and VLOOKUP your way to a match. Thousands of Nepali businesses do exactly this, every evening. It works, until a fee rate drifts, a payment straddles two batches, or a refund quietly nets out - and then you are staring at a residual with no idea where it came from.

This is exactly what RakamHQ automates. It ingests your eSewa report and your bank statement, decomposes every settlement into the payments and fee inside it, and if there is a residual it names the amount and shows you the best fit - instead of silently absorbing it. Every rupee traces back to a source row.

That is the whole idea: prove where every rupee went, every morning, without opening Excel.