AI Returns and Exchange Calls: Window and Refund Errors

Figures from the National Retail Federation (NRF) are 2025 projections. Rules checked against primary sources in November 2026. This is not legal advice.

A caller says, "I want to send back the jacket. What do I get?" The agent answers, "You'll get $120 back in three to five days." The ledger says $103.68. The caller now holds a spoken promise that is $16.32 off, and a support ticket is coming.

This post is for teams that built the phone line inside an ecommerce or retail platform. You own the agent, and it runs across many merchants, each with its own policy. We cover AI returns exchange phone calls themselves: the window, amount, method, timing and the record written. Carrier-side returns after a failed delivery are a different problem, covered in missed delivery and return calls. Lookup and shipment status are covered in WISMO AI phone calls.

Why AI returns exchange phone calls break differently from order calls

An order-status call reads one fact: where the parcel is. A returns call has to combine five facts, and each lives in a different place.

1. Eligibility. Is this item returnable at all? Final-sale, hygiene and custom items are usually excluded.

2. Window. What date does the clock start on, and what date does it end?

3. Amount. What does the ledger refund after discounts, tax, shipping and fees?

4. Method. Original payment, store credit or exchange?

5. Timing. When does the money move, and when does the caller see it?

A language model can state all five fluently from a policy paragraph in the prompt. That is the trap. The prompt says "30-day returns, refund to original payment." The model fills in the rest with guesses, and each one sounds confident on the phone.

NRF and Happy Returns projected $849.9 billion in US returns for 2025. That is a 15.8% return rate, and 19.3% online. Retailers expect about 17% of winter holiday sales to come back. Your agent hears these calls in clusters, when the policy is most complicated.

The refund amount is the sentence most likely to be wrong

Callers anchor on the number they remember. That is usually the list price, the sale price on the banner, or the total on the card statement. The ledger refunds something else.

Here is a worked example. All numbers are illustrative, not from a real merchant.

A caller might expect $120.00, $111.68 or $103.68. Only one is in the ledger. The restocking line adds a fourth outcome that only a policy engine can compute.

The rule is simple. The agent may say a refund amount only when it is a field returned by the system of record for this return. It may not compute one, round one, or say "about" and then a number.

Two cases need extra care.

Partial return of a bundle. A set sold for $150 may list three items at $70, $50 and $60. If the caller returns the $50 piece, an allocation rule decides the refund. Pro rata gives 50 ÷ 180 × $150 = $41.67. An agent that says "$50" is $8.33 high. A promotion that needed the full set can also change the allocation. The system has to return that rule. The agent cannot infer it.

Exchanges at a different price. An exchange is a return plus a new order, with new tax and sometimes new shipping. The first order's promo may have expired. If the agent says "even swap" and the ledger shows a $12 charge, the caller finds out from a card alert.

Window errors: the date, the start event and the clock

"You have 30 days" is incomplete. Thirty days from what, in which time zone, under which rule?

The holiday row is the one teams miss. Any holiday return window needs its own test. A holiday return window is usually keyed to the purchase date, not the call date. An agent that reasons "it is December, so holiday rules apply" extends a window the order never earned.

The delivered-date row is the second. The start event differs by merchant: purchase, ship or delivery. The record must carry it as a date, not a sentence. If the caller says "it arrived last week," the agent reads the system field and does not argue. Our delivery exception AI calls post covers delivered-but-not-received cases.

Time zones are the quiet one. Store the window end as a timestamp with a zone. Have the tool return a verdict ("open", "closes today", "closed") with the date, so the model never does date arithmetic.

Refund timing: what the agent can say and what it cannot

"You'll have it in three to five days" is the most common spoken promise. It is usually unfounded. The clock has three owners: the warehouse, your refund system and the card issuer.

Federal rules cover only part of this chain. For credit cards, Regulation Z has a provision for merchants who accept a return. Under 12 CFR 1026.12(e), a merchant that accepts a return to be credited to a card must send a credit statement to the card issuer within 7 business days. The issuer must then credit the account within 3 business days of receiving it. Those are the credit-card rules checked for this post. The equivalents for debit cards and other payment methods were not verified here, so the agent should not generalize.

Two things follow for the agent.

• The clock starts when the return is accepted, not when the label is printed or the caller phones. An agent that promises timing from the call date is wrong by design.
• Spoken timing comes from the merchant's policy field, with the trigger named: "once the warehouse receives it." Never from the model's idea of bank speed.

