All insights

AI Agents

AI agents for airline refunds: what pays out automatically, and what a human signs

A DOT refund clock starts the moment a refund is due, and a queue of people can't beat it at scale during a mass disruption. Refunds are deterministic enough for an agent to own end to end. Compensation isn't, because it turns on the extraordinary-circumstances call. Here's the line, the two data points that decide it, and the 2026 rules you're coding against.

AI agents for airline refunds: what pays out automatically, and what a human signs, article illustration

When a US flight is cancelled and the passenger declines a rebooking, a clock starts. The refund is due, and the airline has seven business days to return it to a credit card, or twenty calendar days to any other form of payment. Miss that window and the non-compliance is measured in days and passengers, not in a single complaint.

That clock is the whole reason to put an agent on refunds. A queue of people working cases one at a time cannot beat a seven-business-day service level across ten thousand disrupted bookings in a bad-weather week. The work is high-volume, time-boxed, and mostly identical case to case, which is the exact shape an agent is good at.

So here’s the line I’d draw before writing any of it. Refunds are deterministic and can be owned by the agent end to end. Compensation is not, because it turns on a legal judgment the agent should draft and a human should sign. Getting that split right is the difference between an agent that saves the airline a compliance headache and one that creates a liability.

This is the money side of a disruption. We covered the other side, re-accommodation and rebooking, separately, and it’s a different problem with different risk. Rebooking moves a passenger onto another seat. This moves money, and money is harder to take back.

Four things people call the same thing

Before automating anything, separate four obligations that get lumped together as “what the airline owes me.” They’re legally distinct, and the agent’s scope depends on the distinction.

What it isWho owes it
RefundThe fare back for travel you didn’t take, or a fee for a service not deliveredThe airline, by statute
CompensationA fixed penalty for the disruption itself, payable even if you still flyThe airline, EU261 only
CareMeals, hotel, and transport during the waitThe airline, regardless of cause
InsuranceA payout under a policy you boughtA private insurer, not the airline

An agent operating on the airline’s own obligations handles the first three. The fourth is a separate product with its own adjudication, which is why travel insurance claims are a different build with a different system of record. Conflate compensation with insurance and you’ll design an agent that either pays twice or denies something it owes.

Refunds: the part an agent can own

A refund is deterministic. The triggers are objective, the method is dictated by how the passenger paid, and the deadline is a fixed number of days. Nothing here needs judgment, which is exactly why it’s safe to automate.

Under the US DOT automatic-refund rule, a refund is due when a flight is cancelled, or significantly changed and the passenger declines the alternative. Significant means a departure or arrival shift of three or more hours domestic, or six or more hours international, a changed airport, an added connection, or a downgrade to a lower class than booked.

Bag fees are refundable too, when a checked bag isn’t delivered within twelve hours domestic, or fifteen to thirty hours international depending on flight length, once the passenger files a mishandled-baggage report.

A paid ancillary that wasn’t delivered, the broken wifi or the seat you didn’t get, is refundable on the same terms.

Two data points decide the whole refund, and neither of them is a judgment call:

  • The disruption trigger decides whether a refund is due. It’s an objective comparison against the thresholds above.
  • The form of payment decides how the refund is paid and how fast. It must go back to the original payment method, no vouchers unless the passenger chooses one, and the seven-business-day or twenty-calendar-day window depends on whether that method was a card.

That maps cleanly to an action. The eligibility screen is arithmetic against a maintained policy, not hard-coded numbers, so the thresholds can move without a deploy:

