POS Software with bKash & Nagad: How Integrated MFS Payments Change Day-End

Walk into almost any shop in Mirpur, Agrabad or Bogura at closing time and you will see the same scene. The cashier counts the drawer, then opens bKash on a phone, scrolls through the day's "You have received" messages, and adds them up on a calculator. Then the same again for Nagad. Then someone writes three totals in a khata, and if the numbers do not match the bill book, the argument starts. The till was closed in five minutes; the mobile money took forty-five, and nobody is certain the answer is right.

This post is about the difference between a POS that "accepts bKash" and a POS where bKash and Nagad are real tender types, recorded on the bill, reconciled at day-end and posted to the ledger. We cover merchant versus personal numbers, the common payment flows, split bills and refunds, a worked day-end example you can copy, settlement timing, cashback offers, fake-SMS fraud at the counter, and what multi-outlet reporting should look like. Every fee or timing we mention is a range to check with your MFS provider; we have tagged those lines.

Tender type vs side ledger: the only distinction that matters

Most POS software in Bangladesh can be made to "take bKash". The question is how. There are two patterns.

The side ledger. The cashier makes the bill as cash (or as "other") and the bKash payment lives only in the phone. The POS total for the day is one number; the real cash in the drawer is a smaller number; the difference is supposedly bKash. Reconciliation means comparing three unrelated sources by hand, and every mistake looks like cash theft or cashier error.

The tender type. bKash, Nagad, card and cash are each a payment method on the bill itself. The cashier picks the method, enters the transaction ID or confirms the QR, and the bill carries that payment line. The day-end report then shows sales by tender automatically, and accounting posts bKash receipts to a bKash clearing account rather than to cash.

Everything else in this article follows from that second pattern. If your POS cannot show you "Nagad sales today: ৳9,200 across 11 bills" without anyone opening a phone, it is using the side-ledger pattern, whatever the brochure says. The MondayPOS checkout treats cash, bKash, Nagad and cards as separate tender types for exactly this reason, and the day-end (Z-report) breaks sales down by each.

Merchant account or personal number

A surprising number of shops still take payments to the owner's personal bKash or Nagad number. It works, but it creates three problems the POS cannot fix for you.

For a POS, the merchant account matters because it gives you a statement you can reconcile against. The merchant portal lists every transaction with a time, amount and transaction ID. That is the list you compare with the POS tender report at day-end. A personal number gives you SMS messages and an app history that the cashier scrolls through, which is precisely the side ledger we are trying to remove.

If you are still on a personal number, opening a merchant account is usually the first step before integrating MFS with a POS. Requirements and fees vary by provider and by your monthly volume; ask bKash and Nagad directly and tag the numbers in your own notes, as we have here.

The three payment flows at the counter

Whatever the provider, the customer pays in one of three ways. Your POS should record all three the same way: as a tender line with a reference.

1. QR code (static or dynamic)

The customer scans a QR at the counter and enters the amount, or, with a dynamic QR generated by the POS for the exact bill, just confirms. Dynamic QR is better because the amount cannot be mistyped and the reference is already linked to the bill. Static QR is cheaper (a printed card) and works with any phone, but the cashier must type the amount to check and must confirm the transaction separately.

2. USSD or app "Payment" to the merchant number

The customer dials the provider's USSD code or uses the app, chooses Payment, enters the merchant number and amount, and gets an SMS. The cashier sees the confirmation on the merchant phone or portal and types the transaction ID into the POS bill. This is the most common flow in smaller shops and in areas with weak data coverage, since USSD works without internet.

3. Payment gateway or API integration

The POS sends the amount to the provider, the customer approves on their phone, and the POS receives an automatic confirmation with the transaction ID. There is no typing at all. Integration terms, onboarding and fees depend on the provider and on whether you go direct or through an aggregator.

For an offline-first POS, the first two flows keep working through load-shedding because the confirmation arrives by SMS on the merchant phone, and the cashier records the transaction ID on a bill that is saved locally and synced later. The gateway flow needs an internet connection at the moment of payment, so a practical setup is gateway-first with USSD/QR as the fallback. See offline POS and load-shedding for how bills sync.

