Retail Return and Exchange Software
HisabLekha connects retail returns and exchanges to the original sale, returned variant, replacement stock, payment difference, customer ledger, and participating branch. Eligible positive return-credit payments can be allocated FIFO to older same-shop completed-sale dues, while tax treatment and credit-note decisions remain with the retailer’s accountant.
Feature showcase · settlement preview
From return credit to a cleaner customer due
This is the documented production boundary for a positive return-credit payment: same-customer, same-shop, older completed-sale dues are considered in FIFO order, while cash-refund returns remain separate.
Record the source return
Start from the original sale and record a positive return-credit payment for the returned item.
Find the same-shop dues
The supported allocator looks for older completed-sale dues for the same customer and shop.
Apply credit FIFO
Eligible credit is applied oldest-due first, bounded by the return's effective time and the amount available.
Review what remains
Review the amount applied and any remaining return credit; cash-refund returns stay outside this automatic allocation.
Settlement preview
The return result should make the applied amount and remaining credit reviewable by the counter team.
- Source return
- Same-shop dues
- FIFO allocation
- Remaining credit
Workflow preview based on the live production capability, not a fabricated product screenshot. Confirm the source invoice, customer, shop, return policy, and accountant-approved tax or credit-note path in a demo.
Feature preview · Sales History
See an exchange visit in one card
The latest exchange-history implementation is designed to give the shopkeeper one Sales History card for an exchange visit: the returned items, the new items, and reconciled branch context, shown only when the visit balances.
Summarise the visit
Show one summary of the exchange visit for the current shop instead of making the shopkeeper reconstruct it from several bills.
Keep the exchange story visible
Keep the returned items and the new items together so the card explains the visit in the same order the counter team thinks about it.
Separate other-shop context
When a participating branch also contributed to the visit, show the reconciled all-shop totals without repeating the current shop's rupees twice.
Fall back when facts do not reconcile
Show the summary card only when the exchange visit balances; otherwise keep the existing Sales History card rather than a summary that does not reconcile.
Verification boundary
The card is only for a reconciled exchange visit. Confirm that the latest app and database deployment is enabled for your shop.
- Visit summary
- Returned + new
- Other-shop context
- Reconciled result
Preview based on the latest committed exchange-history workflow, not a fabricated customer screenshot. Older or inconsistent deployments should keep the existing history card.
Recent product workflows
New return and settlement workflow details
The return workflow keeps the source invoice, customer, shop, payment, and due record connected.
Return credit can settle older same-shop dues
For a positive return-credit payment, current production can allocate credit FIFO to older completed-sale dues for the same customer and shop. Cash-refund returns are excluded, and any remaining amount stays as return credit for review.
See the return-credit workflowExchange-visit cards in Sales History
The latest exchange-history implementation summarises the returned items, the new items, and reconciled all-shop context for a visit that balances. It keeps the existing card when a visit cannot be reconciled.
Preview exchange-history trackingWhat does HisabLekha handle for this shop type?
A return is not complete when the cashier takes back a garment or shoe. The original sale, returned variant, replacement variant, stock movement, payment difference, customer balance, and branch need one traceable exchange story. The latest exchange-history implementation can also surface a Sales History visit card for an exchange visit that balances, keeping other-shop context separate. For a positive return-credit payment, current production can also allocate credit FIFO to older completed-sale dues for the same customer and shop; cash-refund and tax-treatment decisions remain separate and subject to the retailer’s policy and accountant.
Find the source invoice and record the returned variant, quantity, reason, and stock movement together.
Select the replacement size, colour, or footwear variant and calculate any payment difference before settlement.
For a positive return-credit payment, automatically apply credit FIFO to older completed-sale dues for the same customer and shop; cash refunds remain separate.
Keep due, advance, refund, and customer ledger effects tied to the return or exchange instead of correcting them later.
Support branch exchange cases where a participating shop accepts the return and another branch supplies the replacement (cross-shop returns depend on your plan; check the pricing page).
For the latest exchange workflow, a Sales History visit card summarises an exchange visit that balances, with the returned items, the new items, and reconciled all-shop context; otherwise the existing history card stays.
Give the accountant the original sale and return context needed to decide the applicable GST or credit-note treatment.
How do return and exchange cases stay traceable?
A return or exchange needs the source sale, physical variant, replacement, payment difference, customer due, and shop boundary to stay connected.
| Return case | Recorded context | Settlement workflow |
|---|---|---|
| Apparel return | Original size-colour variant | Source invoice, stock movement, and ledger update |
| Footwear size exchange | Returned shoe size + replacement size | Variant stock and payment difference |
| Boutique or fabric case | Piece or roll/metre item | Physical inspection, return flow, and any separate stock correction |
| Multi-branch exchange | Return shop + replacement shop | Cross-shop settlement and separate GST context |
Where should a retailer verify return-credit fit first?
- Returns and exchanges depend on the configured shop policy, source invoice, physical inspection, and participating branch; the page does not promise every retailer’s policy automatically.
- Automatic due allocation is limited to a positive return-credit payment for the same customer and shop's older completed-sale dues; cash-refund returns remain outside that allocation and any remaining credit should be reviewed.
- GST refund, credit-note, damaged-stock, and tax-period treatment must be checked by the retailer’s accountant and current law.
- The exchange-visit card requires the latest app and database deployment and appears only when the exchange visit reconciles; older or inconsistent deployments keep the existing Sales History card.
FAQ
Frequently asked questions about Retail Return and Exchange Software
Can a customer exchange a shirt, pant, or shoe size?
Can returns work across branches?
Does the software decide GST credit-note treatment?
What happens to the returned stock?
Can an exchange include a payment difference?
Can return credit be applied to older customer dues?
Are cash-refund returns automatically allocated to customer dues?
Can Sales History summarise an exchange visit?
Related fashion-retail workflows
Explore another documented workflow that may fit the next stock, shop, or channel question.
See the return-credit workflow in action
Create a supported return-credit case, inspect the same-shop older dues considered for FIFO allocation, review any remaining credit, and confirm the accountant-approved tax or credit-note path with your team.
No credit card · Cancel anytime · Test your workflow first
HisabLekha Technologies Private Limited · Made in India · support@hisablekha.com