Articles
Cash on delivery is an operations problem, not a payment option
Cash on delivery is a cash-handling operation with a delivery step attached. What to record, how to reconcile, and where the money quietly goes missing.
- ecommerce
- delivery
- logistics
Cash on delivery is usually listed next to card payment, as if it were a setting. It is not. It is a cash-handling operation with a delivery step attached: goods leave before any money exists, and the record of who owes what gets written by three different people. It becomes a genuine payment option only when you deliver in your own vehicle, in your own city, and settle the same evening. Everything beyond that is reconciliation, and reconciliation is work nobody budgets for.
Why does the money arrive after the goods?
Because the parcel travels with a third party. The customer hands cash to a driver who is not your employee, and that driver's employer settles with you later, against a batch. Between the moment the parcel leaves your shelf and the moment cash reaches your account, you control nothing and you know only what someone tells you.
That gap is the whole problem. Every figure you report about the month — revenue, margin, what the shop actually earned — depends on what you recorded during the gap, not on what happened in the shop.
What does the confirmation call actually protect?
It protects the address, not the sale. Most failed deliveries are not refusals; they are parcels nobody could find. A commune name with no street, a phone that rings out, a customer who used a nickname on the order form.
So the call is a data repair step, and it works only if there is something to repair into. The order form needs a wilaya, a commune, a written landmark, and a second number. If it takes one phone field and a free-text address box, the driver is making the decision at the door, in front of the customer, with your parcel in his hand.
Whose record is the truth: your order list or the courier's manifest?
Neither. Your list says what you promised; the manifest says what was handed over. They disagree by a line or two per run, and nobody notices until the money is short.
Keep both, and key them on an identifier you generate. Not the customer's phone number, which changes and gets reused by family members. Not the courier's number, which you do not control and cannot query next year. The parcel label should be printed from your system, so that when a line does not match, you are looking something up rather than arguing about it.
How do you reconcile the cash against delivered orders?
Three questions per order, answered at least monthly: was it delivered, how much was collected, and did that amount reach the bank or the till?
That is only answerable when a delivery status arrives with an amount attached, and when the settlement you receive references the batch it belongs to. A courier who pays a lump sum without batch detail is asking you to trust a total. A total you cannot break down is not a reconciliation — it is a rumour with a bank reference.
What has to happen when a parcel comes back?
A refused parcel is a normal outcome, not an exception, and the return loop is where stock quietly disappears. The parcel must re-enter stock, in a recorded condition, with a recorded reason.
The reason matters more than the count. "Refused at the door", "no answer after two attempts" and "wrong item sent" point at three different fixes: a different confirmation script, a different zone, or a picking error. A returns pile that nobody classifies teaches you nothing and costs you the same every month.
Who owns a disputed delivery?
Write the rule down before the first dispute, not during it. In practice: the courier's scan triggers the state change, the signed receipt is the proof, and the settlement line is the settlement.
Then name one person who owns that queue — a role, not "whoever is free". Disputes that belong to nobody turn into discounts, and a discount given to close an argument is the most expensive way to end one.
What must the system record for the monthly figure to be real?
| Event | Reported by | What is stored |
|---|---|---|
| Order placed | Your shop | Address, phone, basket |
| Parcel shipped | Courier | Manifest, batch, date |
| Delivered | Courier | Amount, receipt |
| Refused | Courier | Reason, return date |
| Settled | Courier or bank | Batch, amount, date |
If one of those five is missing, the month is an estimate. An estimate is fine for a conversation and useless for a price change, because you cannot tell whether the margin moved or the record did.
In what order do you fix this?
- Count what you can actually prove. Take last month and try to tie every delivered order to a collected amount. The number you cannot explain is your baseline.
- Fix the order form before anything else: wilaya as a list, commune as a list, landmark as a required field, second phone as optional.
- Generate your own parcel reference and print it on the label.
- Agree with the courier what the statuses mean, in writing, including what counts as a second attempt.
- Reconcile weekly for one month, even if the volume does not justify it. You are looking for the pattern, not the total.
- Only then automate. A system built on an unreconciled process will produce a faster wrong number.
Where this goes wrong
- The status list is invented at the courier's convenience. "Delivered" and "delivered and paid" are different facts, and merging them loses the only question you care about.
- The confirmation call becomes a sales call. The agent starts persuading instead of repairing the address, and the failure rate does not move.
- Cash is counted by the person who collected it. One person, one count, no second signature, and a shortage nobody can trace.
- Returns re-enter stock without a state change. The count drifts, and the drift gets blamed on theft.
- The monthly report is built from orders, not from settlements. Revenue looks healthy in the month the parcels shipped and collapses in the month the cash did not arrive.
What this does not cover
It does not tell you which courier to use, or what a delivery should cost — that is a separate decision about zones and volume. It says nothing about the tax treatment of cash sales, which depends on your accounting and your invoices. And it assumes the customer's phone number is reachable at all; in practice, a share of orders never connects, and the only fix for that is deciding how many attempts you are willing to pay for.
We build the order and delivery record that makes this reconcilable: statuses that mean one thing, a parcel reference you own, and a settlement line that ties back to a batch.
Services in this article
Articles
Related articles.
Work out delivery cost before you set a price
Delivery is priced per parcel you hand over, but it is paid per order that arrives. How to build a cost per delivered order before you set a price.
- delivery
- pricing
- ecommerce
Accepting online payments in Algeria: the two paths, and who each one suits
Card acceptance in Algeria runs through a bank arrangement or a gateway on the same two card schemes. What each path changes, and what you build either way.
- payments
- ecommerce
- algeria
One stock number across several shops: what actually breaks
With a second shop, the transfer becomes the weak point: an item sold on one side, bought on the other, owned by nobody in the van. What to model first.
- inventory
- logistics
- multi-site
Start a project
Have something to build?
One short brief is enough. You get a written scope and a fixed quote before anything starts.
