AI Agents
AI agents for airline revenue accounting: proration, interline settlement, and the order-based shift
A flown ticket carried by three airlines has to be split across all three, billed through IATA's SIS, and reconciled against a stack of rejection memos. It's rules-heavy, deadline-driven, and mostly manual. Here's where an agent grounded in Data 360 earns its place in the revenue-accounting back office, where it must not, and how the move to order-based settlement changes the target.
A passenger books one ticket and flies three airlines to get home. The fare was collected by the airline that sold the ticket. The other two carried the passenger and are owed their share. Working out that share, billing for it, and arguing about it when a partner disagrees is interline revenue accounting, and it’s one of the last manual corners of a modern airline’s back office.
The volume is not small. IATA’s Simplified Invoicing and Settlement system processed over 1.94 million interline and supplier invoices worth more than USD 89.0 billion in 2025, up 18% on the prior year, across 497 airlines and thousands of other entities. Behind each of those invoices sits proration logic, coupon matching, and a rejection-memo loop that runs on strict deadlines.
My answer up front: point an agent at the triage, the matching, and the first draft of a rejection response, where the rules are written down and the exceptions are the actual work.
Keep the disputed valuations and the accounting judgment human. That split is the whole design, and getting it wrong in either direction, too timid or too bold, is how these projects fail.
What the work is
The IATA Revenue Accounting Manual sets the standard billing procedures for interline accounting of passenger, cargo, UATP and miscellaneous revenue. Strip the jargon and the cycle looks like this.
A ticket is issued with coupons, one per flight segment. When a coupon is flown on a partner airline, that partner is owed a prorated slice of the fare, calculated under agreed rules. The owed airline bills the issuing airline through SIS.
The issuing airline’s revenue accounting team checks each incoming bill against its own records. When a value looks wrong, it raises a rejection memo, and the two carriers exchange memos until the amount is agreed or escalated. SIS stores the prorate records from the value-determination process and generates the invoices and the daily revenue-recognition file that feeds each airline’s books.
Three properties of that cycle decide where an agent fits. It’s high-volume and repetitive, which suits automation. It’s rule-bound, so most decisions are lookups against documented logic, not judgment calls. And it’s deadline-driven: rejection memos have windows, and a missed window means eating a cost you could have recovered.
That last property is the one that makes automation worth it, because the failure mode of manual processing isn’t wrong answers, it’s answers that arrive too late.
The three jobs worth handing an agent
Not “automate revenue accounting.” That framing is how you end up with a model making settlement decisions it can’t defend. Three specific jobs, each with a clean boundary.
Rejection-memo triage. Incoming memos arrive with a reason code and a disputed amount. An agent can read the memo, pull the matching coupon and prorate record, classify the dispute (a genuine proration disagreement, a duplicate, a stale fare, a data mismatch), and route it, with the supporting records already attached, to the right queue. The accountant opens a memo that’s already been investigated instead of one that’s just been received.
Coupon and invoice matching. Before a bill is even disputed, someone has to match incoming billing records to flown coupons and flag the ones that don’t reconcile. This is pattern work: join the billing record to the coupon, check the amount against the expected prorate, surface the outliers. An agent that does the join and presents only the exceptions turns a full-file review into an exceptions review.
Drafting the response. When a rejection is valid, the reply often follows a template: cite the RAM rule, attach the record, state the corrected value. An agent can draft that reply for a human to approve. Drafting is not deciding. The accountant still owns the send.
None of those three is the agent setting a settlement value on its own. That line is deliberate, and it’s the same human-in-the-loop boundary that any high-stakes agent needs: the model does the gathering and the first pass, the person owns the number that leaves the building.
Grounding it: the data problem comes first
An agent is only as good as what it can see, and airline revenue data is scattered by design, ticketing in one system, the SIS billing files in another, fare rules in a third, partner agreements in a shared drive. An agent that can’t join those can’t triage anything.
This is a Data 360 job before it’s an agent job. Unify the coupon records, the inbound and outbound SIS billing data, and the prorate records into a governed model the agent can query.
The value-determination logic and the partner agreements become grounding the agent reasons over, not knowledge it invents. Skip this step and you get a confident model hallucinating prorate rules, which in a settlement context is worse than no model at all.
A rough shape for a single triage decision, expressed as the structured output you’d want the agent to return before any human sees it:
{
"memoId": "RM-2026-118342",
"couponRef": "057-2214887762-3",
"disputeReasonCode": "PRORATE_DISAGREEMENT",
"billedAmount": 214.50,
"expectedProrate": 168.20,
"variance": 46.30,
"classification": "likely_valid_rejection",
"ramRuleCited": "provisional_prorate_rule",
"supportingRecordsAttached": true,
"recommendedQueue": "senior_analyst",
"confidence": 0.72,
"humanApprovalRequired": true
}Note the last two fields. The agent reports its confidence and always flags that a human approves. A structured decision like that is auditable: you can query why the agent routed a memo the way it did, which matters when a regulator or a partner asks. Salesforce shipped Agentforce Operations specifically for back-office finance and compliance work with audit trails, and this is the shape of workload it’s built for, high-volume task automation where every action has to be explainable after the fact.
The order-based shift changes the target
Here’s the part that makes this more than a cost-cutting story. The whole ticket-and-coupon-and-proration edifice is being replaced.
IATA’s Offers and Orders work moves the industry from ticket-based accounting to order-based accounting. In the Settlement with Orders program, a single order ID carries the payment and sales accounting, and settlement runs on the order rather than on reconstructed coupons. The pilot for interlining with offers and orders established internal values and settlement amounts upfront, in real time with revenue accounting, removing the need for proration altogether.
If proration is going away, why automate it? Because the transition takes years, and during it every airline runs both worlds at once: legacy interline on tickets and coupons for existing partners, order-based settlement for the ones who’ve migrated.
The reconciliation work doesn’t shrink during that window. It doubles, because now you’re matching across two models. An agent that can triage a rejection memo in the ticket world and validate an order-based settlement in the new one is more valuable during the migration than in either steady state.
So the design brief has a time dimension. Build the grounding model to hold both ticket-coupon records and order records, and scope the agent’s tools so the same triage and matching logic works whichever settlement model a given transaction used. Don’t build a tool that assumes proration will exist forever, and don’t build one that assumes it’s already gone. It’s the same dual-running reality the move to NDC and order-based retailing created on the selling side, now reaching the back office.
What this is not
It’s worth being clear about the boundaries, because this sits next to work we’ve covered that looks similar and isn’t.
It’s not passenger refunds and compensation. That’s money going back to a customer under fare rules and regulation. Interline settlement is money moving between carriers under IATA billing rules. Different counterparties, different systems of record.
It’s not the merchant payment stack. Card networks, tokenization and PCI scope are the passenger-payment world. SIS settlement is airline-to-airline netting, a different two-sided flow entirely.
And it’s not a replacement for a specialist revenue-accounting platform. The heavy proration engines and SIS integrations are mature products. The agent’s job is the reasoning layer on top, triage, matching, drafting, escalation, feeding those systems cleaner inputs and taking their outputs to a human faster.
Framed that narrowly, it’s a defensible, high-value build. Framed as “let AI do revenue accounting,” it’s a project that will lose a partner’s trust the first time it agrees to a settlement value it shouldn’t have.
The teams that get this right start with the data model, pick the three jobs above, keep the accountant on the settlement decision, and build for the years when tickets and orders both exist. That’s a smaller ambition than the pitch decks want, and it’s the one that ships.
Understanding the basics
What is interline revenue accounting?
It’s how airlines settle money between each other when a passenger’s journey is carried by more than one carrier. The airline that sold the ticket collected the fare; the carriers that flew each segment are owed a prorated share. Working out those shares, billing for them through IATA’s settlement system, and resolving disputes is interline revenue accounting, governed by the IATA Revenue Accounting Manual.
What is IATA SIS?
SIS, Simplified Invoicing and Settlement, is IATA’s platform for exchanging and settling interline and supplier billing electronically. In 2025 it processed over 1.94 million invoices worth more than USD 89.0 billion across 497 airlines and thousands of other participants. It stores prorate records, generates invoices on behalf of the billing entity, and produces the daily revenue-recognition file airlines post to their books.
Where should an AI agent stop in revenue accounting?
At the settlement decision. An agent can triage rejection memos, match coupons to billing records, surface reconciliation exceptions, and draft responses citing the relevant rule, with every action grounded in unified data and logged for audit. It should not set or agree a settlement value on its own. That judgment stays with a human accountant who owns the number.
How does order-based settlement change interline accounting?
Under IATA’s Offers and Orders model, a single order ID carries payment and sales accounting, and settlement runs on the order with values established upfront, which removes the need for proration. The shift takes years, so airlines run legacy ticket-and-coupon interline and order-based settlement side by side during the transition, which is exactly when reconciliation tooling has to handle both models at once.
If you’re sitting on a revenue-accounting backlog and weighing where an agent grounded in your own data fits, and where it must not, that’s the conversation to have. Talk to us. We scope the workflow, build the Data 360 foundation, and keep the human on the decisions that have to stay human.
