If you sell through more than one channel in Nepal, you already know the feeling. Money comes in through eSewa and Khalti. Some customers pay by bank transfer or QR. A big chunk still pays cash on delivery (COD) through your courier. And every few days you're staring at three or four apps trying to answer one simple question: did I actually receive all the money I was supposed to?
This post lays out a simple, repeatable reconciliation system built for the way Nepali shops actually operate — eSewa/Khalti settlements, COD remittances from couriers, bank deposits, and VAT/PAN record-keeping — so you can close your books in minutes instead of guessing.
Why reconciling is harder in Nepal than the apps make it look
The core problem is timing and fees. Money rarely arrives the moment a sale happens.
- Wallet settlements lag. A customer pays Rs. 1,000 on eSewa today, but the amount lands in your linked bank account on a settlement cycle, often minus a transaction charge. The sale date and the deposit date don't match.
- COD is collected by someone else. Your courier collects cash from the customer, then remits it to you days later — usually after deducting delivery charges and sometimes a COD handling fee. Returns and undelivered parcels make the remittance smaller than your order total.
- Channels don't talk to each other. Your online store, your POS at the counter, your Khalti dashboard, and your bank statement are four separate truths. Nobody reconciles them automatically.
Multiply this across a busy week and small leaks become real money: a COD parcel that was returned but never credited back, a wallet charge you forgot to account for, a deposit that simply never showed up.
The one-table system: a single payment ledger
You do not need accounting software to fix this. You need one consistent record — a spreadsheet, a notebook, or a tool that does it for you — where every sale is logged once with its expected money, and then marked when the money is actually received.
Track these columns for each sale:
- Date & order ID — so it ties back to a specific transaction.
- Channel — Online, POS/counter, or marketplace.
- Payment method — eSewa, Khalti, bank/QR, or COD.
- Order amount (NPR) — what the customer owes, VAT included.
- Expected to receive — order amount minus known fees (wallet charge, courier delivery + COD fee).
- Status — Pending / Received / Returned / Short.
- Date received & reference — the settlement date and the transaction or remittance reference number.
The discipline is simple: a sale is not "done" until the Status says Received and the amount matches what you expected. Anything stuck on Pending for too long is your to-do list.
Reconciling each channel
eSewa and Khalti
Once or twice a week, open your wallet/merchant dashboard and export the settlement report. Match each settled transaction to an order in your ledger by amount and reference. Note the transaction charge as an expense — don't pretend the gross amount is what you earned. If a payment shows in your dashboard but you can't find the matching order, flag it; if an order shows Received in your store but never settled, chase it before the trail goes cold.
Bank transfers and QR
Bank and QR payments are the easiest to trust because the money is already in your account, but they're also the easiest to mis-assign. Always ask customers to send the order ID with the transfer, and record the bank reference number against the order. At month-end, your bank statement total for sales should equal the sum of your "bank" rows.
COD through couriers
This is where most money goes missing. When your courier sends a remittance, reconcile it parcel by parcel, not as a lump sum:
- Tick off each delivered parcel against your dispatched orders.
- Confirm returned/undelivered parcels are removed — you should owe delivery charge but not be credited the order value.
- Verify the deductions (delivery fee, COD fee) match the rate you agreed.
The remittance total should equal: collected orders − courier charges. If it's short, the per-parcel list tells you exactly which order to question.
Don't forget VAT and PAN
Your reconciliation isn't just for cash flow — it's the backbone of clean tax records. If you're PAN/VAT-registered, the order amounts you reconcile feed your sales records and VAT returns. Keep these straight as you go:
- Record sales VAT-inclusive and know your VAT portion, so the 13% you collected isn't mistaken for profit.
- Keep wallet and courier fee receipts — they're legitimate business expenses.
- Reconcile before you file, not the night your return is due. A ledger that's already matched makes monthly filing routine instead of stressful.
Surviving the Dashain–Tihar rush
During the festival season, order volume can spike for weeks, and that's exactly when reconciliation falls apart. A few defenses:
- Reconcile more often, not less — daily during peak, even if it's just 15 minutes. Backlogs from October are miserable to untangle in November.
- Watch COD closely — festival COD volume is high and return rates climb with rushed buying. Don't let unremitted cash pile up at the courier.
- Set a wallet payout cadence so settlements don't bunch up unnoticed while you're busy shipping.
Where a connected platform helps
The reason this gets painful is fragmentation — four dashboards, no single source of truth. This is exactly the gap a platform like Saauzi closes: because your online store, POS, and eSewa/Khalti/bank payments live in one system, each order already carries its payment method and status, so your reconciliation "ledger" is largely filled in for you. You're left verifying COD remittances and settlement dates rather than rebuilding the whole picture by hand.
Your takeaway
Pick one habit and start this week: log every sale once, mark it Received only when the money truly lands, and reconcile each channel on a fixed day. Start with COD — it's where the leaks are biggest — then add your wallet and bank checks. Within a month you'll know, to the rupee, what you earned, what you're owed, and who to chase. That's the whole game.



Comments
Be the first to comment.