Returns, RTO & COD

Returns, RTO and COD are built into the core app because this is where D2C brands most often lose money.

Returns & replacements

Started from the order page, two flavours:

• Return: a reverse pickup from the customer back to you.
• Replacement: a new outbound parcel (same items or corrected ones), created as a proper clone order that flows through the normal pick → pack → ship pipeline, flagged so packers know it's a replacement. The items you pick when creating it are what the clone order — and its shipping label — list, so the packer sends exactly those; tick "same items as the original order" to resend everything. One of the two is required — a replacement can't be created without saying what's being sent.

Created one by mistake? Open the return or replacement and use Cancel (support and up; a reason is required). It cancels the whole order at the courier too — possible only before the parcel is picked up — and if a cancelled replacement's stock had already been deducted, the units go back on the shelf automatically.

For each one the system creates the Shiprocket shipment, tracks it, and gives your warehouse a receiving step: when the parcel arrives, record its condition: good (restocks automatically if you've enabled that) or damaged (goes to the damaged bucket, never back into sellable stock). Reasons are captured at creation, so you can later see why things come back.

RTO (return to origin)

COD reality: some parcels never get delivered and come back. The system:

• tracks which shipments have flipped to RTO status via the courier feed,
• gives the warehouse an RTO scan-in: scan each returned parcel as it arrives, so "the courier says 14 are coming back" reconciles against "we've physically received 9". The scan matches the order number or either waybill — couriers usually bring a parcel back on a new (RTO) waybill, and that's the number printed on the box. The RTO tab also flags parcels the courier says are back but nobody has scanned,
• restocks good units / flags damaged ones, same as returns.

NDR (non-delivery reports)

When a courier can't deliver ("address issue", "customer unavailable"), the order's shipping status shows it. The re-attempt/RTO action buttons stay in Shiprocket's panel.

COD reconciliation

Couriers collect cash for you and remit it later, in lumps. The COD screen matches those remittances against delivered COD orders, so you always know:

• how much COD is delivered but not yet remitted,
• which orders a given remittance (UTR) actually covered,
• what's been outstanding unusually long.

The "money received" side fills in two ways:

• Pull from Shiprocket — the button on the COD tab asks Shiprocket order by order and records what has actually been remitted. Nothing to download, nothing to upload. It runs in the background; the first run on a long history takes several minutes, day-to-day runs are quick because only orders not yet remitted are checked.
• Import the remittance report — upload the file from Shiprocket's panel. Kept as the fallback; re-importing an overlapping report is safe.

Either way, once money is recorded as received, the matching COD orders are marked paid in Shopify automatically.

The common thread

Across all three screens the idea is the same: anything not yet accounted for sits on a visible list until it is.