CanopyDocs
Docs

Returns

Create and process RMAs end to end — receive, inspect, disposition, and refund — plus the reason codes customers pick from.

Returns is reverse logistics across all clients: each RMA from creation through receiving, inspection, and disposition to the refund that follows — plus the reason codes customers choose from. A brand watches this happen; you run it.

Operator vs. client view

A client tracks their RMAs and sees the results. You do the hands-on work they can't: create an RMA, process it — receive, inspect, and disposition each unit — and manage the reason codes.

The RMA list

Returns → All RMAs lists every return authorization and where it is.

The RMA list

StatusMeaning
PendingCreated; awaiting the customer's shipment.
In TransitOn its way back.
ReceivedArrived at the warehouse.
InspectingBeing checked over.
CompletedDone — items dispositioned and refund resolved.
CancelledCancelled.

A Completed RMA shows a refund chip — Refunded, Refund pending, or Refund failed. RMAs from a connected store carry a Shopify badge; one that synced from a store without matching to an order shows as blind (you don't create those — the system does). Tabs filter by status, and you can search by RMA number, tracking, or customer.

The operator additions are the action buttons: a Pending RMA gets Receive, an in-progress one gets Continue — both open the processing flow — and Create RMA sits at the top right.

Creating an RMA

Returns → Create RMA (operator-only). Most RMAs flow in automatically when a customer requests a return in their store, but you can also raise one by hand:

Creating an RMA

Search for and pick the order to return against — every RMA links to an order, so you can't save without one.
Choose the items and quantities coming back, and each line's refund type (Refund, Store credit, Exchange, Replacement, Warranty, or No financial action).
Set a reason: a Default Reason Code for the RMA, or a Reason on every selected line — this is required, so Save stays blocked until each line has one.
Save. The RMA lands as Pending, ready to receive.

Processing a return

Receive / Continue on an RMA opens the scan-guided processing flow — the operator-only work clients never touch.

Receiving and inspecting a returned unit

Scan & Inspect. Scan the returned unit, set the quantity, and record its inspection result and disposition. The Expected Items panel tracks received against expected per line.

Disposition to a bin. The disposition is auto-suggested from the inspection resultundamaged and opened → Restock, defective → Dispose, wrong item → Quarantine. Restock suggests the Returns zone; Quarantine and Return to vendor suggest the Quarantine zone; Dispose takes no bin at all (the unit is written off, so the bin picker is hidden). Add notes, then Record Receipt.

Complete RMA. Once every unit is handled, complete the return. Restocked units flow back into sellable inventory; the refund resolves per the RMA's terms.

The inspection result constrains which dispositions are allowed — damaged or wrong-item goods can't be restocked into sellable stock:

Inspection resultAllowed dispositions
UndamagedRestock, Quarantine
Opened (still resellable)Restock, Quarantine, Dispose
DefectiveQuarantine, Dispose, Return to vendor
Wrong itemQuarantine, Return to vendor

For lot-tracked SKUs, restocking is blocked until you pick a lot (the flow suggests the lots shipped on the order); the escape hatch is to Quarantine instead. A bin can't hold two lots of one SKU.

A raw all-caps line status shows in the Status column of the Expected Items panel and the detail Items table (the Received column, by contrast, is a received-vs-expected count like 0 / 1, not a status):

Line statusMeaning
PENDINGNothing received against the line yet.
PARTIALSome but not all expected units received.
COMPLETEAll expected units received.
OVERMore received than expected.
SHORTFinished with fewer than expected.

Following an RMA

Open any RMA for the full picture across Details, Attachments, and Timeline: the customer and reason, the return label, each returned line and its refund type, and the receipt log (per-unit inspection result and disposition, shown as raw all-caps like WRONG ITEM / RETURN TO VENDOR). The detail page also carries the stage actions the list rows don't — Start Receiving / Continue Receiving, Complete (needs at least one receipt), and a destructive Cancel (Pending / In Transit only) — plus a Generate Label button (only for a Pending RMA with no label or tracking yet, whose reason policy is store-paid or flat-rate) that mints a Stallion return label emailed to the customer.

A completed RMA's detail (refund not yet issued)

The Refund card shows the computed breakdown and its state: Not yet issued, Ready, Issued, or Failed — retry available (the button becomes Retry Refund). Issue Refund pays it out; Adjust opens a dialog to override the subtotal or add a structured adjustment — Restocking fee, Return shipping fee, Goodwill credit, Shipping refund, or Other (negative to deduct, positive to credit). Adjustments propagate to Shopify.

The Adjust Refund Payload dialog

A header badge tracks channel sync — Synced with Shopify, Sync pending, or Sync failed (with a Retry sync button) — so you know whether the refund and return status made it back to the store.

Return reason codes

Returns → Return Codes is the list of reasons a customer picks when starting a return, and — crucially — who pays for the return label.

Return reason codes

PolicyWho pays / what happens
Return Paid By StoreYou cover the label; the warehouse generates it.
Flat Rate ShippingThe customer pays a set fee, deducted from their refund.
Return Paid By CustomerThe customer ships it back themselves.
Not ReturnableAn RMA can't be created with this reason.

As an operator you Add Return Code, edit a code's label policy, or disable one (kept for history, never deleted). Codes can map to a channel's native return reasons (e.g. a Shopify reason) for round-trip sync.

Adding a return reason code

On this page