Refunds

The admin refund queue, the approval workflow, partial refunds, and what happens to your stock and receipts once a refund completes.

Go to Returns & refunds in the left navigation (on the new admin the page masthead reads returns & refunds.). This is the queue and ledger for every refund request on your store, whether it started from an order cancellation, a customer return, or an item that arrived damaged.

Returns versus refunds

A return is the parcel coming back; a refund is the money going out. They are two separate screens, because a return can be rejected, or can finish with no money to give back, and a refund can start without any parcel travelling at all (a cancellation, for example).

The Returns screen (new admin)

Open Orders → Returns. The page opens with a returns. masthead and the line "Customer return requests: approve or reject each one, then follow it through pickup and refund." Beside the title is a View refunds link that jumps to the Returns & refunds screen. Below it, a Customer Return Requests list shows every return on your store. It is the same list that appears under Shipment → Return Requests, so an action taken in one place shows in the other.

What each column shows

A return that finished on an order with no paid money on record shows the state Closed - no refund and a refund amount of zero, rather than Refunded.

Filter the list. Use Filter by status at the top right: All (the default), Requested, Approved, Rejected, Picked Up, In Transit, Delivered Back, Refund Pending, Refunded or Cancelled. Changing the filter returns you to the first page. The list shows 20 requests per page; the arrows under the table move between pages and the line between them shows the range, such as "1–20 of 47".

The confirm button reads Processing… while the action is saved, then the list reloads. If the action cannot be saved, the dialog stays open with the error message at the top.

The refund queue

The Returns & refunds screen opens on a queue of requests, each showing the order, customer, requested amount, status, and reason. At the top you'll find:

• Pending — requests waiting on your decision.
• Approved today — how many you've processed today.
• Total refunded — running total for the period shown.
• Decline rate — the share of requests you've rejected.

You can filter by status (All, Pending, Approved, Declined, Completed), filter by reason, sort the list, and search the queue.

Find a refund request

1. Open Returns & refunds in the left navigation.
2. Type in the search box above the list (placeholder Search by order ID or customer…). The list updates as you type and returns to the first page.
3. Optionally narrow it with the status tabs, reason, or method filters. Search and filters combine.
4. To start over, clear the box, or use Clear filters on the "no matches" screen.

The search runs on the server across every refund request in your store, not just the page on screen, and it matches:

The three tiles on the new admin Returns & refunds screen

On the new (v2) admin panel the summary strip has three tiles. Each states its own scope in the caption underneath:

Where the customer asked for the money

When the customer filed the return themselves (see Requesting a return), the refund detail shows Customer requested refund to with either Original payment method or Store credit. It appears in the classic refund dialog and in the newer skin's refund drawer. The line is left out when the request carries no choice, such as a refund you created yourself or one made automatically. It records the customer's request; use it when you decide how to settle the refund.

When the customer has already chosen a destination, the refund's own method line is hidden in that detail view, so the same question is not shown twice: Preferred Method in the classic dialog and Refund method in the newer skin's drawer. Those lines still appear for refunds with no customer choice.

Acting on several requests at once (newer dashboard skin)

On the newer dashboard skin, pending rows also have a checkbox. Tick more than one and a bulk action bar appears at the bottom of the screen with three actions: Export (downloads just the selected requests), Decline, and Approve — letting you clear out a batch of pending requests in one pass instead of working through them one at a time. Only pending rows can be selected; approved, declined, and completed requests don't show a checkbox.

Refund intelligence (newer dashboard skin)

Above the queue, an advisory panel compares your refund rate against a category-average benchmark, and breaks down your most common refund reason and what share of requests it makes up. This is informational only — it doesn't change how requests are processed — and is meant to help you spot whether refunds are trending unusually high before it becomes a bigger problem.

Refund risk signals (newer dashboard skin)

A separate, collapsible panel surfaces advisory warnings worth a second look, such as a specific customer who has filed several refund requests recently, or your refund rate running above the category average. Each signal has Review and Hide actions. Like the intelligence panel above, these are advisory nudges — nothing is blocked or auto-actioned based on them.

The refund approval workflow

Every refund request follows the same status path:

Pending → Approved → Processing → Completed
   ↓
Rejected

Partial refunds

You are not required to refund the full requested amount. When approving a request, you can lower the approved amount below what the customer requested — for example, to deduct a restocking fee or because only some of the items were returned. The approved amount can never exceed the requested amount, and BillionBiz records your reason alongside the adjustment so the customer sees a clear breakdown of original versus approved amount.

Start a partial refund from an order

