Cash on delivery is shrinking. It’s gone from roughly 45% of Indian ecommerce orders in 2021 to about 18% today, as UPI now covers close to three out of every four online transactions. If you only read the headline stat, COD reconciliation would look like a problem that’s solving itself.

It isn’t. Ask any ops manager still running COD at scale and you’ll hear the same thing: the volume went down, but the mess per order didn’t. The COD that’s left tends to sit in the categories and geographies where it’s hardest to collect cleanly — mid-value fashion and D2C orders, tier-2/3 pin codes, first-time customers a brand hasn’t scored yet. Smaller COD book, same number of ways for the cash to go missing.

Most teams still treat the fix as a finance problem: better matching software, tighter bank-statement reconciliation, more headcount ticking off transactions. That’s solving it at the wrong end. By the time a bank credit lands, the useful information — which rider, which stop, which discrepancy — is already three systems and several days removed from the transaction. This post is about where the problem actually starts, and what a delivery management system needs to do about it before it ever reaches a spreadsheet.

What COD Reconciliation Actually Involves

“COD reconciliation” gets used as if it’s one process. It’s really three, handled by different people, on different timelines:

Collection — the rider takes cash (or, increasingly, a UPI payment) at the doorstep and is supposed to record it against that specific order.

Remittance — the courier or 3PL batches everything collected over a day, a route, or a hub, and pays it into the seller’s account, usually with deductions already netted out.

Matching — the seller’s finance team tries to tie that lump-sum bank credit back to individual orders, to confirm every rupee collected actually arrived.

Nearly every “COD reconciliation” tool on the market — and nearly every article written about this topic — is built for stage three. It assumes stages one and two happened cleanly and just need to be verified after the fact. In practice, that’s where the gap actually opens up.

Where the Money Actually Goes Missing

A single bank credit can represent hundreds of orders collected over several days. When the amount doesn’t match what finance expected, there’s rarely a clean paper trail back to the specific stop where it went wrong. The usual culprits:

Partial collection at the door. A customer pays less than the order value — short of change, a part-payment negotiated on the spot, a damaged item accepted at a discount — and the adjustment either isn’t logged or is logged inconsistently across riders.

Delayed hub deposits. Cash collected on a Tuesday route doesn’t get deposited to the courier’s account until Thursday or Friday. In that window, it’s sitting with the rider or the hub, unreconciled, and if a bag goes missing or a shift changes hands, there’s no clean record of who held it last.

RTO orders where “delivered” and “collected” diverge. An order marked delivered in the tracking system isn’t automatically an order that was paid for. When returns happen after partial delivery, or a rider marks a delivery attempt as successful before actually collecting payment, finance sees a delivered order with no matching cash.

Digital COD that doesn’t reconcile like cash. More riders now carry a UPI QR code as a backup to cash. That’s good for the customer, but it splits the collection record across two systems — the courier’s cash log and a UPI settlement file — that often don’t get merged before someone in finance has to explain a shortfall.

Why Bank-Statement Matching Can’t Catch This

By the time a reconciliation tool sees the bank credit, it’s looking at a number, a date, and maybe a courier reference ID. It has no visibility into what happened at the doorstep. So the best a bank-statement-first tool can do is flag that something doesn’t match — not why. Someone still has to manually trace the discrepancy back through courier logs, rider run sheets, and delivery timestamps, which is exactly the “ticking and tying” work that eats a finance team’s week and rarely gets fully closed before the next batch of orders lands on top of it.

This is why COD reconciliation, done only as a downstream finance exercise, tends to stay a permanent fire drill rather than a solved problem. The fix has to start where the cash actually changes hands.

The Real Cost of Getting This Wrong

Unicommerce’s India D2C Report 2026 found COD orders returning at 58% during the festive quarter, against under 15% for prepaid orders in the same window — and RTO on COD swinging from 39.2% at the November 2025 festive peak down to 21.0% by March 2026 for brands that tightened their operations. Shipway’s ShipNotes report, built on FY25 shipment data, put the baseline non-prepaid RTO rate at 26% nationally, ranging from 18% in Vadodara to 35% in Patna, with RTO nearly doubling — from 22% to 35% — when delivery attempts slipped from 1–2 days to 5-plus days after the order was placed.

