> ## Documentation Index > Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Receiving and inspecting returns > Receive returned parcels in the warehouse, confirm what came back, update stock, handle failed deliveries coming home, and issue refunds or credit memos. > [!NOTE] > > **Where to find it:** Main → Shipping → Returns — [Open in OTO ↗](https://app.tryoto.com/returns) This is the half of a return that decides whether it cost you a parcel or a product. Everything before it was a conversation; from here someone is holding the box. ## One form, six stages A return is worked through a single **View Return Details** form rather than across several screens. A progress bar across the top names every stage and marks where this one has got to. ![The return details form, mid-lifecycle](https://mintcdn.com/oto/lDMfM_zaxBnpzX-0/images/ret-4-details.png?fit=max\&auto=format\&n=lDMfM_zaxBnpzX-0\&q=85\&s=65ec29ba2310397376db323db7617122) Fig. 1 — Six stages: Request Created → Pending Approval → Reverse Shipment → Received → Items Confirmed → Refunded. This return is at stage three. | Stage | What it means | | - | - | | **1 · Request Created** | The customer asked, or you asked on their behalf. | | **2 · Pending Approval** | Waiting on a decision. | | **3 · Reverse Shipment** | Approved. The item now has to be collected. | | **4 · Received** | The parcel is with you. | | **5 · Items Confirmed** | Someone has counted what is actually in it. | | **6 · Refunded** | Money, exchange or credit issued. Closed. | > [!TIP] > > **The form tells you what to do next** > > Above the detail sits a banner naming the current stage and the actions available at it — here *“The return request is approved. Create a reverse shipment to collect the items from the customer”*, with **Create Return Shipment** and **Reject Return** beside it. > > That is the difference between a status field and a workflow. Nobody has to know what stage four requires; the form says so, and offers only the actions that make sense there. ### What the form holds | Panel | Contents | | - | - | | **Order Information** | **Order ID** (with its **-R1** suffix), **Return Request Source** — *Customer Portal* or raised by you — **Request Date**, **Customer Name** and **Status**. | | **Return Details** | **Return Method**, **Refund Method**, **Approved Refund Amount**, **Return Window** (e.g. *Within 30 days*) and the **Customer Comment** from the request. | | **Quick Actions** | **View Main Order**, **Add Internal Note** and **Return Shipment Details**. | | **Return Items** | The quantity table. See below. | | **Return or Exchange Reason Attachments** | The photographs the customer uploaded with the request. | > [!TIP] > > **Return Request Source is worth reading** > > It records whether the customer raised this themselves or someone on your team did it for them. Over a few hundred returns that ratio is a measurement of whether the portal is working: a high proportion of agent-raised returns means customers are not finding it, or not trusting it, and are calling instead. ### Four quantities, not one The **Return Items** table carries every number separately, per SKU: | | | | - | - | | **Ordered Quantity** | What they bought. | | **QTY Return Requested** | What they asked to send back. | | **Last Confirmed QTY** | What you agreed to. | | **Returned Quantity** | What actually arrived. | | **Return Reason** | Why, in the customer’s words, from your reason list. | > [!TIP] > > **The gap between requested and returned is the whole discipline** > > Most systems keep one quantity and overwrite it, which means that by the time a refund is issued nobody can tell whether the customer asked for two and sent one, or asked for one and sent two. > > Keeping all four side by side means the discrepancy is visible at the moment of the refund rather than reconstructable afterwards — and it is the single most useful piece of evidence in a fraud case or a supplier claim. ### 1 · Create the reverse shipment The return label is generated inside the form. You choose the shipment option — **OTO Rates** or **Own Rates**, exactly as on an outbound order — and the destination, which can be any warehouse or branch. The **Return Label** (airway bill) prints from the **Quick Actions** menu. > [!TIP] > > **The return does not have to come back where it came from** > > Sending every return to the warehouse that shipped it is the obvious default and often the wrong one. A returns-processing hub, the nearest warehouse to the customer, or the branch that can resell the item immediately may all be better — and choosing the destination per return is what makes that possible. > > This is the whole of reverse logistics in one field: the route back is a decision, not a reflection of the route out. ### 2 · Receive it When the parcel arrives, the form records the **Receiving Date and Time**, the exact **warehouse or branch** that took it in, and internal notes on the physical condition of what was received. Those notes are for you rather than the customer, and they are what a refund dispute is settled with three weeks later. ### 3 · Confirm the items The critical step, and the one that must come before any money moves. It matches **the quantity requested against the quantity actually received**, and verifies the **return reason** the customer gave at the start against what is in the box. ### 4 · Process the refund Only now. The form shows the refund amount **calculated by your e-commerce platform**, you select the method — Money Back, Exchange or Store Credit — and confirm, which moves the request to **Completed**. > [!TIP] > > **Partial is the normal case, not the exception** > > A customer returning three of five items, or returning something with a missing accessory, is ordinary. Confirming quantities per SKU rather than accepting the request wholesale is what turns that from a write-off into a partial refund. > > The options run the full range — accept it, refund part of it, refund all of it, or send it back — and they exist because returned goods genuinely arrive in all four of those states. ## Confirming in the warehouse The desktop path runs from **Shipping → Shipments → Returned**: | Action | What it does | | - | - | | **Tools → Confirm Return** | One order. Opens the Return Confirmation Form: return reason, customer return comment, and a **quantity to confirm per SKU**. | | **Tools → Confirm Return Multiple** | Several orders at once, confirming every item in them and adjusting inventory accordingly. | | **Tools → Edit Return Reason** | Correct the reason after the fact. | | **Tools → View Return Details** | Shipment information, return reasons and the customer’s comments in one place. | > [!WARNING] > > **Bulk confirmation trusts the request** > > **Confirm Return Multiple** accepts every item in every selected order without anyone counting. On a backlog of straightforward returns that is exactly the right tool; on anything where quantity or condition is in question it converts an inspection into an assumption. > > Worth reserving for volume, and keeping single confirmation for anything that matters. ### In the app **Return** is one of the nine actions in [the OTO PACK app](https://docs.tryoto.com/modules/warehouse-management/ops.md). The operator picks the order and confirms items by **scanning** — or by manual selection where scanning is not possible — and inventory updates in real time. Scanning is the point. A return confirmed by eye against a list is a return where the wrong SKU can be put back into sellable stock, and that error is invisible until someone tries to pick it. ## What a confirmed return does to stock | Level | What changes | | - | - | | **Quantity on Hand** and **Quantity Available** | Both adjusted to the quantity physically returned. With OTO INVENTORY. | | **Bin inventory** | Returned items are placed automatically in the **Return** bin. With OTO PACK Advanced and bin tracking. | > [!TIP] > > **Why the Return bin matters commercially** > > Stock in a Return bin is counted but not sellable, so [sync](https://docs.tryoto.com/modules/inventory-management/inventory-sync.md) does not offer it to a storefront while it is waiting to be inspected. > > That is what prevents the worst version of this: reselling a returned item before anyone has established that it is fit to sell, and turning one unhappy customer into two. ## Failed deliveries coming home A parcel that could not be delivered comes back whether anyone asks for it or not. That is **return to origin**, and it is handled automatically rather than as a customer request — the order is marked returned, and the goods re-enter through the same receiving path as anything else. On the delivery side, a driver handing an undelivered parcel back at the warehouse uses **Drop & Return Order**, which requires a return reason before it will complete — see [Delivery](https://docs.tryoto.com/modules/oto-flex/delivery.md). > [!NOTE] > > **Count these separately** > > A return-to-origin is a delivery failure wearing a return’s clothes. Its causes are addresses, phone numbers and time windows; a customer return’s causes are fit, expectation and quality. > > Reported together they produce a returns rate that nobody can act on, because the two halves need entirely different fixes — one belongs to [address verification](https://docs.tryoto.com/modules/customer-notification/branded-pages.md), the other to your product pages. ## Refunds and credit memos Where the sales channel supports it, confirming a refund writes it back: the refund is issued and a credit memo created on the e-commerce platform automatically, so the finance record matches the physical one without anyone re-keying it. That is the step most returns processes lose. A refund agreed in one system and recorded in another is a reconciliation problem that surfaces at month end, by which point the parcel, the person and the reason are all long gone. ## Related * [Customer returns](https://docs.tryoto.com/modules/return-management/customer-returns.md) — how the request got here. * [Inbound and putaway](https://docs.tryoto.com/modules/warehouse-management/inbound-putaway.md) — bin types, including Return. * [Inventory tracking](https://docs.tryoto.com/modules/inventory-management/inventory-tracking.md) — the numbers a confirmation moves. ## Related topics - [Return Management](https://docs.tryoto.com/modules/return-management/overview.md) - [Return portal and customer return requests](https://docs.tryoto.com/modules/return-management/customer-returns.md) - [Return automation rules](https://docs.tryoto.com/modules/return-management/return-automation.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.