How to reconcile bKash and Nagad collections with your books

If customers pay you through bKash or Nagad, your wallet balance and your sales ledger will almost never agree on their own. Customers pay with a reference you cannot always read, fees are taken before you see the money, settlements to your bank arrive in lumps, and some payments are refunded or reversed. At month end the accountant is left with a screenshot, a statement and a vague feeling that Tk 40,000 is missing.

This article sets out a method that works whether you have ten wallet payments a week or several hundred a day. The method is the same: treat each wallet as a bank account, bring the statement in, and match it.

Why wallets are harder than a bank account

• The statement shows a transaction ID and a sender number, not an invoice number, so matching needs a human or a rule
• Fees or charges may be deducted from the amount, so what you receive differs from what the customer paid
• Money may sit in the merchant wallet for a period and then be transferred to your bank as one settlement covering many sales
• Refunds, reversals and customer mistakes (wrong amount, wrong reference) appear as separate lines
• Several staff may share access, so the person who received the payment is not always the person who records it

Step 1: set up each wallet as its own account

Create a separate ledger account for each wallet you accept: one for bKash merchant, one for Nagad, and so on. Do not post wallet receipts straight to your main bank account. The wallet is where the money lands first. The bank is where it lands after settlement. Keeping them apart lets you reconcile each leg on its own and see at a glance how much is sitting in wallets.

Step 2: record customer payments against invoices as they arrive

When a customer pays, record the receipt against the invoice they are paying, using the wallet account as the receiving account, and put the wallet transaction ID in the reference field. That ID is the key you will match on later. If your staff record payments from a phone screenshot, make the transaction ID a required field, not optional.

Step 3: import the statement and match

At the end of each week, or daily if volume is high, download the merchant statement and import it. Each line becomes a statement entry that you match against a recorded receipt. In eSolverBooks, the banking section supports importing bKash, Nagad, Rocket and Upay merchant statements from Excel, with a preview before posting, and transaction IDs already imported are skipped so the same file cannot be posted twice.

1. 1Match by transaction ID first. These should agree exactly.
2. 2For unmatched statement lines, match by amount and date, then confirm with the customer or the staff member.
3. 3For recorded receipts with no statement line, check whether the payment was made to a personal number or an old wallet instead of the merchant account.
4. 4Leave anything unresolved on a short unreconciled list with an owner and a date, rather than forcing it.

Step 4: record fees and charges separately

If the provider deducts a fee, record the gross sale to the customer, the fee as an expense (for example payment processing charges), and the net movement in the wallet. This is better than recording only the net. Your revenue should show what customers paid, and your cost of collecting it should be visible, so you can see whether accepting wallets at a given volume is worth it.

Step 5: reconcile the settlement to the bank

When the wallet transfers a lump sum to your bank, the bank statement shows one deposit. In your books this is a transfer from the wallet account to the bank account, not a new sale. Match the bank deposit to the wallet transfer line. If the two sides differ, there is a fee, a timing difference, or an error. Because it is a transfer, there should be no revenue effect at all. Revenue was recognised when the customer paid.

Common problems and fixes

Customers paying to a personal number

In small businesses, money sometimes lands in an owner's or employee's personal wallet. That money is still the company's. Record it as a receipt, then record the transfer from the person to the company, or the owner's drawing if it stays with them. Do not leave it out of the books because it never touched the business account.

Wrong amount or duplicate payments

If a customer overpays or pays twice, record the extra as a customer credit or advance, not as additional sales. Either apply it to a later invoice or refund it, and record the refund against the wallet.

Refunds and reversals

A refund shows up on the statement as a debit. It needs a matching credit note or sales return in your books, not just a negative entry in the wallet account, otherwise your sales figure and your VAT will be overstated.

A weekly routine that keeps it small

• Monday: download last week's statements for each wallet
• Import, match by transaction ID, and clear the easy ones
• Chase the unmatched lines with the customer or the staff member who took the payment
• Post fees and settlements
• Check that the wallet ledger balance equals the statement closing balance

The last check is the one that matters. If the ledger balance of each wallet account equals the closing balance on the statement, any remaining error is in what you matched against, not in what you imported. Small weekly differences are cheap to fix. A year of differences is not.