Back to Glossary

Entry · KPIs

Customer Refund Approval Aging

Customer refund approval aging is the elapsed time each qualifying open refund request has spent awaiting an authorized approve or decline decision, measured from a declared start to a report timestamp or final decision. It measures decision backlog, not refund payout time.

State eligibility, start, clock, incomplete cases, partial decisions and open age buckets.

From the Money Master HQ dictionary, founded by Shihan Sheriff (FCMA, VP of Finance at Nomod, CFO at Esanjo Ventures). How these definitions are written.

What it means

A customer asks for a refund after returning an item or cancelling a service, and the support team records the request, but finance has not decided whether it qualifies. Customer refund approval aging measures how long open, decision-ready or pending refund requests have waited for an authorised approval decision.

Define the request carefully, because a customer email, return authorisation and finance case can occur on different dates. Define the start by choosing either receipt of a complete eligible request or the initial request, and show incomplete cases separately if using the first.

Set the end at the timestamp of the final authorised approve or decline decision, not the later payment settlement. Oracle NetSuite describes return authorisation approval before receiving, crediting or refunding under its workflow, and Stripe distinguishes refund processing statuses such as pending and succeeded; these are product examples, and approval age is not money-transit time.

Choose the unit, because a request may contain several returned lines, and define case or line counting. Verify the customer by matching order, payer and authorised claimant before any financial decision or disclosure, and check policy, since contract, return terms, payment method and applicable law can determine eligibility.

Record evidence such as purchase proof, return condition, cancellation time and reason, and do not treat requests as approved, because a support acknowledgement is neither finance approval nor proof that money moved. Track status, because awaiting customer evidence, warehouse inspection, fraud review and approver action are different bottlenecks with different owners.

Show open age rather than only an average of decided requests, which ignores old cases still awaiting review, and use age buckets that present counts and amounts by elapsed calendar or business day ranges, labelled clearly. Track amount as well, as one high-value delayed request may outweigh many small ones in customer and cash terms.

Some jurisdictions impose refund deadlines, so check the transaction's specific law before asserting one. Handle partial refunds by preserving the contested remainder and the rule for closing the case, link duplicates when a customer contacts support twice about the same order, and keep a rejected request's authorised basis and clear internal record rather than a generic no.

A decision changed after new evidence should remain in the audit history with its effective time. Separate execution, because after approval, refund initiation and final receipt are further stages that need different measures; if a processor rejects a refund after approval, the approval-age clock may be closed but an execution case remains open.

Guard against speed bias, since approving weak claims solely to improve the metric can harm the business, and offer an alternative evidence route where a customer cannot reasonably provide what is requested. Keep any customer promise, such as a reply by Friday, in the case, give every complete request a named reviewer so it cannot age silently, and break out requests past the promised response date even when the median age looks healthy.

In practice

Real-world examples.

1

Example

A complete refund request arrives on Monday and remains under review on Thursday, so its open age is three calendar days. The report shows it in the 3 to 5 day bucket with its owner and its current status. The customer-facing team can see it before the promised reply date passes.

2

Example

A returned laptop needs warehouse inspection before finance decides on a $900 refund. The case stays visible in the open queue with the waiting reason recorded as inspection. Managers can see that the delay sits in the warehouse and not with the approver.

3

Example

An approved refund encounters a processor failure. The approval-age clock ends at the approval timestamp, but a separate payment-execution case stays open until the money is sent. The team therefore does not mistake an approved decision for a completed payment.

Formula

Calculation

Open age = Report timestamp - Declared request start, for each unresolved decision Closed decision time = Final decision timestamp - Declared request start, calculated separately for decided cases Worked example. On a Friday report date a retailer has 40 open, complete refund requests with a combined value of $12,000. - 0 to 2 days: 22 requests, $4,400 - 3 to 5 days: 10 requests, $2,800 - 6 to 10 days: 6 requests, $3,000 - Over 10 days: 2 requests, $1,800 - Check: 22 + 10 + 6 + 2 = 40 requests and $4,400 + $2,800 + $3,000 + $1,800 = $12,000. - Share older than 5 days = (6 + 2) / 40 x 100 = 20% by count and ($3,000 + $1,800) / $12,000 x 100 = 40% by value. The value share is double the count share, so a handful of old, expensive cases deserve attention first even if the queue looks short.

Case study

Seen in the real world.

This entirely fictional case follows Pine Retail. Support marked a customer's refund request handled after acknowledging it, but the approval queue had no owner. A review found the open case before the promised reply time. The team assigned the reviewer and separated decision status from payment status. The dashboard until then reported only the average time for decided requests, which looked healthy at under two days.

When the team added open age buckets, it found 14 requests older than ten days that had never appeared in the average. Most of them were waiting for a reviewer who had left the team. The team then gave every complete request a named owner, set an alert for cases nearing the promised reply date, and reported open age by value as well as count. This example does not authorise a real refund or denial.

Watch out

Common mistakes.

  • Calling acknowledgement or return authorization final refund approval.
  • Hiding old open requests by reporting only decisions already completed.
  • Using approval as proof the payment actually reached the customer.

Questions

People also ask.

Does approval mean the refund has settled?

No. Processor initiation and customer receipt are separate stages.

Can missing documents pause the clock?

Only under a stated rule; still show the case and its pending reason.

What if only part is approved?

Keep approved, denied and unresolved amounts separate under the closure rule.

Was this explanation helpful?

From the founder's library

Accounting Fundamentals: A Non-Finance Manager's Guide to Finance and Accounting, by Shihan Sheriff

Take it further with the book.

Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.

US$2.24US$2.99

25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.

View the book and save 25%

Related

Keep reading.

Refund Processing TimeReturn AuthorizationRefund EligibilityRefund LiabilityCustomer Service Backlog
Last updated · October 8, 2026
Browse all terms →

Disclaimer

The information provided in this finance dictionary is for educational and informational purposes only. It should not be construed as financial, investment, legal, or tax advice. Always consult with a qualified professional before making any financial decisions. Money Master HQ makes no representations or warranties about the accuracy, completeness, or suitability of this information. Use of this content is at your own risk.