Agency Debit Memo Checks With AI: One Real Example

A ticket takes seconds to issue. If it broke an airline's rules, the bill can arrive weeks later. By then the money is collected, the commission is paid and the passenger has flown.

That bill is an agency debit memo, or ADM. A ticket consolidator we work with brought us this problem. They wanted to know if AI could spot rule-breaking bookings before the tickets went out.

We are not ADM specialists, and this is not a complete guide. It is what we tried in a proof of concept (a small trial build), what worked, what didn't, and what we learned.

What is an agency debit memo (ADM)?

An agency debit memo (ADM) is a charge an airline sends to a travel agency after its audit finds a booking or ticket broke the airline's rules. It usually goes to the agency that issued the ticket. Some ADM risks can be spotted while the booking waits to be ticketed, which is where our proof of concept focused.

Put simply:

Before ticketing, a broken rule costs a fix. After ticketing, it can cost an ADM.

IATA, the airlines' trade body, describes ADMs as adjustments issued by an airline for any incorrectly reported document.

In many countries, agencies and airlines settle up through IATA's shared billing system, the Billing and Settlement Plan (BSP). Airlines send ADMs through BSPlink, the BSP's online system, and the amount lands on the agency's next bill.

Each airline publishes its own ADM policy. Qantas's ADM policy, for example, adds an administration fee to each ADM on top of the amount owed.

Some ADMs come from work done after ticketing, such as refunds, reissues and name changes, which Qantas also lists. Our proof of concept didn't cover those.

Why does the ticketing agency pay for a sub-agent's booking?

This was the first thing we had to understand. It helps to know who does what when an air ticket is sold:

• The airline owns the seats, the fares and the rules for selling them.
• The GDS (global distribution system, such as Sabre, Amadeus or Travelport) is the shared marketplace where seats are booked.
• The consolidator is a large agency with airline contracts and the authority to issue tickets.
• The sub-agent is a smaller travel agent. It often can't issue tickets itself, so it builds the booking and sends it to the consolidator.

The ticket goes out under the consolidator's ticketing authority. So when the airline's audit finds a broken rule, the ADM goes to the consolidator, even if a sub-agent built the booking. Getting that money back from the sub-agent is a separate, often painful conversation.

Why doesn't the GDS stop the booking? Because it is a neutral marketplace, not the airline's enforcer. It can't know which exceptions an airline agreed to. So the ADM is often the first sign that anything was wrong.

1. The sub-agent builds the booking in its own GDS office.
2. The booking waits in the consolidator's ticketing queue. This is the window where a check can still fix, reprice or hold it.
3. The consolidator issues the ticket under its own authority.
4. The airline audits the ticket, often weeks later.
5. The airline sends the ADM to the consolidator, not to the sub-agent.
6. The consolidator recovers the money from the sub-agent, if it can.

What causes an ADM in airline ticketing?

Airline ADM policies list many causes. The ones we looked at fall into a few families. The table pairs each family with an example and where it comes from.

The last column is our own view, based on the checks we built. What stood out to us: many ADM causes are clear-cut. The booking either breaks the rule or it doesn't. Only a few need someone to read and weigh the evidence.

What is a point-of-sale violation?

A point-of-sale violation was the clearest example in our work. It also showed us how subtle these rules can be.

Every agency office in a GDS has an identity, called a PCC (pseudo city code) in Sabre or an Office ID in Amadeus. Each one is registered to a country. Airlines open different booking classes in different markets, so a cheap class can be open to an Indian office while it is closed to a US one.

Say a sub-agent builds a booking in its own India-registered office, where the cheap class is open. It then sends the booking to a consolidator's US ticketing office to be issued in US dollars. The seat came from a market the US sale was never entitled to. The airline treats this as misuse of its seats.

Airlines put this in writing. From 1 September 2025, Thai Airways requires that tickets are issued in the same country where the booking was made. Ticketing elsewhere, particularly to get round controls such as fare availability, is a violation. Thai issues an ADM of USD 100 per passenger for each one.

The test we landed on: were the booking office and the ticketing office registered in the same market?

For this rule, where the traveller is from, where the agency's staff sit and where the journey starts are not the test.

We got this wrong at first, and it would have flagged every legitimate cross-border sale. An agency in India using a US office that a consolidator provides can be completely normal. A fare can still carry its own sales restrictions. Those are checked against the fare rules, which comes up below.

Why is checking after ticketing too late?

Many consolidators only learn about a broken rule when the ADM arrives. By then the ticket is issued and the money has moved. The only options left are to pay or dispute.

Disputes take evidence and time. Qantas, for example, asks agents to raise a dispute within 60 days of the ADM notification, with justification and supporting evidence.

There is a window where prevention is cheap: between the booking being made and the ticket being issued. In a consolidator, bookings usually sit in a ticketing queue during this window. A booking found here can be fixed, repriced or rejected before any money changes hands.

The problem is volume and speed. Checking every booking by hand doesn't scale, and spot-checks miss most of them. Auto-ticketing tools make it harder still: they issue whatever fare is stored in the booking, and no person looks.

How did we split the checks between software, an AI agent and a person?

The most useful thing we did was sort the rules into groups before building anything. Some rules are black and white, and plain software checks them perfectly. Others need someone to read and weigh evidence. That's the only place we used AI.

