Bank Statement Reconciliation in Nepal

Every Nepali business that takes digital payments ends up staring at the same document: the bank statement. It is the final word on where your money actually is. Your eSewa dashboard, your Khalti report, your order system - all of these are claims. The bank statement is the truth. Reconciliation is the work of making those two agree, line by line, until nothing is left unexplained.

The trouble is that a Nepali bank statement rarely arrives in a form you can just read. It comes as a CSV with inconsistent columns, or a PDF that looks tidy but fights every attempt to extract a table. And even once you have the rows, the narrations are cryptic. This article is about turning that raw statement into something you can match against your sales.

Getting the statement into a usable shape

Banks in Nepal export statements in two formats, and neither is friendly.

• CSV or Excel. The better case. You get columns, but the headers vary by bank - Txn Date, Value Date, Description, Debit, Credit, Balance. Some banks split debit and credit into two columns; others use one signed amount. Date formats wander between YYYY-MM-DD, DD/MM/YYYY, and occasionally a Bikram Sambat date, which is a trap all its own.
• PDF. The harder case. The table looks clean on screen but is often a set of positioned text runs with no real grid. Copy-pasting scrambles the columns. A multi-line narration wraps and breaks your row alignment. You need a parser that reads by column position, not by line.

The goal at this stage is boring and essential: one clean table with a date, a signed amount, a running balance, and the full narration text preserved. Everything downstream depends on getting this right.

Classifying credits: settlement vs transfer vs everything else

Once you have clean rows, the real work begins. Not every credit on your statement is a sale. Mixing these up is the single most common reconciliation error we see.

A typical merchant statement contains at least four kinds of credit:

• Settlement credits. Money swept from a payment provider - eSewa, Khalti, Fonepay, connectIPS. These are net of fees and usually arrive as a lump. Narrations look like ESEWA STL, FONEPAY SETTLEMENT, or a Khalti reference code. These are the credits that must reconcile against your sales.
• Direct transfers. A customer or another party sending money straight to your account. Real revenue sometimes, but not a provider settlement, so it never matches a settlement batch.
• Internal movements. Sweeps between your own accounts, loan disbursements, fixed-deposit maturities. Not revenue at all. If you count these as sales, your numbers inflate quietly. Banking-sector reporting norms are set by Nepal Rastra Bank, and statement formats broadly follow them.
• Reversals and charges. Bank fees, cheque returns, tax deductions at source. Debits mostly, but they belong in the reconciliation too.

The discipline is to tag every credit before you match anything. A settlement credit gets sent to the settlement-matching process. A direct transfer gets checked against your invoices or ignored as non-sales. An internal movement is excluded from revenue entirely. Do this classification first, and matching becomes tractable.

Matching lumps to orders

Here is the heart of the problem. Your order system says you made 47 sales through eSewa today. Your bank statement shows a single credit of Rs 41,180.50 with the narration ESEWA STL. How do you prove those 47 orders are inside that one number?

You reverse the batching:

• Establish the window. A settlement covers a period of verified payments, not a calendar day. Work out which payments the batch could contain - usually everything since the last settlement of that provider.
• Sum the gross. Add up the provider's own report for that window. This is your expected gross.
• Apply the fee model. Subtract the provider's service fee. Now you have an expected net.
• Compare to the credit. Expected net should equal the bank credit. If it does, the lump is decomposed - those orders are provably inside it.

When it does not match, the gap is a residual, and a residual is a question you answer rather than a number you round away. The usual culprits are a payment that straddled two batches, a refund netted out of the settlement, a fee rate that drifted, or a duplicate you double-counted. Each has a signature once you know to look. We cover the mechanics of decomposing a single provider batch in reading your eSewa settlement report, and the broader discipline in what payment reconciliation actually is.

The narration problem

Nepali bank narrations are terse and non-standard. ESEWA STL, FONEPAY, NPI/..., a bare reference number - the same provider can appear under three different narration styles depending on the settlement rail. connectIPS credits look different again. You cannot rely on an exact string; you build a set of patterns per provider and match on the recognisable fragment.

This is also where dates matter more than they look. If your statement carries a Bikram Sambat value date and your provider report carries an AD date, a naive match fails even when the money is correct. Reconciliation in Nepal has to be calendar-aware, which is why we treat the Bikram Sambat financial year as a first-class concern rather than a formatting detail.

From matched rows to a proven close

Once every credit is classified and every settlement lump is decomposed, you have something valuable: a statement where each line traces to a source. Settlement credits map to provider batches, which map to orders. Transfers map to invoices. Internal movements are excluded and labelled. Nothing is unexplained.

That is the raw material for a daily close - the point where you can say, with evidence, exactly what came in and where it sits. If the phrase is new to you, what a daily close is and why a proven one matters is the natural next read.

Doing all of this by hand in a spreadsheet is possible, and plenty of Nepali accountants do it every evening. It works until a PDF parses badly, a narration changes, or a residual appears with no obvious source. RakamHQ does this parsing, classification, and lump-to-order matching automatically, from the bank statement and provider reports you already have, so every rupee on the statement traces back to a row you can point at.

Frequently asked

Why is a bank credit smaller than my sales total?

A settlement credit arrives net of the provider's service fee and often bundles many orders into one lump. The gap between your sales and the credit is usually fees plus timing, not missing revenue.

How do I tell a settlement credit from a normal transfer?

Classify every credit before matching. Settlement credits come from providers like eSewa or Fonepay with narrations such as ESEWA STL and arrive net of fees, while direct transfers, internal sweeps, and charges are separate categories that never match a settlement batch.

What is a residual in reconciliation?

A residual is the unexplained gap left after you decompose a settlement into its orders and fees. It is a question to answer - a straddled payment, a netted refund, a drifted fee rate, or a duplicate - not a number to round away.

Can I reconcile a PDF bank statement?

Yes, but PDFs need a parser that reads by column position rather than by line, because narrations wrap and break row alignment. Use the running balance column as a checksum to confirm no rows were dropped or duplicated.

Keep reading

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

Read

What Is a Daily Close, and Why Prove It?

Read

Reconciling Cash on Delivery Orders

Read