Every one of those returned orders is also a reconciliation event: cash that was never collected, or was collected and then has to be reversed, alongside forward shipping, reverse shipping, and repackaging costs. To make it concrete: a mid-size apparel brand running 10,000 COD orders a month at a 25% RTO rate is absorbing roughly 2,500 reversal cycles monthly — each one a chance for the “delivered,” “returned,” and “collected” flags to fall out of sync. (This is an illustrative estimate to show the scale, not a benchmark for any specific brand.) Multiply that across a hub network and it’s easy to see why finance teams report unresolved receivables that stay open for weeks, quietly affecting vendor payments, courier fee negotiations, and cash-flow planning until someone tracks each one down by hand.

Fixing It at the Source: What a Delivery Management System Should Actually Do

A COD reconciliation problem created at the doorstep can’t be fully solved by a tool that only looks at the bank statement afterward. It needs to be captured correctly at the point of collection. That’s a delivery management system’s job, not a finance tool’s — five things it should handle:

  1. A digital cash ledger per rider, per run. Every collection — full, partial, or converted to UPI — gets logged against the specific order and rider at the moment it happens, not reconstructed later from memory or a paper register.
  2. Hub-level till reconciliation before the bank deposit. Cash gets counted and matched against the day’s manifest at the hub, at end of shift — before it’s bundled into a single deposit — so a shortfall is caught within hours, not weeks.
  3. RTO-linked automatic reversal. When an order status changes to RTO or partial return, the system should automatically flag the expected collection amount for reversal, instead of leaving finance to notice the mismatch independently.
  4. Unified capture across cash and digital COD. Whether the customer pays cash or scans a UPI code at the door, it should land in the same ledger entry against the same order — not two records in two systems that someone has to merge manually.
  5. An exception queue with a named owner and a deadline. Every mismatch gets a status, an owner, and an SLA the moment it’s flagged, rather than sitting in a shared spreadsheet until someone has time to look at it.

Handled this way, “reconciliation” becomes something closer to real-time monitoring than monthly forensics. What lands in the bank should already match what finance expects, because the gap was caught — and usually fixed — days earlier, at the hub or on the route.

A 5-Checkpoint Framework You Can Implement This Quarter

If a full system change isn’t happening this month, these five checkpoints are where to start, roughly in order of effort:

  1. Audit your current collection-to-deposit gap. For a sample week, track how many hours or days pass between rider collection and hub deposit. If it’s more than 24–48 hours, that’s your biggest exposure window.
  2. Require a discrepancy note on every partial collection. Even a simple mandatory field — “customer paid ₹X of ₹Y, reason: __” — turns an untraceable shortfall into a searchable record.
  3. Match RTO status changes to collection status weekly, not monthly. Catching the mismatch inside a week keeps it small and traceable; catching it a month later means investigating dozens of orders at once.
  4. Separate your cash and UPI-at-doorstep records into one reconciliation view, even if it’s a manual merge for now. Two ledgers that don’t talk to each other is the single most common gap we see.
  5. Assign reconciliation ownership by hub, not centrally. A regional hub lead who’s accountable for same-week closure catches discrepancies faster than a central finance team working from batched reports.

Frequently Asked Questions

What is COD reconciliation? COD reconciliation is the process of confirming that cash (or digital payment) collected from customers at delivery matches what’s remitted to the seller and recorded against each order — covering collection, remittance, and final matching against the seller’s books.

Why does COD reconciliation still matter if COD volume is shrinking? Because the orders that remain COD tend to be concentrated in higher-risk categories and geographies, the operational complexity per order hasn’t dropped even as overall COD share has fallen from about 45% in 2021 to roughly 18% today.

What causes most COD discrepancies? The largest sources are partial collections at the doorstep that aren’t logged consistently, delayed cash deposits from hub to bank, RTO orders where delivery and collection status diverge, and digital COD payments recorded in a separate system from cash.

Can COD reconciliation software alone fix this? Bank-statement-matching tools help close the loop, but they can’t catch discrepancies created at collection — they can only flag that something doesn’t add up after the fact. Fixing the root cause requires capturing collection accurately in the delivery management system itself.

How does RTO affect COD reconciliation? Every RTO order is also a reconciliation event: any partial collection has to be reversed, and if the “delivered” and “collected” statuses aren’t linked automatically, that reversal often gets missed until someone manually audits the order.

Want to see ZenDMS on your operation?

Talk to our team for a 30-minute working demo, on your data, your lanes, your constraints. Schedule it here.