1. Rule checks in software. Every booking passes through these first. This one breaks no clear-cut rule: the office markets match and the currency is right. The software notes the hand-typed fare for the next check.
2. The AI agent, for judgment. It reads the remarks and fare rules. It finds no approved exception for the hand-typed fare, so it flags the booking with its reason.
3. A person decides. They keep the booking on hold and ask the booking agent for the airline's approval.

1. Clear-cut rules: plain software

For these, we found plain software a better fit than AI. It gives the same answer every time, costs almost nothing to run, and an auditor can read exactly why a booking was flagged. The rules we put here:

• Office markets: booking office country against ticketing office country.
• Currency: the currency collected against the one the ticketing office is set up to collect.
• Duplicates: the same passenger on the same flight in more than one booking.
• Missing details: passenger names or contact details that are required but empty.
• Hand-typed fares: whether the fare was priced by the GDS or typed in, where the GDS records this.

2. Cases that need judgment: an AI agent

Some ADM risks can't be reduced to a yes-or-no rule. The evidence sits in free-text remarks, in fare rules written in airline shorthand, and in patterns that only look wrong in context:

• A hand-typed fare with a story. Is it an exception the airline agreed to, or a cheaper fare typed in to get round the system?
• Remarks left by agents. They can point to an approved deal or to a workaround. Only reading them tells you which.
• Fare rules against the booking. Sale restrictions and routing rules are dense text that has to be interpreted.
• Suspicious patterns. Names that look like placeholders, or the same traveller booked and cancelled again and again.

3. The decision: a person

The AI agent recommends; a person decides. The agent never issues, cancels or changes a booking. It flags the booking with its reason. Flagged bookings are held for a person to review, and that person decides.

With the reason in front of them, they can agree or disagree in seconds. This is the same rule we use for any action that needs human approval.

What we built, and how it was scoped to run in Avesta AgentOS

The proof of concept checked bookings in the consolidator's ticketing queue before they were issued. We scoped it to run on Avesta AgentOS, our platform for building and running AI agents, or as a custom build.

What we built

• Rule checks first, AI second. Every booking went through the rule checks. Only bookings that needed judgment went to the AI agent, which kept cost and response time down.
• What the agent saw. For each booking, it got the booking record and the results of the rule checks, so it didn't repeat them. It also got the rule in plain words, plus the airline's fare rules, fetched from the GDS only when needed.
• What it returned. A verdict, the rule involved, its reasoning in plain words and a suggested next step. That reason is what a reviewer reads, and what an AI agent audit log should keep.
• Batching. The agent worked through bookings in batches of 20, using about 5 agent turns per batch (an agent turn is one round of reading and deciding).

Where the data runs

Booking data is sensitive, and many travel businesses don't want it leaving their own systems. We scoped three ways to run the checks. They could run on Avesta AgentOS in our cloud, on Avesta AgentOS inside the client's own cloud, or as a fully custom build in the client's cloud.

Running inside a client's own cloud account is how CHAIRS Global runs its members' assistant.

What we learned

1. Where people sit isn't the point of sale. Our first framing mixed up an agency's location with its office's registered country. Getting this wrong would have flagged every legitimate cross-border sale.
2. Build rules from real ADMs. General rules are a start. We asked the client's audit team for real ADMs, because those are the rules airlines actually charge for.
3. Shortcuts create false alarms. Comparing the office's country with where the journey starts is easier to build, but it is a different test. Currency has the same trap. A ticket for a journey starting in India shows the fare in rupees, even when a US office sells it and collects US dollars. That is compliant, so the check looks at the currency collected, not the fare's currency.
4. Most of our checks didn't need AI. The hard part was deciding which rules need judgment. Getting that split right made the system cheaper, faster and easier to trust.
5. GDS access takes longer than the logic. Access forms, fixed network addresses and permissions all take time. Ask only for the GDS services you need, because extra ones can add costs you didn't plan for.

The hard part wasn't the AI. It was deciding which ADM rules need judgment at all.

When is an automated ADM check not worth it?

Our proof of concept covered a handful of rules for one consolidator. Here is where we would be careful:

• It is not complete protection. We covered a few rules. New workarounds keep appearing, and each new ADM should become a new check.
• Low volume. If you issue a handful of tickets a day, a trained ticketing person with each airline's ADM policy open is likely to be cheaper and good enough.
• No ADM history. If you can't get examples of the ADMs you have actually received, start by collecting them. Rules built from textbook principles miss what airlines really charge for.
• Only clear-cut rules. If every rule that hurts you is a yes-or-no check, plain software is enough. Adding an AI agent adds cost and variation without adding accuracy.

We saw the same thing when we built checks for reading shipping documents: fixed rules caught what the AI's own confidence scores missed.

The bottom line

An agency debit memo is the airline's bill for a rule that was broken before the ticket went out. In our proof of concept, the ticketing queue was the place to look, because a booking there can still be fixed.

Our main lesson was to sort the rules into two groups first. One group holds the rules a booking clearly breaks or doesn't. The other holds the ones that need someone to read and weigh things. Software took the first group. The AI agent helped with the second, with a person deciding. Our guide to AI agent human approval covers which decisions should always wait for a person.

Which of last quarter's ADMs could a simple rule have stopped before the ticket was issued?

---

Working on the same problem? We'd be glad to compare notes. We can also run checks against a sample of your own bookings.

See how we build AI agents for travel businesses

Get started: hello@avestalabs.ai