The batch that doesn't balance

The instinct is obvious. You shipped ₹96,000 in COD orders this week. Your bank received ₹84,420. The ₹11,580 gap must be something someone didn't send you. Almost every D2C founder arrives with this framing, and almost every time, the framing is the problem. COD remittances are not a weekly summary of COD sales. They are a rolling window of delivered-and-deposited orders that spans multiple calendar weeks, nets out returns and fees, and lands in your bank on the courier's schedule — not yours.

The cash takes four stops. A customer hands ₹ to a delivery agent at the door. That agent deposits the cash at a courier hub — Delhivery requires this within 24 hours; in practice it can stretch. The courier pools that cash across hundreds of sellers into a single batch. When the batch closes — 48 hours from hub deposit for Delhivery, weekly runs for Shadowfax, 7 working days for XpressBees and BlueDart — the courier initiates a single NEFT credit to your bank. One NEFT. Containing orders from multiple prior weeks. Arjun's Tuesday credit held 51 orders from the current week, 22 from the prior week, and 4 from the week before that — delayed deliveries finally completed. It excluded 29 of his current-week dispatches, which close in next cycle. A week of dispatches and a batch are different things.

Inside the batch, three deductions happen before the NEFT leaves the courier's pooled account. The COD handling fee — Delhivery's standard rate is roughly 2% of the collected amount; most couriers charge between 1.5% and 4%. GST on that fee at 18%, which is a logistics service charge and claimable as ITC if your GSTIN is on the courier's invoice. Any weight or zone adjustment billed for the cycle, which may net against the COD remittance rather than arriving as a separate freight invoice. A fourth number sometimes surprises: if the courier's wallet ran negative in a prior cycle, the previous batch's remittance was deferred — and then releases weeks later as a bonus amount in a future credit. This is why Arjun's Tuesday bank credit included ₹6,000 from a deferred batch six weeks earlier.

The hardest part of COD reconciliation is not the fee arithmetic. It is knowing which orders are genuinely returned versus which have been marked returned without a delivery attempt. RTO is legitimate: the customer wasn't home, the address was wrong, the order was refused. But fake RTOs — where a field agent marks 'Customer Not Available' without attempting delivery, and the cash goes elsewhere — are a documented problem. The only way to catch them is AWB-level matching. Every order has an Air Waybill number; every remittance line has one too. When an order shows as RTO-with-no-return-scan, or RTO-then-redelivered-same-day, the anomaly surfaces. Tools purpose-built for COD reconciliation classify this as a distinct category precisely because it is common enough to warrant one.

The reconciliation's output is not a matching total. It is a list with four rows: settled (AWB found, amount matches), pending-in-SLA (delivered, remittance window still open, no action yet), overdue (window passed, no credit, raise a dispute), and RTO-to-verify (marked returned, confirm the return scan exists). That is what Riya gives Arjun at the end: not the number ₹11,580, but what to do with each rupee of it. For a seller at ₹25 lakh a month with 30% COD, getting this wrong silently costs more than the reconciliation work costs to do. The founders who skip it discover the loss months later, in aggregate, when the trail back to carrier and cycle is already cold.