Link refund review to return receipt without making them the same decision

A return authorisation expects a three-item bundle, but the warehouse receives two items. Finance sees the original order total and a request for a partial refund. An earlier refund has already been processed against the same payment.

Build a line-level reconciliation before sending another payment instruction. Receiving provides evidence about the goods; the applicable customer terms and authorised commercial decision determine entitlement. The workflow must also account for money already refunded or still in flight.

Start with the financial and physical references

Link the original order, invoice or sale record, payment, return authorisation, return receipt and proposed refund. Preserve the item and quantity allocation for each relationship. A parcel identifier alone cannot explain a bundle refund.

Microsoft's sales-return documentation separates physical-return and credit-only processes. A credit can be authorised without physical return in an appropriate configured process, so a receipt requirement must not be assumed universally. Microsoft Dynamics 365 — Sales returns

Likewise, stock disposition and customer entitlement may differ. A product that cannot be resold can still qualify for a refund; a physically received item may require an identity investigation. The warehouse should report facts without making an unauthorised financial decision.

Reconcile a discounted bundle

This illustrative order contains three components priced at ₹1,000, ₹600 and ₹400 before a ₹200 bundle discount. The approved sale allocation assigns that discount proportionally: ₹100, ₹60 and ₹40. Taxes, delivery fees and other adjustments are excluded from this teaching example.

Total net paid value is ₹1,800. Under this fictional case's approved partial-refund decision, A and B support ₹900 + ₹540 = ₹1,440. The ₹360 for C remains a separately owned decision. It is not automatically denied merely because the parcel is short; the reviewer must consider the applicable policy and evidence.

If ₹500 has already been confirmed refunded against this same approved entitlement, only ₹940 remains to be instructed. Sending another ₹1,440 would over-refund the approved amount by ₹500.

Do not recalculate the discount using today's prices or a different promotion rule. Preserve the original allocation or obtain finance's approved method where it was not stored. Tax and other applicable adjustments need their own correct treatment in the real transaction.

Keep the request and the money apart

For the remaining ₹940, record the refund approval reference, payment reference, currency, amount, destination provider, operation identity and current outcome. The approval does not itself move money.

A provider response needs its precise meaning. Razorpay documents that a refund can reach its processed state before the gateway ARN/RRN is received, depending on account configuration. Do not translate a provider status into a stronger claim about customer receipt than the evidence supports. Razorpay — Refunds

The operating view can show ₹500 confirmed under the chosen reconciliation evidence, ₹940 submitted and awaiting final reconciliation, and ₹360 under separate entitlement review. Those categories must not be added as though all are completed refunds.

If the customer reports non-receipt, retain the refund and payment references and route the case through the provider's current tracing process. Do not issue a second refund solely because a dashboard status is unclear.

Design the exception queue around the decision

A credit note, a replacement order and a cash refund are different outputs. Link them so the same concession is not unintentionally granted twice. Some approved remedies legitimately combine them; the record should make that deliberate.

Make retries safe

Use the provider's supported idempotency or duplicate-prevention mechanism and retain a stable operation reference. Persist the approved instruction and its outgoing request so a timeout can be investigated.

If the provider accepted the request but the acknowledgement was lost, query the existing refund before resubmitting. A new request identity can defeat duplicate protection. If the amount changes, treat it as a new authorised adjustment after resolving the earlier request, rather than mutating an in-flight instruction.

Restrict actions to the relevant order, customer and payment. OWASP's object-level authorisation guidance applies when refund services accept identifiers supplied by a caller. OWASP — Broken Object Level Authorization

The person resolving a warehouse count should not automatically gain authority to send a payment. Permissions should reflect the actual division of responsibility.

Compare the workflow options

A controlled reconciliation sheet can work when refund volume is modest and the payment system remains the authority for transactions. It must include pending requests, not only completed ones.

A native order or returns system can prepare line-level recommendations if it retains net paid values and prior remedies. An integration should pass an approved amount and stable references to the payment process, then reconcile the provider outcome back to the same case.

Test partial bundles, prior refunds, a credit-only remedy, duplicate receipt messages and an uncertain provider response. Include a correction after approval but before submission. The correct output may be a held proposal with a named reviewer.

Measure approved amounts, submitted amounts and reconciled outcomes separately, together with unresolved age and erroneous instructions. A short refund cycle time does not compensate for paying the wrong amount.

Reconcile entitlement before execution and execution afterwards

The useful control joins physical evidence to a financial decision without making them identical. It then follows the authorised payment instruction until its outcome is understood.

Next actions

1. Map return components to original net paid values and prior remedies.
2. Record the authorised entitlement separately from stock disposition.
3. Test pending and uncertain refund requests before enabling retries.
4. Reconcile each approved amount to an owned hold or a known provider outcome.

A refund-workflow review should begin with one partial bundle and every financial action already linked to its payment.