Reconciling Fonepay, eSewa and Khalti payments without a spreadsheet

You can reconcile Fonepay, eSewa and Khalti payments without a spreadsheet by letting software pull each provider's transactions, normalise them into one format, and match them to your orders on amount, time and reference. People then handle only the payments that don't match. The hard part isn't the matching logic. It's getting clean data out of each channel.

If you run a shop, a clinic, a school or an online store in Nepal, you probably know the evening routine. Log in to the Fonepay dashboard, download the day's list. Do the same in eSewa and Khalti. Open the bank statement. Paste everything into one sheet and start ticking rows against the order book. On a quiet day it takes half an hour. On a busy one it eats the evening, and the mismatches roll into tomorrow.

How fast are QR and wallet payments growing in Nepal?

Fast enough that the spreadsheet stops working for a lot of businesses at once. Nepal Rastra Bank's Financial Stability Report for FY 2024/25 puts QR-based payments at about Rs 958 billion for the year, up roughly 92% on the Rs 500 billion of the year before, a figure The Kathmandu Post also reported in April 2025. Five years earlier, in FY 2020/21, the figure was around Rs 20 billion. By transaction count, QR payments went from about 169 million to about 326 million in a single year.

The user base behind that is large. The same report counts 26.77 million wallet users and 27.74 million mobile banking customers by mid-July 2025. B360 reported that in March 2025 one payment provider processed more than a million merchant QR payments in a single day. For a merchant, all of this means one thing: more small payments, from more apps, landing in more places.

Why don't wallet payments match invoices on their own?

Because the payment and the order live in two different systems, and nothing forces them to share an ID. A customer scans a static QR, types an amount, maybe adds a remark, maybe not. Your order book knows the customer and the invoice. The provider's report knows a phone number or a masked name, an amount and a timestamp. Somebody has to connect the two. The usual troublemakers are familiar:

• Several reports in several formats. Fonepay, eSewa, Khalti and each bank export different columns, date formats and reference fields.
• Settlement timing. The money a customer paid today may reach your bank the same day or later, depending on the provider, your agreement and cut-off times, so the bank line and the sale sit on different dates.
• Fees netted off. NRB's NepalQR guidelines let acquirers charge merchants a merchant discount rate (MDR) and bar charging customers, so what settles can be less than what the customer paid.
• Wrong or partial amounts. A customer pays Rs 2,450 for a Rs 2,540 bill, or pays half now and half next week.
• Missing references. No invoice number in the remark, or a parent paying school fees from their own phone for a child with a different name.
• Refunds and reversals that show up days after the original sale.

None of these is rare. Each one is a row that won't tick off, and each one needs a person to phone someone or dig through a chat to resolve it.

What data can you actually get from Fonepay, eSewa and Khalti?

This is where most plans go wrong, so it is worth being precise. We checked each provider's public documentation. Khalti publishes the most: a payment lookup API and a merchant transaction list that returns amount, fee, state and refund status. eSewa's public ePay docs cover taking a payment and a status-check API that can report states such as COMPLETE, PENDING, PARTIAL_REFUND and AMBIGUOUS, but we found no public transaction-list or settlement endpoint. Fonepay offers dynamic QR codes that carry the amount and a reference per transaction, plus a merchant dashboard, but we could not find open public developer docs; integration details come through onboarding.

The single most useful change is on the collection side, not the matching side. When you generate a per-order reference, through a dynamic QR, a checkout integration or a payment link, the payment arrives carrying your invoice number. Matching then becomes a lookup rather than a guess.

How does automated reconciliation work, step by step?

It's a pipeline, and each stage is ordinary software. First, collectors pull data from every channel: APIs where they exist, scheduled portal exports where they don't, and the bank statement. Second, a normaliser turns every row into the same shape: amount, fee, net, time, channel, payer and reference. Third, the matcher runs rules in order of confidence. Exact reference match first. Then amount plus a time window. Then fuzzy rules, such as a near-miss amount from a known payer. Fourth, whatever doesn't match lands in an exception queue for a person. Finally, confirmed matches post to your accounting software as receipts.

Two design choices matter more than the rest. Keep the raw data, so you can always rerun a day after fixing a rule. And never auto-confirm a fuzzy match. Propose it, let a person accept it, and log who did.

How much staff time does manual reconciliation really cost?

Less than it feels like per payment, and more than it looks like per month. A minute and a half per match sounds trivial. At 120 payments a day over 26 trading days, it's around 78 hours a month before anyone has chased a single mismatch. Add the daily downloads from each channel and you're close to a part-time job. The calculator below uses stated assumptions, not benchmarks. Change them to fit your business.

The number that moves the result most is the exception rate. If most of your customers pay with a reference you generated, exceptions stay low and automation pays quickly. If most pay to a static counter QR with no remark, even good software will send a lot to the queue. For how we think about payback on work like this, see how automation ROI actually works.

Should you fix collection or matching first?

Usually collection. A few changes cost little and cut exceptions before any software exists:

• Use dynamic QR or payment links that carry the invoice number, at least for larger bills and online orders.
• Print the order number on the bill and ask customers to put it in the remark when they use a static QR.
• Consolidate channels where you can. Every extra wallet or bank is another report to collect.
• Book provider fees as their own expense line instead of netting them silently.
• Agree a daily cut-off time, so today's sales and today's settlements are compared on the same basis.

Then automate the matching. Start with one channel and the bank statement, prove the match rate for a month, and add channels one at a time. This is the same pattern our fintech reconciliation automation blueprint follows for invoices and ledgers.

What's the bigger picture for Nepali merchants?

QR payments went from a novelty to the default in about five years, and the rails behind them, which we covered in Nepal's fintech at scale, now work well for customers. The merchant back office hasn't caught up. Taking payments is easy. Proving every payment belongs to a sale, net of fees, is still a spreadsheet job in most businesses we talk to. That gap will only widen as volumes keep rising.

Where does NeuralYug fit in?

We build this kind of pipeline: connectors for Nepali payment channels, matching rules tuned to your real exceptions, a simple review screen, and posting into the accounting tool you already use. We'd rather start with one channel and a month of your real data than promise a match rate up front. If your evenings go to ticking off wallet payments, talk to us or see what our Flow Automation service covers.