public with sharing class RefundEligibility {
    public class Request {
        @InvocableVariable(required=true) public String pnr;
        @InvocableVariable(required=true) public String disruptionType; // CANCELLED, DELAY, DOWNGRADE
        @InvocableVariable public Integer arrivalChangeMinutes;         // signed delta at arrival
        @InvocableVariable public Boolean isInternational;
    }
    public class Result {
        @InvocableVariable public Boolean refundDue;
        @InvocableVariable public String rationale;
    }

    @InvocableMethod(label='Screen DOT refund eligibility'
        description='Applies the objective DOT significant-change triggers. Screening only; a human gates the payment.')
    public static List<Result> screen(List<Request> reqs) {
        RefundPolicy p = RefundPolicy.current(); // thresholds read from a maintained record
        List<Result> out = new List<Result>();
        for (Request r : reqs) {
            Result res = new Result();
            Integer threshold = r.isInternational
                ? p.intlSignificantMinutes : p.domesticSignificantMinutes;
            if (r.disruptionType == 'CANCELLED') {
                res.refundDue = true;
                res.rationale = 'Flight cancelled; passenger declined rebooking.';
            } else if (r.disruptionType == 'DELAY' && r.arrivalChangeMinutes != null
                       && Math.abs(r.arrivalChangeMinutes) >= threshold) {
                res.refundDue = true;
                res.rationale = 'Arrival change of ' + r.arrivalChangeMinutes
                    + ' min meets the ' + threshold + '-min significant-change threshold.';
            } else {
                res.refundDue = false;
                res.rationale = 'Below the significant-change threshold; no automatic refund due.';
            }
            out.add(res);
        }
        return out;
    }
}

The thresholds and windows live in a policy record the agent reads, not in the code:

{
  "dot": {
    "domesticSignificantMinutes": 180,
    "intlSignificantMinutes": 360,
    "refundWindowCardBusinessDays": 7,
    "refundWindowOtherCalendarDays": 20
  },
  "eu261": {
    "delayCompensationMinutes": 180,
    "refundDays": 7,
    "compensationEUR": { "upTo1500km": 250, "upTo3500km": 400, "over3500km": 600 }
  }
}

EU261 fits the same shape on the refund side. On a cancellation, the passenger chooses reimbursement or re-routing, and a reimbursement is due within seven days. That’s a clean, time-boxed obligation an agent can execute.

The data lives in systems Salesforce doesn’t own

The reason a refund agent is a real integration project, not a prompt, is that the two load-bearing facts live outside Salesforce.

The form of payment sits in the reservation system and the payment record, in the PNR held by Amadeus Altéa, Sabre, or Navitaire, and in the payment ledger. It’s what tells the agent whether the seven-day card window or the twenty-day window applies, and where the money goes back to. The disruption trigger comes from the operational feeds: the cancellation and delay events, and the departure-control record of who flew.

Salesforce is not the system of record for any of that. An agent built here reads the PNR and writes the refund through governed APIs, usually MuleSoft in front of the PSS, and grounds its reasoning on a unified view assembled in Data 360 from the reservation, payment, baggage, and operational data.

Build it as if the CRM were the reservation system and you’ll issue refunds against itineraries the source of truth doesn’t agree with.

An event-triggered agent is the right shape here. The cancellation event wakes it, not a customer message, so the refund is moving before the passenger has joined the phone queue.

Compensation: where the agent drafts and a human signs

Compensation is a different animal, and the difference is one word in the regulation: extraordinary. EU261 pays a fixed penalty for the disruption, €250, €400, or €600 by distance, when a flight is cancelled or delayed three hours or more at arrival. But the airline owes nothing if it can show the cause was an extraordinary circumstance it couldn’t have avoided with all reasonable measures.

That defense is a legal judgment, not a lookup. The test from the Wallentin-Hermann case is two-part: the event has to be outside the normal exercise of running an airline, and beyond the carrier’s actual control.

A routine technical fault generally fails that test, and the airline pays. Severe weather or an air-traffic-control strike generally passes it, and the airline doesn’t. The same delay can be coded more than one way, and the coding decides the money.

So compensation is where the agent stops short of the decision. It can propose the amount by distance band, pull the disruption reason code, and draft the accept-or-deny with the rationale written out.

What it must not do is auto-deny on an extraordinary-circumstances call. A wrong one is a legal liability the airline wears, not a customer-service miss it apologizes for. Draft, then route to a human, on the human-in-the-loop discipline that decides in advance which calls need a person and what that person sees.

One thing that trips up teams building for both markets: the US has no EU261-style compensation. The DOT rule mandates refunds, not a penalty for the delay, and the one US cash-for-disruption rule, denied-boarding compensation for bumping, is a separate and older rule with its own formula. An agent that offers a US passenger EU-style delay compensation is inventing an entitlement.

The 2026 rules you’re coding against

Two regulatory clocks matter, and both moved in 2026, so read them as they stand today rather than from a 2024 article.

