In Bangladesh, a courier company is not just a delivery business. It is a cash collection business that happens to move parcels. Most parcels are paid by cash on delivery, which means every rider on the road is carrying your merchants’ money. COD reconciliation is the process of proving that every taka collected at a doorstep is accounted for — matched to a parcel, deposited by the rider, and paid out to the right merchant.
When reconciliation is weak, money leaks. Not usually through dramatic theft, but through small daily gaps: a parcel marked delivered with no cash recorded, a partial payment nobody flagged, a rider deposit that is 500 taka short and gets “adjusted later.” Individually these look like rounding errors. Across hundreds of parcels a day, they quietly eat the margin of the entire operation.
This guide walks through how COD reconciliation should work in a Bangladeshi courier business, where the money actually goes missing, and a worked example you can adapt to your own operation.
What COD reconciliation actually means
Reconciliation is a three-way match. For every parcel, three numbers must agree:
- Expected amount — the COD value the merchant declared when booking the parcel.
- Collected amount — the cash the rider actually took from the customer.
- Deposited amount — the cash the rider handed over to the branch or hub at end of day.
If all three match for every parcel, your books are clean and you can pay merchants with confidence. If any pair disagrees, you have a discrepancy that needs a reason: a return, a discount given at the door, a partial delivery, a data entry error, or missing cash.
A fourth match happens later: the total you owe each merchant, minus your delivery charges and COD fees, must equal what you actually send through bKash, Nagad, or bank transfer. That side of the process is merchant settlement — this post focuses on getting the cash side right first, because you cannot settle correctly from numbers you have not verified.
Where the money leaks in a typical courier operation
Ask any operations manager who has run reconciliation on paper or Excel, and the same failure points come up:
1. Delivered-but-not-collected gaps
A rider marks a parcel delivered but the cash never appears in the deposit. Sometimes the customer genuinely paid and the rider is short. Sometimes the customer promised to pay “next time” and the rider marked it delivered anyway to keep his success rate up. Without a per-parcel cash match, both cases look identical — and both go unnoticed until a merchant complains.
2. Partial payments at the door
Customer ordered three items, kept two, paid for two. The parcel status says delivered, the expected COD says 3,000 taka, the rider collected 2,000. If your system only tracks delivered or not delivered, that 1,000 taka difference becomes a mystery at month end.
3. Returns recorded late
A failed delivery comes back to the hub two days later, but the merchant’s ledger still shows it as pending COD. When the merchant asks where the money is, your team spends an hour reconstructing what happened from call logs.
4. End-of-day deposit shortfalls
The rider’s deposit is short. Was it parcel 14 or parcel 27 that caused it? If the branch accepts a lump sum instead of a per-parcel breakdown, nobody knows — and shortfalls that cannot be traced can never be recovered. Tight rider cash handling rules prevent most of these, but only if reconciliation catches the exceptions the same day.
5. Spreadsheet drift
Excel reconciliation depends on someone copying rider sheets into a master file every night. One wrong cell, one missed row, one file emailed instead of updated, and the master no longer reflects reality. The scary part is that spreadsheet errors do not announce themselves — they surface weeks later as merchant disputes.
The daily reconciliation process, step by step
A clean process runs on a daily cycle. Weekly reconciliation is too late — by then riders have mixed several days of cash, memories have faded, and disputes are unwinnable.
Step 1: Assign with expected values
Every parcel handed to a rider in the morning carries its expected COD amount. The rider’s run sheet — paper or app — shows exactly how much cash he should be holding if every delivery succeeds. This number is the anchor for everything that follows.
Step 2: Record collection per parcel, in real time
At each doorstep, the rider records the outcome: delivered and collected in full, partial collection, or failed. Real-time recording through a rider app beats end-of-day recall every time. A rider who logs 4,500 taka collected at 2:15 pm cannot later claim it was 3,500.
Step 3: End-of-day deposit against the run sheet
Back at the branch, the rider deposits cash. The branch does not accept a lump sum — it checks the deposit against the sum of per-parcel collections. Deposit matches: rider is cleared for the day. Deposit is short: the specific parcels are identified on the spot, while the rider still remembers the doorstep conversation.
Step 4: Post exceptions with reasons
Every mismatch gets a reason code the same day: customer refused, partial acceptance, discount authorized by merchant, rider shortage. Uncoded exceptions are not allowed to age. An exception without a reason after 24 hours escalates to the branch manager.
Step 5: Roll up to merchant ledgers
Once cash is verified, each merchant’s ledger updates: COD collected, delivery charges deducted, net payable. Only verified cash flows into payables — a parcel marked delivered but not yet cash-matched stays out of the payout queue.
A worked reconciliation example
Here is a simplified end-of-day reconciliation for one rider. The numbers are illustrative, chosen to show each type of discrepancy.
Rider Karim took out 10 parcels with a total expected COD of 18,500 taka.
| Parcel | Merchant | Expected COD | Status | Collected | Discrepancy |
|---|---|---|---|---|---|
| P-101 | Mira Fashion | 1,500 | Delivered | 1,500 | — |
| P-102 | Mira Fashion | 2,200 | Delivered | 2,200 | — |
| P-103 | TechHut BD | 3,500 | Delivered | 3,500 | — |
| P-104 | Mira Fashion | 1,800 | Failed / return | 0 | Return, no cash due |
| P-105 | GreenLeaf Foods | 950 | Delivered | 950 | — |
| P-106 | TechHut BD | 4,000 | Partial | 2,500 | 1,500 short — customer kept 1 of 2 items |
| P-107 | GreenLeaf Foods | 1,200 | Delivered | 1,200 | — |
| P-108 | Mira Fashion | 1,100 | Delivered | 600 | 500 short — no reason coded |
| P-109 | TechHut BD | 1,450 | Failed / return | 0 | Return, no cash due |
| P-110 | GreenLeaf Foods | 800 | Delivered | 800 | — |
| Total | 18,500 | 13,250 |
Reading the table:
- Expected cash after removing the two returns (P-104, P-109) is 18,500 − 3,250 = 15,250 taka.
- P-106 is a documented partial: the merchant confirmed the customer could accept one item, so 2,500 is correct and TechHut’s ledger records a 1,500 return value.
- P-108 has an unexplained 500 taka gap. Collected shows 600 against an expected 1,100 with a full delivered status. This is the parcel that gets questioned tonight, not next week.
So Karim must deposit 13,250 taka, and the branch has exactly one open exception worth 500 taka with a name, a parcel ID, and a same-day timestamp attached. Compare that to a lump-sum world where the branch just knows “Karim brought 13,250 against 18,500 expected” and has to guess why.
Multiply this across 30 riders and three branches, and the difference between per-parcel matching and lump-sum matching is the difference between recovering shortfalls and writing them off.
Why software beats spreadsheets for reconciliation
Everything above can theoretically be done on paper. In practice, paper and Excel break down as volume grows, because reconciliation is a matching problem — and matching thousands of rows daily is exactly what software is for.
A purpose-built COD management system enforces the process instead of hoping people follow it: expected amounts attach to parcels automatically, riders record collections in an app, deposits are validated per parcel, and exceptions cannot be closed without a reason code. Merchant ledgers update from verified cash, so the payout queue is always defensible.
The reporting side matters just as much. When reports and analytics show shortage trends by rider, branch, and merchant, patterns emerge that no nightly spreadsheet ever reveals — the rider whose “customer refused” rate is triple the average, or the branch whose exceptions consistently age past 48 hours.
Drix was built around this exact workflow for Bangladeshi courier companies: parcel-level COD tracking from booking to doorstep to deposit to merchant payout, with bKash, Nagad, and bank settlement records tied back to individual parcels.
Signs your reconciliation is leaking money right now
Run a quick self-audit against these symptoms:
- Merchants regularly dispute payout amounts, and resolving a dispute takes more than a day.
- Rider shortfalls are “adjusted” against future collections instead of resolved.
- You reconcile weekly or monthly, not daily.
- Nobody can say, for a random parcel from last Tuesday, exactly who held its cash at each point.
- Your accounts team dreads month-end because the COD numbers never tie out the first time.
Two or more of these usually means the leak is already costing more per month than the software that would fix it. Reconciliation also directly shapes how much working capital you need — a topic we cover in depth in our guide to COD cash flow management.
Close the gap before it compounds
COD reconciliation is not glamorous, but it is the discipline that separates courier businesses that scale from those that stall. Every unexplained shortage erodes merchant trust, and merchant trust is the only real moat a courier company has.
Drix gives Bangladeshi courier businesses parcel-level COD reconciliation out of the box — rider collections, deposit matching, exception handling, and merchant ledgers in one system instead of a folder of spreadsheets. If you want to see what your daily close could look like, book a free demo and walk through the reconciliation flow with real parcel data, or review pricing to see how it fits your volume.