This is not legal advice. Your counsel should confirm which rules apply to your merchants and payment methods.

What the federal order rule does and does not cover

Teams often cite the FTC's Mail, Internet, or Telephone Order Merchandise Rule when they discuss refunds. Read its scope before you do. The FTC business guide says the rule applies to most goods ordered by mail, telephone, fax or the internet. Its refund requirements apply when an order is cancelled or cannot ship. The guide does not address returns of goods already delivered. The text of 16 CFR part 435 matches. Section 435.2(c) triggers a refund on cancellation before shipment, a decision not to ship, or an unmet shipping-delay option.

For a change-of-mind return of delivered goods, the window and fees come from the merchant's published policy and any state law. State statutes were not reviewed here. The FTC's page on online shopping tells shoppers to check the refund policy, return shipping costs, days allowed and restocking fees. Your agent must read the same fields.

One practical result: a caller cancelling before shipment is on a different path from one returning a delivered item. The agent must classify the call first. Mixing the two is a common silent error.

Where the return record breaks

The call is the front door to a workflow: capture the request, check eligibility, create the return authorization (RMA), issue a label, and write the refund or credit. Speech errors enter at capture. They corrupt later steps without any visible failure.

Most of these leave a clean-looking record, and the return label can ship with the wrong variant. The call ended politely. The ticket says "return created." No error was logged. That is why you test the write-back and not only the conversation.

A transcript-only check can miss the root cause, because the transcript is itself model output. The Careless Whisper study found roughly 1% of Whisper transcriptions contained whole hallucinated phrases absent from the audio. That covers one model and its test setting, not your stack. It still shows why a judge that reads only the transcript inherits its mistakes.

Fraud and abuse flags: route, do not accuse

NRF's figures say 9% of returns are fraudulent, and 45% of shoppers say bending the rules on a return is acceptable (NRF 2025 Retail Returns Landscape). Merchants will want risk control on the phone line. The agent is the wrong place to make a fraud decision.

A safer design follows.

• The tool returns a `route_to_human` flag from a rules engine. The agent does not infer it.
• The spoken line is neutral: "I can't complete that on this call. A team member will review it." No reason is given.
• Tests include a caller who pushes back or asks "why not?" The agent must hold the line and still write a clean handoff note.

Also test the reverse. A genuine caller with an unusual case must not be routed away because noise or an accent was misread as evasion. Return fraud is the merchant's rules engine's call, not the agent's.

The gate that decides whether the agent may speak a refund

The simplest control is a gate in code, not a longer prompt. The agent may speak a window, amount or timing only after a tool returns that value for this specific return.

When a gate fails, the agent says what it knows, names what it cannot confirm and offers a handoff. It must not fall back to the policy paragraph, because that is where a confident wrong sentence comes from. Our guides on testing knowledge grounding and function schema validation cover making tools return typed values the agent must quote.

How to test an AI returns and exchange line

Test AI returns exchange phone calls on the record and the spoken sentence together. A correct ledger with a wrong promise is still a failed call.

1. Define the return record. List every speakable field: `eligible`, `window_start_event`, `window_end_ts`, `window_verdict`, `refund_amount`, `refund_method`, `fee_amount`, `timing_text`, `route_to_human`. Anything else is off limits.

2. Write the policy as data. Window length, start event, final-sale categories, holiday rules, fee rules. Version it. A policy change is a test trigger, like a prompt change.

3. Seed fixture orders. Build one per case above: promo, taxed, bundle, final-sale item, holiday boundary, delayed delivery scan, exchange at a different price, store-credit-only item.

4. Add caller conditions. Vary accent, pace, interruptions and noise. Include number-heavy turns: "fifteen" against "fifty", "size ten". Our STT background noise guide shows how.

5. Assert on two things. First, the record created: line items, method, RMA status. Second, every money amount and date the agent spoke, compared with the ledger values.

6. Set pass bars. Amounts and dates need a 100% match in every scenario. Track the share of calls reaching a correct write-back. One wrong promised amount is a failure, not noise.

7. Re-run on every change. Prompt, policy, model and tool changes all run the same suite. See regression testing after model updates.

8. Feed production back. Calls where the refund the caller was told differs from the refund issued become new fixtures. See turning production failures into tests.