Split payments and partial MFS

Real bills are rarely one tender. A ৳1,850 grocery bill is often ৳1,000 by bKash and ৳850 in cash because the customer's wallet is running low. A pharmacy customer pays ৳500 by Nagad and puts the rest on the family's credit account. A POS with MFS as a tender type should allow more than one payment line on a single bill, each with its own amount and reference, and the day-end must split them correctly.

Three things to check at a demo:

• Can a bill carry cash + bKash + Nagad at the same time, with the change calculated only on the cash portion?
• Does a partial payment (MFS now, balance due later) post the balance to the customer's receivable account rather than silently marking the bill paid?
• If the MFS payment comes in for ৳1,000 but the customer typed ৳100, can the cashier record the actual amount received and collect the rest in cash, leaving the audit trail intact?

Refunds and reversals

Refunds are where side ledgers break completely. A customer returns a ৳1,200 shirt bought with bKash. Options: refund in cash (drawer goes down, bKash does not), refund by sending money from the merchant wallet (fees may apply and the transaction looks like a send, not a reversal), or a formal reversal through the merchant portal where the provider supports it.

The POS needs to record which method was used, link the refund to the original bill, and post it to the matching account. A cash refund of a bKash sale is a legitimate decision, but it has to appear in the day-end as "bKash sales ৳X, cash refunds against bKash sales ৳1,200", otherwise tomorrow the cash drawer looks short and the bKash statement looks long. Refunds should also require a supervisor approval and leave an audit entry, the same as any other return. The access and audit controls that prevent unexplained voids should cover MFS refunds too.

Day-end reconciliation: a worked example

Here is a closing routine for a single grocery outlet in Mirpur on an ordinary Tuesday. The numbers are illustrative; the structure is what to copy.

Step 1. Print the POS day-end by tender. The Z-report shows each tender type, count of bills, and amount.

Step 2. Pull the external source for each tender. Drawer count for cash; merchant portal or app statement for bKash and Nagad; terminal batch report for cards.

Step 3. Compare, line by line, and explain every gap before anyone goes home.

Step 4. Post the day. In an integrated system, the accountant does nothing at this point: cash goes to Cash in Hand, bKash receipts to a bKash clearing account, Nagad to a Nagad clearing account, cards to a card clearing account. When settlement lands in the bank, the clearing account is cleared against the bank entry, net of fees. Fees post to an expense account. The accounting module does this from the same bill, so the ledger and the till cannot disagree.

Step 5. Handle open items. The ৳200 cash shortage follows your normal policy. The ৳400 bKash gap is escalated to the owner the same night, with the bill number, the transaction ID the customer showed, and the CCTV timestamp.

The whole routine takes ten to fifteen minutes once the tender report exists. Without it, the forty-five minutes of scrolling through SMS messages returns, and the ৳400 gap usually goes unnoticed until the monthly statement.

Settlement timing and fees

The day-end above says "matched", but matched is not the same as money in the bank. Merchant settlements follow the provider's schedule and your agreement; the cycle is written into your merchant agreement, it differs by provider and product, and weekends and public holidays push it out. Read your own agreement and build the day-end around that number rather than around an article's. Fees are a percentage per transaction, negotiated by volume, and may differ between QR, USSD and gateway payments.

What this means for your POS: the system should keep MFS receipts in a clearing account until the bank credit arrives, and the reports should show three numbers for each tender: collected today, awaiting settlement, and settled. If your accountant is booking bKash receipts straight to the bank on the day of sale, the bank reconciliation will never agree and fees will be scattered as "differences". Ask your vendor to show the clearing account and how the fee is posted when settlement arrives.

Cashback and provider offers

bKash and Nagad run periodic cashback and discount campaigns, sometimes funded by the provider, sometimes co-funded by the merchant. At the counter this creates a classic reconciliation trap: the bill is ৳1,000, the customer pays ৳1,000, the provider credits the customer ৳50 later. Your POS should record ৳1,000 received, full stop. The cashback is between the provider and the customer.

