Returned goods: reconcile stock and customer credit
Keep physical returns, customer credits and refunds connected without assuming that one action automatically completes the others.
On this page
A returned item, a credit note and a refund describe different events. The item may have arrived without passing inspection. A credit may reduce an outstanding balance without sending money back. A refund may be due even when the original invoice is already settled. Your workflow should preserve these distinctions.
Start with the original transaction
Record the original order, invoice and item line against the return request. Capture the quantity, reason and agreed resolution. A free-text customer name is not enough to determine which sale is being adjusted, particularly when the same customer buys the same item repeatedly.
Give the return a reference that follows it through warehouse and finance review. Do not assume that approving a return authorises every later financial action. Set approval responsibilities according to the value and reason for the adjustment.
Inspect before making stock available
The warehouse records what actually arrived, including condition and discrepancies. A damaged item should not become sellable stock merely because the return was received. Separate items awaiting inspection, items available for resale and items requiring another disposition.
In a hypothetical example, a customer requests a return of five units, but the parcel contains four usable units and one damaged unit. The quantity received is five; the quantity ready for resale is four. Finance still needs the agreed commercial resolution before deciding the credit amount.
Reconcile three records
| Record | Question it answers |
|---|---|
| Return receipt | What physically arrived, and when? |
| Credit note | What customer balance is adjusted? |
| Refund or allocation | How was the credit settled or used? |
Zoho Inventory documents return processing and credit notes as related actions. Your implementation should verify the stock effects of each action so that an integration does not adjust the same quantity twice.
Test the awkward cases
Include a partially paid invoice, a replacement rather than a refund, a return from a different warehouse and a duplicate message from the storefront. Use the source return ID to recognise repeated integration events. Keep failed financial updates visible for review instead of marking the whole return complete.
Accounting and tax treatment depend on the transaction and applicable requirements; finance should approve the posting rules. This article concerns the operational evidence linking those decisions, not a universal tax treatment.
Close the return only when the physical and financial outcomes are recorded, or when a named owner has accepted a clearly documented remaining action. A weekly queue of received-but-unresolved returns is more actionable than a total return count alone.
Further reading
Primary reference. The workflow examples above are illustrative implementation guidance, not customer results.
Explore the related Dood resource. To discuss your workflow, contact Dood System.