When starting a refund from an order, select the purchased lines you want to refund. Bundle components use their allocated net price after coupon discounts. The amount follows your selection, and you can enter a lower amount for a partial refund. You cannot submit more than the maximum shown. The platform also checks earlier refunds, returns, and payments; if these reduce the remaining amount, the drawer shows the reason so you can review it and lower the request.

The maximum shown is based on the selected lines' purchased net amounts, bounded by the order's net amount. It is not a live statement of all earlier refund and return history. The server checks the remaining balance again, including pending requests and payments already received. On a partially paid order, you cannot refund money that has not been received.

Why can't I refund more on this line?

Admin refunds and customer returns use one shared balance for the order and its purchased lines. Earlier refunds and return reservations reduce what is left, even when they started through a different screen. Refunding another item, changing the request route, or entering the regular pre-bundle price cannot increase a selected line's entitlement.

If a selected purchased line's identifier is unavailable, submission is blocked. Reload the order before retrying; if it persists, ask support to check the order record.

Inventory restoration on refund

When a refund reaches Completed, the platform automatically adds the refunded item quantities back into your stock — you don't need to make a manual stock adjustment. This runs per line item, so a partial refund only restores the items that were actually part of that refund. If the stock update itself fails for some reason, the refund still completes; the discrepancy is caught by your normal inventory reconciliation rather than blocking the customer's money from moving.

Refund status tracking

Every refund carries its own status independent of the order it belongs to, so you can track it even after the order itself shows Cancelled or Returned. The order's payment record also updates to show a partial refund or full refund state once money has moved.

When a refund shows Failed

A Failed refund means Razorpay rejected the reversal — no money moved, and the customer has not been paid back. The reason is written into the refund's notes and into the Auto-Refund Failed notification in your admin notifications.

Retry the same refund rather than creating a second one: open it in the refund queue and approve it again. A Failed refund is allowed to go back to Approved, and re-approving reuses the same refund record, so there is no risk of the customer being paid twice.

Common reasons, and what to do about each:

Credit notes

The moment a refund reaches Completed, BillionBiz automatically generates a credit note — no action needed from you. A credit note also gets generated the same way when a paid, invoiced order is cancelled — the cancellation cascade refunds the payment and issues a full credit note in one step, covered in Cancelling an order. And you can trigger one directly, without a refund, from an order's Invoice ▾ → Cancel & reissue menu — see Cancelling and reissuing an invoice — for correcting an invoice on its own, such as a data-entry mistake. Whichever path creates it, a credit note is:

• Immutable — once created, nothing about it (amount, GST split, or number) is ever edited.
• Sequentially numbered, using the same financial-year-scoped numbering as your invoices, with a CN marker so it's clearly distinguishable from an invoice number.
• Emailed automatically to the customer with the credit-note PDF attached.

On the order detail screen, a refund-triggered credit note's number appears on the Refund node of the order timeline once it's been generated — see The order timeline — and any credit note (refund- or cancellation-triggered) also shows on the Invoice & GST card. On the customer's own side, once it's ready, a credit note tied to a refund shows on their order page under that refund with its own Download link — see Payment & invoice.

Refunds created at the POS counter

Returns taken at a Point of Sale counter follow their own flow on the counter screen, and the server quotes the refund amount rather than letting the cashier type it. A cashier's refund limit is ₹0: a cashier's refund above zero, and any whole-bill void, needs the owner's approval, by Owner PIN or Ask owner remotely; an owner signed in with the admin sign-in is not asked. The owner reviews requests at /settings/pos/approvals. See Returns & Exchanges.

An item the cashier added by scanning an unknown barcode can be returned once at the counter, up to the quantity sold; a second return of the same line is refused. See Returns & Exchanges.

Late terminal cancellation after a paid bill

Screen: as the owner, open /orders/pos-history, select Counter when offered, then Open on the original bill. Review Settlement needs owner review and its reason. A terminal may honour a cancellation after the bill has finished; this does not automatically rewrite the bill's money or perform a second refund. Refunds against the flagged terminal receipt are blocked while its settlement needs review.

1. Keep the bill and terminal payment references. Ask the owner to check the actual terminal settlement before any further collection or refund.
2. If you visit /pos-payments, the owner can read Payment exceptions, use Open bill on an entry, Next page or First page, and Retry if the list fails to load. These controls read records; they do not resolve an exception or send money.
3. Reopen the original bill to check its current state. Do not switch refund methods or create another return merely to bypass the settlement warning.

Why can't I refund a receipt that still looks paid? A later honoured terminal cancellation can leave the original capture recorded while blocking another gateway refund. Read the owner's warning and retain the original references; neither a pending refund nor the unavailable settings control proves money was returned.

Next steps

• The Orders List & Order Lifecycle — where a refund request often starts.
• Order Detail: Status, Cancellation & Fulfilment Handoff — starting a refund from an order.