The exception is merchant-funded discounts, where you agree to give the customer 5 per cent off for paying by a particular wallet. That is a discount on the bill, recorded as a discount line with a reason code, so your margin reports and your Mushak 6.3 invoice reflect the actual sale value. Never handle an MFS discount by under-recording the payment; it corrupts the tender report and the VAT invoice in one move. The pricing and promotions module should let you define a "pay by Nagad, 5% off" rule with start and end dates so cashiers do not improvise.

Fake SMS and counter fraud

The ৳400 gap in the worked example is the most common MFS fraud in Bangladesh retail: the customer shows a screenshot or a forged SMS that looks like a payment confirmation, and a busy cashier hands over the goods. Variants include a genuine payment sent to the wrong (or the fraudster's own) number, a payment that was initiated but not confirmed, and a screenshot of an old transaction.

Counter rules that work, and that a POS can enforce:

1. 1Confirmation comes from the merchant side, never the customer's phone. The cashier checks the merchant app, portal or the merchant phone's SMS, or the POS receives the gateway callback. A customer's screen is not evidence.
2. 2The transaction ID is mandatory on the bill. The POS should refuse to close a bKash or Nagad tender line without a reference. Duplicated IDs on the same day should be blocked or flagged.
3. 3Amount check. The POS compares the bill amount to the confirmed amount and warns on mismatch.
4. 4Large-bill rule. Above a threshold you set, the cashier must wait for the merchant-side confirmation before releasing goods, no exceptions. Put the threshold in the POS settings, not in the cashier's memory.
5. 5Daily unmatched report. Any bill whose reference does not appear in the merchant statement is listed by cashier and by time. Patterns, such as the same cashier and the same "customer", show up within a week.

None of this needs special hardware. It needs the POS to treat the reference as data, not as a note field. Combined with the shrinkage controls in reducing inventory shrinkage, it closes one of the last easy doors.

Multi-outlet MFS reporting

With two or more branches the side-ledger problem multiplies: each outlet has its own phone, its own khata and its own idea of what was collected. Two setups are common.

One merchant account, many outlets. Simpler to open, harder to reconcile, because the statement is a single list and you must map each transaction back to an outlet. A POS can do this if every bill carries the transaction ID, so the statement can be matched to bills by reference, and each bill knows its outlet.

One merchant account (or sub-account) per outlet. Cleaner reconciliation, more paperwork, and a small chance that a cashier at Outlet A asks a customer to pay to Outlet B's QR by mistake. Provider support for sub-merchant or multi-outlet setups varies.

Either way, head office should see one screen: by outlet, by tender, by day, with matched, unmatched and awaiting-settlement amounts. The multi-branch module and reports in MondayPOS show tender-wise collections per outlet and roll them up, so the Dhanmondi branch's unmatched bKash bills are visible in Uttara the same evening rather than at month-end.

Questions to ask at a demo

Run these on any vendor, including us.

1. 1Ring up a ৳1,850 bill as ৳1,000 bKash plus ৳850 cash. Show me the receipt and the day-end.
2. 2Try to close a Nagad tender line without a transaction ID. Does the POS stop you?
3. 3Enter the same bKash transaction ID on two bills. What happens?
4. 4Refund a bKash sale in cash. Where does it show in the day-end and in the ledger?
5. 5Show me the bKash clearing account, and how settlement and fees post when the bank credit arrives.
6. 6Show me yesterday's unmatched MFS bills across all outlets, by cashier.
7. 7Unplug the router. Take a bKash payment by USSD and finish the bill. Where does it go when the router returns?
8. 8Apply a "5% off for Nagad" promotion. Does the Mushak 6.3 invoice show the discounted value correctly?

If the demo answers all eight on screen, the day-end scene we started with goes away. If any answer involves the phrase "you can note it in the remarks", you are looking at a side ledger.

Conclusion

bKash and Nagad are not an add-on to Bangladeshi retail; on many counters they are a third of the day's takings. A POS that records them as tender types, forces a reference on every bill, posts them to clearing accounts and reconciles them against the merchant statement turns a forty-five-minute evening argument into a ten-minute routine, and it catches the ৳400 fake-SMS the same night rather than next month.

To see the worked example above run on your own products and your own merchant statement, book a demo or start free. The point-of-sale overview covers the rest of the checkout.