The US DOT rule is in effect. The one live carve-out is narrow. DOT is exercising enforcement discretion on refunds for renumbered flights, where a flight flies under a new number but the passenger is rebooked with no significant change. That pause runs through July 2027, while DOT reconsiders the definition of a “cancelled flight.” The three-hour and six-hour significant-change thresholds themselves are not paused. Build to them.

EU261 has a bigger change pending, and it’s easy to get wrong, because the early drafts leaked figures that didn’t survive. The reform adopted in July 2026 kept the three-hour trigger and the €250, €400, and €600 amounts. The 4-hour and 6-hour thresholds that circulated in 2025 were a negotiating position that was dropped, so anything quoting them as final is wrong.

What the reform adds is procedural: a duty to notify a compensable passenger proactively and electronically, a deadline to answer a claim, and a self-rerouting right. It enters into force around 2027, so today an EU-facing agent runs the current regime while you plan for the new duties.

The lesson in both is the same, and it’s why the thresholds sat in a policy record earlier and not in the Apex. Statutory numbers and definitions move, sometimes mid-year. An agent that reads its rules from a maintained source updates with a config change. One that hard-codes 180 minutes needs a deploy, a test cycle, and someone remembering it exists.

Never move money without a gate

The last principle is the one that keeps this safe. A refund and a compensation payment are close to irreversible, so every payment mutation and every write back to the PNR sits behind a control.

Screen and draft automatically. Issue a standard, in-policy refund within a confidence threshold, and gate anything outside it. Put fraud and duplicate-claim checks ahead of any payout, so the same disruption doesn’t pay twice.

Batch the mass-event decisions for a human to approve in bulk, rather than letting the agent fan out ten thousand irreversible payments on its own read of a volatile morning. It’s the same posture as any agent that touches money: the guardrails and approval flow are the product, not an add-on.

Where to start

Build the refund engine first. It’s the clear win: deterministic triggers, a payment method and deadline dictated by the data, and a compliance clock a human queue can’t beat. Read the thresholds and windows from a policy record so a rule change is a config edit. Ground the agent on a unified view of the reservation, payment, and disruption data, and write refunds through governed APIs, never pretending the CRM is the reservation system.

Leave compensation as draft-and-approve, with the extraordinary-circumstances call reserved for a person. Gate every payment and every PNR write behind a control, with fraud checks in front. Do that and the seven-business-day clock stops being the thing that makes you non-compliant in a bad week, and starts being a deadline the agent beats while a human spends judgment only where the law asks for it.

Understanding the basics

What’s the difference between a flight refund and flight compensation?

A refund returns the fare for travel you didn’t take, or a fee for a service the airline didn’t deliver. Compensation is a separate statutory penalty for the disruption itself, paid even if you still reach your destination on a later flight. Under EU261 compensation is €250, €400, or €600 by distance for long delays and cancellations, unless an extraordinary circumstance applies. The US mandates refunds but has no general delay-compensation rule.

Can an AI agent issue airline refunds automatically?

Yes, and refunds are the strongest case for automation because they’re deterministic. The triggers are objective (a cancellation, or a three-hour domestic or six-hour international change), the refund must go to the original form of payment, and the deadline is fixed at seven business days for cards or twenty calendar days otherwise. An agent can screen eligibility, issue the refund within the window, and do it at the scale a mass disruption demands, provided the payment sits behind a control and fraud checks.

Why should compensation decisions stay with a human?

Because EU261 compensation turns on whether the disruption was an “extraordinary circumstance” the airline couldn’t have avoided, which is a legal judgment, not a lookup. The same delay can be coded as a technical fault (usually payable) or weather (usually not), and the coding decides the money. An agent can draft the decision with the reason cited, but auto-denying on that call creates legal liability, so a person should approve it.

Is the US DOT automatic refund rule still in effect in 2026?

The core rule is in effect. The only active carve-out is a narrow enforcement pause on refunds for renumbered flights, where the passenger is rebooked with no significant change, which runs through July 2027 while DOT reconsiders the definition of a cancelled flight. The three-hour domestic and six-hour international significant-change thresholds still apply, so build your eligibility logic to them.


Building the refund-and-compensation layer around your reservation and payment systems, with the deterministic part automated and the judgment gated to a human? Talk to us. Grounding an agent in the systems of record and drawing the money-movement boundary cleanly is exactly the Agentforce work we do.

Keep reading

All insights