How to Control Customer Refunds Before Money Leaves

A refund is a payment going out of the business, so it carries the same risks as paying a supplier, plus a few of its own. It can go out twice, go to the wrong account, cover a sale that never happened, or repeat money the customer has already recovered through their bank or the payment gateway.

In a small shop or service business, one person often takes the customer's call, agrees the refund and makes the transfer. That is convenient, but no one else ever sees the decision. A short, written routine fixes this without slowing down genuine refunds.

Start every refund with a request record, whether it lives in your accounting software, a ticketing tool or a controlled register. Give each record a number, and do not pay anything without one.

• ✓Customer name and customer code, exactly as they appear in the customer master.
• ✓Original invoice or order number, its date and amount.
• ✓Original payment reference, payment method and the amount actually received.
• ✓Refund amount requested and whether it is full or partial.
• ✓Reason code from a fixed list, plus a short note in plain words.
• ✓Who raised the request and when, along with the customer's written request or other supporting evidence.
• ✓Status fields for approval, verification, payment reference and closure.

Keep the reason codes short and fixed so they can be counted later. A typical set might be: goods returned, service not delivered, pricing error, duplicate payment, overpayment, goodwill and chargeback-related. Steer clear of a catch-all "other" code. If you do keep one, have the owner review every use of it.

The approver should be someone other than the person who raised the request and someone other than the person who releases the payment. In a very small team the owner may be the only independent approver. That is acceptable, as long as the owner does not also raise and pay the same refund without a record.

Set a refund limit that suits your own business. Below it, a designated manager approves. Above it, the owner approves personally. No single figure fits every business, so base it on your typical sale value, your margins and how much you are willing to have pass through one person's hands. Record the limit in writing and review it from time to time. If you already use a payment approval matrix for suppliers, add refunds to the same matrix so the rules stay in one place.

Approval says the refund is reasonable. Verification proves the money is really owed. Before releasing payment, have the person preparing it confirm each of these points against your books and bank or gateway records.

1. The invoice or order exists, belongs to this customer and has not been cancelled already.
2. The payment was actually received and has settled into your bank, not only been shown as initiated.
3. The refund amount does not exceed the amount received, less anything already refunded or credited on that invoice.
4. The customer's account balance supports the refund. A customer who still owes you on other invoices may need an adjustment rather than cash, but only where they have agreed to it.
5. No chargeback, dispute or reversal is open or completed on the same payment.
6. Where goods were returned, the godown or store has confirmed they were received.

Paying back through the same card, gateway, UPI handle or bank account the money came from is the strongest single protection against fraud. A request to send the refund to a new bank account, a relative's account or a different UPI ID is a common way for money to be diverted.

If the original method genuinely cannot be used, for example because a card has been closed, treat the new destination like a vendor bank account change. Get a written request, confirm it through a contact you already hold on the customer master rather than the details in the request, and have the owner approve the exception. The same thinking appears in the guide on verifying a vendor bank account change.

Unidentified receipts deserve care too. Do not refund money just because someone claims it. First establish who paid and against what, using the routine in the guide on allocating unidentified customer receipts. For advances, the guide on tracking customer advances against invoices shows how to keep balances clear.

Once a month, list every refund paid with its reason code, approver, amount and payment reference. Match the list to bank and gateway debits, and confirm each refund is closed in the customer ledger. Look for patterns: one customer with repeated refunds, one staff member raising an unusual share of them, frequent goodwill codes, or refunds approved just under the limit.

Make this review part of your month-end close checklist and your receivables collection routine, so refunds and customer balances are read together.

• Paying a refund from an email or phone call with no request record.
• Letting the same person request, approve and pay the refund.
• Refunding against an order that was never paid or has not yet settled.
• Sending money to a new account at the customer's request without independent confirmation.
• Refunding while a chargeback on the same payment is still open.
• Approving part-refunds one at a time without checking the running total on the invoice.
• Recording refunds without reason codes, which makes later review impossible.

This routine covers the payment control only. It does not cover how credit notes or refunds are reported for GST or treated in your accounts. Those questions are covered separately in our guide on reporting a GST credit note for a customer refund, and should be confirmed with your chartered accountant. Businesses with high-volume online refunds handled automatically by a marketplace or gateway will need to adapt these steps to the controls the platform provides.