The anatomy of a courier settlement
If you run a courier operation that handles cash on delivery, the moment a parcel is delivered isn’t the end of the transaction — it’s the start of three of them. The recipient pays the courier in cash. The courier returns to base and reconciles. Eventually, the shipper client gets their money. Most operations think of this as one flow. CourierManager treats it as three layers, and the difference is what keeps the operation solvent when shipments cross borders, currencies, or partner boundaries.
Layer 1 — Collection
Collection is the courier-to-cash side of the equation. A driver delivers ten parcels in a morning, takes ten cash payments in whichever currency the recipient pays in, and comes back to the warehouse with a stack of receipts and a sum that should add up.
The CourierManager driver app generates a numbered receipt at the point of payment, ties the cash amount to the AWB, and produces an end-of-shift summary the moment the courier returns. Reconciliation against expected COD totals is automatic — every shipment knows what it was supposed to collect, every collection is tied to its shipment, and every discrepancy is flagged before the cash is even counted.
Where this gets harder: when a partner courier collects on your behalf. You don’t have the driver app on their phones; you have an API or a CSV. The same matching has to happen, against an external feed, with the same flag-the-discrepancy expectation. CourierManager runs both flows on the same model — your own collection and your partners’ — so the reconciliation logic is consistent across the boundary.
Layer 2 — Conversion
Layer 2 is where most homegrown systems break. A Bulgarian recipient pays in BGN. The shipper client is invoiced in EUR. The courier subcontractor is settled in RON. Three currencies, one parcel. Every conversion is a potential discrepancy — and a potential margin leak if the rates aren’t pinned to a moment in time.
CourierManager handles conversion explicitly: each leg of the financial flow has its own currency and its own conversion event. The platform pins exchange rates per settlement run, records the conversion in the audit trail, and surfaces the rate that was applied for every shipment in every currency. When a discrepancy shows up at month-end — and at scale, it does — you can trace the cents to a specific parcel, a specific rate, and a specific timestamp.
This matters most for cross-border integrators (FAN International running thirteen-country flows is the canonical example) but it also matters for any domestic operation with sensitive margins. The difference between “we collect in cash and pay out in cash” and “we collect in cash and pay out cleanly” is a finance team that can close the books on time.
Layer 3 — Settlement to client
Layer 3 is the part the shipper client sees: their COD payout. They sent the parcels, they’re waiting for the money, and every day of delay damages the relationship.
CourierManager’s client-settlement module calculates exactly what each client is owed, net of transport charges. It generates a settlement statement per client, per cycle (daily, weekly, monthly — configurable per client), with the underlying AWB list as backup. Where a client has unpaid transport invoices, the system automatically offsets them: a compensation invoice is generated, the transport invoice is marked paid, and only the net amount transfers. No manual calculation, no spreadsheet, no risk of paying out gross while leaving the transport receivable uncollected.
For shippers who opt into Revolut or another integrated banking flow, the payout itself is one click. For everyone else, the settlement statement is the deliverable and the bank transfer is the operator’s job — but the math is done.
Why three layers and not one
A single-layer COD model — “collect cash, pay it out, done” — works at small scale and breaks the moment any of the following happens: shipments cross currencies, a partner courier is involved, a courier subcontractor is paid by commission, or a client wants weekly payouts instead of per-shipment.
Three layers means the operation stays solvent when those edge cases happen, because each layer has its own ledger, its own currency, its own reconciliation, and its own audit trail. When you discover a discrepancy six months later, you can pin it to the layer that failed.
This is the architecture of a real settlement engine. It’s also why the COD module on CourierManager is the second-most-asked-about feature on demos, behind hub sorting and ahead of the driver app. Operations that have been bitten by single-layer flows know exactly what they’re looking for.
See it on a real operation. View pricing → — every plan includes the full COD module, including multi-currency conversion and per-client settlement cadence configuration.