Refund Policy Compliance Checker

A refund policy compliance checker is an LLM-assisted review step that sits between a return request and any money movement. It reads the request, the applicable refund policy, the shopper’s purchase history, warranty terms, marketplace rules where the order originated, and documented exceptions. It then produces a structured compliance assessment: whether the request appears eligible, which clauses support or block approval, and what open questions remain.

The model does not issue refunds. Staff (or a controlled settlement system they operate) still authorize payment. The checker’s job is to flag compliance clearly enough that a returns agent can act without re-reading the full policy on every ticket.

This page is for practitioners who already run returns operations and want a consistent, auditable policy check before refunds leave the ledger. It pairs with disposition and fraud workflows rather than replacing them. See Automated Return Disposition, Return Fraud Risk Scoring, and Return Reason Classification for adjacent steps in the same stage.

The checker should refuse to produce a compliance verdict when required inputs are missing. Empty output is the correct behavior when the refund request, the policy text (or structured policy record), or purchase history cannot be retrieved. Guessing from partial context creates false approvals and hard-to-defend denials.

Minimum inputs typically include:

• The refund or return request: order identifiers, claimed reason, requested remedy (full refund, partial, store credit), and any shopper-provided notes or photos referenced by policy.
• The active refund policy for that channel and region, including windows, restocking rules, non-returnable categories, and exception paths (damaged goods, wrong item, goodwill).
• Purchase history for the order line: purchase date, fulfillment date, price paid, promotions or gift cards applied, and prior returns on the same order or SKU when policy depends on them.
• Warranty rules when the claim is framed as defect or failure rather than buyer’s remorse.
• Marketplace or platform requirements when the sale ran through a third-party channel with its own refund SLAs or evidence standards.

Optional but useful inputs include agent notes from prior contacts, serialized product registration, and known policy overrides already approved by a supervisor. Those enrich the review; they do not replace the three required sources above.

If any required source is unavailable, the system returns no compliance decision and surfaces which input failed. Downstream automation must treat that as “do not refund” until the gap is filled, not as silent approval.

Once inputs are present, the model maps the request to policy clauses rather than summarizing the policy in prose alone. A useful output names the governing rule, states whether the request meets it, and cites the facts from purchase history that drive the conclusion (for example, days since delivery versus the stated window, or category exclusions that apply to the SKU).

The review should cover common decision dimensions in a fixed order so agents learn the pattern:

1. Eligibility window and clock start (purchase, ship, or delivery).
2. Product and category restrictions, including hygiene, digital, and final-sale items.
3. Condition and evidence requirements when policy demands proof of defect or non-receipt.
4. Remedy type allowed (refund vs exchange vs credit) and any restocking or shipping deductions.
5. Warranty versus returns policy: which instrument applies and whether both can apply.
6. Marketplace overlays when platform rules tighten or extend retailer policy.
7. Documented exceptions: published goodwill rules, VIP programs, or prior written commitments on the case.

Warranty and marketplace layers often conflict with the base returns page. The checker should call out conflicts explicitly (for example, a marketplace that requires a longer window than the storefront policy) and recommend the stricter or contractually controlling rule according to your operating handbook, without inventing a new policy.

Exceptions belong in the same structured pass. If an exception exists only as tribal knowledge and is not in the policy corpus, the model should not invent one. It should flag that the request falls outside written policy and needs a human exception decision.

The checker may also note consistency with the stated return reason when classification is available from Return Reason Classification. Reason labels help choose the right clause; they do not by themselves authorize payment.

The compliance result is a recommendation package for a returns agent or supervisor:

• Compliant as requested: policy and purchase facts support the asked remedy; staff may proceed to issue the refund through the normal payment path.
• Compliant with a different remedy: exchange or credit fits; full cash refund does not. Staff explain and settle accordingly.
• Not compliant: cite the blocking clauses and missing evidence. Staff deny or request more information without implying the model “rejected” the customer in a legal sense; the company decision remains human.
• Incomplete: empty or partial output because inputs were missing; staff gather data and re-run before any settlement.

Human-in-the-loop means the model flags compliance; staff still issue the refund. Keep settlement actions (payment gateway credits, marketplace refund APIs, gift-card issuance) behind roles and systems that agents control. Do not wire the LLM output directly to an auto-refund.

Logging should store the policy version, order snapshot identifiers, model assessment, and the agent’s final action. That trail matters for marketplace disputes, chargebacks, and internal QA. Pair fraud signals from Return Fraud Risk Scoring with compliance: a request can be policy-eligible and still high risk, or low risk and still out of policy. Those are separate axes.

Disposition of the physical return (restock, scrap, vendor return) remains a separate decision, covered in Automated Return Disposition. Compliance answers “may we refund under policy?” Disposition answers “what happens to the unit?” Running them in the wrong order creates refunds on units you cannot resell or denials when policy already required a refund after inspection.

Treat empty output as a first-class state. Triggers include missing request payload, unreachable or stale policy documents, incomplete purchase history (partial OMS sync, split shipments without line dates), or ambiguous order identity across marketplace and retailer IDs. The UI should show “assessment unavailable” with the missing field list, never a soft “likely OK.”

Other failure modes to design for:

• Policy drift: storefront copy updated while the model still reads an old snapshot. Pin policy version IDs in the prompt context and refresh on publish.
• Overlapping clocks: delivery confirmation delayed; the model should state uncertainty rather than assume the window closed or opened.
• Partial refunds and promotions: paid price after coupons, loyalty burn, or split tenders must come from purchase history, not list price.
• Multi-item orders: assess line by line; do not approve a whole-order refund because one line is eligible.
• Channel mismatch: applying website policy to a marketplace order, or the reverse, without the overlay rules.

Guardrails worth enforcing in product and process:

• No auto-refund from model output alone.
• No compliance verdict without request, policy, and purchase history.
• No silent defaults that treat missing warranty or marketplace data as “not applicable” when the claim type requires them; require those inputs or return empty for that branch.
• Agents can override with a recorded reason; overrides feed QA and, when repeated, policy updates.

Measured success for this use case is fewer inconsistent refund decisions, faster agent handle time on routine policy lookups, and clearer audit trails, not higher refund volume. Volume targets belong to commercial policy, not to the checker.

In a typical retail return flow, reason classification and fraud scoring may run early to route the case. Disposition may wait on inspection. The refund policy compliance checker belongs at the money decision: after you know what was requested and what the order was, and before settlement.

Use it as a repeatable quality control on refunds so agents apply the same clauses the same way, while keeping issuance and exceptions in human hands. When inputs are incomplete, produce nothing and wait. When inputs are complete, flag compliance with cited rules, then let staff issue, adjust, or deny the refund.