Here is a simplified check for step 5, as illustrative Python. Real transcripts need a normalizer for spoken numbers such as "one hundred three sixty-eight."

import re

MONEY = re.compile(r"\$\s?(\d{1,3}(?:,\d{3})*|\d+)(?:\.(\d{2}))?")

def spoken_amounts(agent_turns):
    """Return every dollar amount the agent spoke, as cents."""
    out = []
    for turn in agent_turns:
        for dollars, cents in MONEY.findall(turn):
            out.append(int(dollars.replace(",", "")) * 100 + int(cents or 0))
    return out

def check_refund_claim(agent_turns, ledger):
    """Every spoken amount must equal a ledger field. Otherwise fail."""
    allowed = {ledger["refund_cents"], ledger.get("fee_cents", 0)}
    bad = [a for a in spoken_amounts(agent_turns) if a not in allowed]
    return {"pass": not bad, "unsupported_amounts": bad}

Evalgent is built for this kind of voice agent testing. It generates scenarios from the agent's prompt and flows, including policies, hard constraints and coverage gaps. It calls the agent over phone, SIP or WebRTC with caller profiles that vary accent, pace, interruption level, response delay, background noise and language. You can define a custom metric such as "every spoken refund amount matches the system record" and run it on every call, with human review of verdicts. It judges from the audio, not only the transcript, so it can catch a figure the transcript got wrong.

Monitoring the live line

Pre-release tests cover the fixtures you thought of. Production brings the rest: three orders on one number, a stacked coupon nobody modelled, a payment method that behaves differently. Evalgent's production monitoring takes your call recordings, transcribes them, maps each call to a scenario and judges it. It flags policy failures, tool-call failures, PII leakage and latency spikes, with fix recommendations. For a returns line, the useful review queue is calls where the spoken amount, window or timing differs from what the tool returned.

Track three numbers weekly. First, the share of calls with a spoken amount that has no matching ledger field. Second, the share that ended in handoff because a gate failed. Third, follow-up contacts about the same return within 14 days, which catch broken promises your checks missed. The 14-day figure is a suggested starting point, not a benchmark.

Frequently asked questions

Can an AI agent process returns over the phone?

Yes, if the agent can create the return in your order system and read back what the system returned. The safe scope is to classify the request, check eligibility, create the authorization and trigger the return label. Amounts and deadlines come from tools. Anything unconfirmed goes to a human.

Does the return window start at purchase or delivery?

It depends on the merchant's policy. Some start at purchase, some at ship date and some at delivery. The agent must not guess. Store the start event and the end timestamp in the record, with a time zone, and have the tool return an open or closed verdict that the agent repeats.

How long does a refund take after a return?

The agent should say only what the merchant's policy field says, and should name the trigger, such as warehouse receipt. For credit cards, Regulation Z section 1026.12(e) gives a merchant 7 business days to send a credit statement and the issuer 3 business days to credit. Debit and wallets differ.

Should an AI agent quote a refund amount?

Only if the amount is a field returned for this specific return. Discounts, tax, shipping and fees make list-price recall wrong. The agent should never compute, round or estimate. If the field is missing, it should say it cannot confirm the amount on the call and offer a handoff.

What is the difference between a refund and store credit?

A refund goes back to the original payment method. Store credit stays with the merchant and may carry limits. The agent must record the caller's choice, not default to credit. Test callers who say "whatever is easiest", because that phrase is where the wrong method gets written.

How should the agent handle final sale items on a returns call?

Read the eligibility flag from the catalog or order line. If the item is final sale, say so plainly and offer the allowed options, such as an exchange if the policy has one. Do not promise exceptions. Exceptions belong to a person with authority and a record of the decision.

Do restocking fees come out of the refund?

If the merchant's policy charges one, the refund field already reflects it. In the worked example above, a 10% fee on a $96.00 item cuts the refund from $103.68 to $94.08. The agent should state the fee and the final amount from the system, not calculate them.

How do you test an AI returns line?

Seed fixture orders for each tricky case, call the agent with varied caller conditions, then compare two things: the record the call wrote and every amount and date the agent spoke. Run the suite on every prompt, policy or model change. Add misquoted production calls as new fixtures.

The bottom line

An AI returns line is only as accurate as the fields it is forced to read from the system of record. Test the sentence the agent speaks against the ledger on every change, because a polite call with a wrong promise still ends in a ticket.