Courier Dispatch with Cash on Delivery Reconciliation and Merchant Payouts

The problem small couriers have with cash on delivery

Cash on delivery is still how a large share of online orders are paid for in Pakistan and across South Asia, the Middle East and Africa. For a small courier company, every COD parcel starts a chain: the rider collects cash, hands it to a branch at night, the branch deposits it in a bank, and weeks later the company pays the online seller minus fees and returns. Each step leaks. Riders are short by a few hundred rupees, deposits do not match, returned parcels are charged twice or not at all, and sellers complain that payouts are late and unexplained. For small sellers on Instagram or their own sites, this cash is their working capital.

What already exists and the gap

• Onro and Shipday offer delivery management for local businesses, with dispatch, driver apps and tracking.
• CourierManager sells COD settlement software for courier companies, focused on matching collections to shipper payouts.
• Large national couriers run their own in-house systems, which are not available to small regional couriers.

Dispatch tools treat COD as a field on a delivery, and accounting tools treat it as a lump sum. The gap is a system where every rupee of COD is a tracked ledger entry from doorstep to payout, so a small courier can answer "where is this seller's money?" instantly and prove it.

What you build

Roles: merchant (books parcels, sees payouts), ops staff (runsheets, returns), rider (mobile web app), branch cashier (cash handover, deposits), finance (payouts, reconciliation).

Flow: merchants book parcels; ops assign runsheets; riders deliver and record outcomes; at night riders hand over cash; the cashier deposits; finance runs weekly payouts. Every money movement posts balanced ledger entries between accounts such as customer, rider wallet, branch cash, bank, merchant payable and fee income.

The technically interesting part

There are three hard problems, and a strong team should tackle all of them.

A double-entry ledger. Every event posts debits and credits that sum to zero. Balances for a rider, branch or merchant are sums of entries, never stored directly. Corrections are reversing entries, not edits. This is the discipline payments companies such as Stripe describe in their engineering writing, and it gives you auditability for free.

Idempotent, offline-tolerant status updates. Riders lose signal. A "delivered with 3,450 collected" event may be sent twice or arrive after a "failed" retry. Give each event a client-generated ID, reject duplicates, and define a state machine that rejects impossible transitions. Test it with replayed and reordered event streams.

Reconciliation. At handover, compare expected cash (sum of delivered COD on the runsheet) to cash handed over, and record variances. Weekly, prove that merchant payouts equal COD collected minus fees and returns for every merchant. Build a reconciliation report that shows zero unexplained differences, or lists each one.

How to evaluate it

• Ledger invariants: a property test that generates thousands of random parcel lifecycles and checks the ledger always balances and every merchant statement equals the sum of its parcels.
• Duplicate and reorder safety: replay a day of rider events with 10 percent duplicates and random reordering; final state must equal the clean run.
• Load: with k6, simulate 200 riders sending updates during an evening peak; report 95th percentile latency and error rate.
• Pilot or realistic simulation: run one week of a small courier's anonymised data or a realistic synthetic dataset, and report the time to produce payouts compared with their current process.

Suggested plan

1. Weeks 1 to 3: interview a small courier and two online sellers; map the cash chain and write the account list.
2. Weeks 4 to 8: parcels, merchant booking, runsheets and parcel state machine.
3. Weeks 9 to 13: rider PWA with offline queue and idempotent events.
4. Semester 2, weeks 1 to 5: double-entry ledger, cash handover, returns and fees.
5. Weeks 6 to 9: payout statements, reconciliation report, property tests.
6. Weeks 10 to 14: load test, pilot or simulation, final report.

Path to a product

Your first customer is a regional courier or a city-level delivery company with a few dozen riders, which is too small for enterprise software and too big for spreadsheets. Price per parcel processed, which scales with their revenue. A second customer type is an online seller collective that runs its own riders. Grow by adding integrations with store platforms once the ledger is proven.

Scope warning

Do not build a routing optimiser beyond a simple heuristic, a customer mobile app, live GPS tracking, or real bank and wallet integrations. Record payments; do not move money. Do not build HR or payroll for riders.

Learn what you need on Sefism

• System design roadmap : idempotency, state machines and consistency are the core of this project.
• Backend cheat sheet : queues, transactions and API patterns.
• Stripe Engineering Blog : ledgers, idempotency and money movement done carefully.
• Swiggy Bytes : last-mile delivery engineering from a large delivery platform.
• PostgreSQL Documentation : constraints and serialisable transactions for the ledger.

Get help with this idea

This is a big project, so split it cleanly between dispatch and money from week one. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session