Payment Reconciliation for Bangladeshi Retailers: bKash, Nagad & Cash
How Bangladeshi retailers can reconcile daily takings across bKash, Nagad, card and cash: typical settlement timelines, a step-by-step daily close process, the mismatch patterns to recognize and a fully worked numeric example.
What payment reconciliation means
Payment reconciliation is the process of matching what customers paid you - across cash, bKash, Nagad, card and cash-on-delivery - against what actually arrived in your accounts. Done daily, it guarantees every taka of the day's takings is explained: either sitting in your drawer, settled into your bank or mobile-wallet merchant account, or written off with a recorded reason. Shops that skip it rarely notice money leaking; they just feel vaguely poorer every month.
Where unreconciled shops lose money
The leaks are small and constant: mobile-wallet fees nobody records, so profit looks fatter than reality; a customer whose payment showed failed but was actually charged, never refunded; late-night sales that settle the next morning and get counted twice; and cash that quietly walks away because nobody compares the drawer to the day's bills. Each leak is trivial alone. Together they eat a noticeable slice of already-thin retail margins.
Know when each method's money actually lands
Before reconciling, understand settlement timing per method, because a mismatch today may simply be money arriving tomorrow. The cycles below reflect what merchants commonly report in Bangladesh - always confirm your own merchant agreement, since rates, cutoffs and schedules differ by provider and plan.
Typical Settlement Timelines by Payment Method
| Payment Method | Typical Settlement Cycle | Practical Note |
|---|---|---|
| bKash merchant payments | Usually next business day (T+1) | Transactions after the evening cutoff settle the following working day |
| Nagad merchant payments | Usually next business day (T+1) | Similar cutoff behavior; Fridays and holidays push settlement forward |
| Card POS (acquiring bank) | Commonly T+1 to T+2 | Depends on your acquiring bank's batch schedule |
| Cash on delivery (courier) | Weekly to twice monthly, after delivery confirmation | Courier fees are deducted before payout reaches you |
The daily close process, step by step
Step 1: Fix a cutoff time - say 10 PM - and mark any sale after it as belonging to the next day's books. Step 2: Close the register and generate the end-of-day summary showing totals per payment method. Step 3: Count the cash drawer and compare it to the cash total; investigate immediately if they differ. Step 4: Open your bKash and Nagad merchant statements and list the day's transactions and amounts. Step 5: Match each method's POS total against its statement total, recording provider fees as expenses rather than missing money. Step 6: Log every difference with a reference number - transaction ID, amount, suspected cause - in one place. Step 7: Sign off, then the next morning confirm yesterday's expected settlements actually landed. Fifteen focused minutes at closing time prevents most month-end mysteries.
Common causes of mismatches
Provider fees: bKash and card processors deduct charges before settlement, so statements show slightly less than your sales total - record the fee as an expense. Failed-then-charged: a customer retries after a timeout screen and both attempts succeed, leaving an extra credit to refund. Timing cutoffs: a sale at 11:58 PM settles tomorrow, so tonight's statement looks short and tomorrow's looks long by the same amount. Duplicate taps, same-day refunds and cashier keying errors fill out the list. Every cause leaves a recognizable signature; once your team knows the patterns, triage takes minutes instead of arguments.
Offline sales and the sync queue
Power cuts and dead zones are normal, so a capable offline-first POS queues sales locally and pushes them upstream when connectivity returns. Reconciliation follows the sync, not the wall clock: yesterday evening's offline batch may reach both the system and the provider statement only this morning. The discipline that matters is comparing like with like - once the offline queue has drained, the POS total for a period should equal statement totals minus recorded fees. Choose a till that survives outages and queues cleanly, and reconciliation stays a five-minute habit instead of a forensic project.
A Worked Example: One Day at the Counter
The day's takings and expected settlements
Suppose the till shows 58,900 BDT taken on Tuesday: 18,500 in cash, 24,800 across forty bKash transactions, and 15,600 across twelve card transactions. Using illustrative fee rates, the reconciliation looks like this - note the fee arithmetic: 24,800 x 1.5% = 372, and 15,600 x 2.0% = 312.
| Method | Taken (BDT) | Fee Rate | Fee (BDT) | Expected Settlement (BDT) |
|---|---|---|---|---|
| Cash | 18,500 | - | - | Stays in drawer |
| bKash | 24,800 | 1.5% | 372 | 24,428 |
| Card | 15,600 | 2.0% | 312 | 15,288 |
| Total | 58,900 | - | 684 | 39,716 deposited |
Chasing the one-transaction difference
True revenue is 58,900 BDT, recorded fees total 684 BDT, and the merchant accounts should show 24,428 BDT from bKash on Wednesday plus 15,288 BDT from cards within two days. Now suppose Wednesday's bKash statement lists forty-one transactions totaling 25,420 BDT - one more than the till. Matching by reference reveals transaction #4071: the customer saw a failure screen and retried, so both attempts succeeded and 620 BDT arrived twice (24,800 + 620 = 25,420). Refund the duplicate through the provider's portal, log it against the day, and the books balance again: 24,800 BDT gross from the till, one 620 BDT duplicate refunded, zero unexplained taka.
Frequently asked questions
Q: The wallet statement shows money my POS does not. What now? A: Check offline-batch sync delays first, then failed-then-charged duplicates. Match by transaction reference, refund duplicates, and record genuine extras as corrections - never spend unmatched money until it is explained. Q: How long should a mismatch stay open? A: Aim for same-day resolution with a hard limit of seven days. Items older than a week are rarely recovered and teach staff that loose endings are acceptable. Q: Can a notebook replace software for this? A: Below roughly twenty transactions a day, a disciplined notebook works. Beyond that, manually matching four payment methods consumes hours and breeds the very errors reconciliation exists to catch. Q: Who should do the reconciling? A: Not the cashier who handled the money. Separation of duties - even between two family members - turns reconciliation into a real check instead of self-graded homework.
Make reconciliation automatic, not heroic
Reconciliation is a habit before it is a feature: fixed cutoff, daily comparison, logged differences. Software makes the habit cheap by recording every payment method at the counter and producing per-method totals automatically. Explore our [fintech development services](/solutions/fintech-development) for payment integrations built for Bangladesh, or see our [POS software](/solutions/pos-software) if you want billing, inventory and daily closes in one system.
Related Articles
Ready to Transform Your Business?
Book a free consultation and let's discuss how the right technology can help your business grow.
Book Free Consultation