A Bangladeshi buyer pays through bKash, Nagad, a bank transfer, a cheque, or cash at the site office — often several of these across the life of one flat. Each channel arrives with different information, and the collection ledger has to end up with one clean answer per buyer. Reconciliation breaks because the ledger is built for bank deposits and everything else is handled by memory.
What each channel gives you
| Channel | Identifier | Timing | Common problem |
|---|---|---|---|
| bKash / Nagad | TrxID and sender number | Immediate | Sent from a relative's number, no reference |
| Bank transfer | Reference and remitter name | Same or next day | Reference field left blank |
| Cheque | Cheque number | On clearing | Receipted on handover date, cleared later or bounced |
| Cash at site | Receipt book number | Immediate | Deposit lag between site and bank |
| Card or gateway | Gateway reference | Immediate, net of charges | Gateway fee not accounted for, so amounts never match exactly |
Two rules fix most of it. Every receipt records the channel and its identifier. And the date of receipt and the date of credit are separate fields, because a cheque received on the 28th and cleared on the 3rd belongs in two different months for two different purposes.
The matching sequence
- Reference match. If the buyer used the reference you gave them, the payment attaches automatically.
- Sender number match. Match the MFS sender number against the buyer's registered numbers, including alternate numbers recorded at booking.
- Amount and expectation match. An unmatched payment equal to an outstanding instalment for a buyer who was due that day is a strong candidate for review.
- Suspense. Anything unmatched goes to a suspense account and appears on a daily list. It does not get "adjusted".
Suspense is the discipline that makes the rest work. An unmatched payment left inside the collection numbers means both the buyer's ledger and the project's collection figure are wrong, and neither will be discovered until someone complains.
Partial and excess payments
Both are routine and both need a rule rather than a decision:
- Partial: apply to the oldest outstanding instalment first, leaving the remainder outstanding. Do not silently move the due date.
- Excess: post as a credit on the buyer ledger and apply automatically to the next instalment.
- Advance: a buyer paying six months ahead should see six instalments settled, not one instalment and a large credit balance, because that is how they think about it.
Whatever rules you choose, write them into the agreement and apply them uniformly. Building a schedule that does not live in Excel covers where these rules belong.
Charges, and why the numbers never match exactly
MFS and gateway transactions carry charges, and depending on who bears them the amount credited differs from the amount the buyer sent. Decide the position once — usually the buyer bears the charge and the ledger records the gross — and configure it. Left undecided, every reconciliation produces small differences that accumulate into a number nobody can explain.
The daily habit that removes month-end pain
Fifteen minutes a day: open yesterday's MFS and bank credits, match, receipt, and leave the rest in suspense with a note. Done daily, the suspense list stays short and the questions are fresh enough to answer. Done monthly, it becomes an investigation into transactions from five weeks ago, involving people who no longer remember.
What to do next
Take last month's bank and MFS statements and mark every credit that is not attached to a specific buyer and instalment in your system. That total is the size of your reconciliation gap — see receipts, channels and the buyer ledger in one flow.