Sales Returns
A sales return brings product back from a direct-to-consumer sale. It is the follow-up document to the sales receipt: every return operates on a receipt that has already completed, because the completed receipt is the proof the product was delivered, and a return is that delivered product coming back. The receipt itself is untouched by all of this; its flow works exactly as if returns did not exist, and the return is a separate document layered on top, with its own number, its own lifecycle, and its own line items.
Returns are restock-only: product that comes back goes into sellable finished-goods inventory. There is no scrap or quarantine path yet, and a return records no money, no refund amount, no prices, no costs. What the returned stock is worth is derived by the cost model at read time, from the receipt it came from.
What it does
- Track the return. At its core a return is a record of product coming back: which
completed receipt it belongs to, which of that receipt's lines are affected and by how
much, where the goods are restocked, and how far along the journey back they are. It
carries its own number,
RET-YYYY-NNNN, minted by a dedicated counter alongside the other document counters. Each line targets one line of the receipt and a quantity in cases, fractional like the receipt's own, and the quantity can be partial: a customer who bought ten and sends back three is one line for three. - Restock finished-goods inventory. When the return completes, each line posts a RECEIVE into the finished-goods ledger at the restock location, under its own return source. The product is sellable again the moment it lands.
One rule protects the link to the receipt: across every live return, the total returned against one receipt line can never exceed what that line delivered. Cancelling a return frees its claim; bringing it back re-checks the cap, in case another return took the allowance in the meantime.
How it works
A return is always in exactly one status, and every move is by hand: it is planned, sent on its way back, and finally received into stock. Only the last step touches inventory.
The statuses
| Status | Type | What it means |
|---|---|---|
| Planning | Manual | Draft. You are preparing the return; nothing is committed and inventory is untouched. |
| Placed | Manual | Agreed with the customer; the goods have not moved yet. |
| In Transit | Manual | The goods are on their way back. Still not in inventory. |
| Completed | Endpoint | The goods have arrived and are restocked. Each line posts its RECEIVE. |
| Cancelled | Exit | Called off before completion, from any earlier status. Nothing had posted, so there is nothing to reverse. Can be reactivated, subject to the cap. |
Moving between them
- By hand, both ways. Advance Planning to Placed to In Transit to Completed as the return progresses, and step back to fix a mistake. Stepping back out of Completed un-restocks: the RECEIVE is reversed and the stock leaves inventory again.
- Cancelling. A return can be cancelled from any status before Completed; since nothing posts before completion, a cancel has no inventory effect. Once Completed, step back to In Transit first. Reactivating a cancelled return re-checks the over-return cap.
- Deleting. A hard delete physically removes the return's ledger rows, matching the established behavior of every other document.
Effect on inventory
| What you do | Ledger effect |
|---|---|
| Plan, place, or ship the return | nothing; inventory is untouched until the goods arrive |
| Complete it | posts a RECEIVE per line at the restock location; on-hand rises |
| Step back out of Completed, or cancel a completed-then-reopened return | reverses the RECEIVE; on-hand drops back |
| Delete | removes the return's rows; on-hand recomputes as if it never happened |
Every entry carries the return's number as its reference and a source of "return", so a restock is never mistaken for a vendor delivery or a transfer arriving.
What comes back with the stock
The returned units re-enter at what they left with. Each restock inherits the layers the receipt line's shipment drew: each lot, its expiration, and its cost, scaled to the returned quantity. Send back half a shipment that spanned two lots and the restock is those same two lots, half of each, each still knowing its own expiration and cost, so FEFO and valuation treat the goods as if they had never left. In the ledger view a multi-lot restock shows as one line per lot; see Lots & Expirations for how that split works.
None of it is frozen on the return. The restock value is derived on read from the originating receipt line, valued as of the moment the goods originally shipped, so it stays correct even when earlier history is corrected: reprice the purchase that stocked the shipment and the return's value follows on the next read. A return whose receipt has been stepped back out of shipping no longer has a shipment to vouch for it, and its restock values at zero until the receipt ships again.
Dates
- Return date is yours. It defaults to today when you create the return and you can change it whenever.
- Status dates (planning, placed, in transit, completed, cancelled) stamp themselves as the return reaches each status, but stay editable afterwards so you can correct them.
The RECEIVE takes its business date from the completed date, so editing that date moves the restock with it. The record-of-entry timestamp never moves, so the stock history always reads in true business-date order, which is what positions and the cost model sort by.
Not yet
- Dispositions. Every return restocks. A scrap path (damaged goods written off on arrival) and a quarantine path (held for inspection before restocking) are natural extensions of the same document.
- Refunds. A return records no money. Tracking a refund amount, and how it nets against the receipt's revenue, is deferred until returns meet accounting.
See also
Create, advance, update, and delete returns through the REST API or the MCP server.