GDS Command Cheat Sheet: Amadeus, Sabre & Galileo Side by Side

Every GDS does the same basic jobs: search availability, sell a segment, build and end a PNR. Each does them with its own command syntax. If you switch between systems, or you're learning a second GDS after training on one, this sheet keeps the essentials side by side. I've limited it to entries with a stable, widely documented format and checked them against vendor quick-reference material. Where something depends on your agency's setup, it's marked as format-variable instead of presented as gospel.

How Cryptic Entries Are Built

Once you see the grammar, the three systems look less alien. Almost every entry is a short command code followed by compressed data with no spaces: a date as day plus three-letter month (15DEC), a city pair as two three-letter codes run together (JFKLAX), a booking class letter, and a seat count. There are two ways to sell a seat. You can sell from availability: run a search, then tell the system which line and class you want. Or you can direct sell: type the airline, flight number, class, date, route and number of seats yourself, with no search first. Sell-from-availability is faster at the keyboard. Direct sell is what you use when you already know the flight, such as rebuilding a booking from an email.

Core Command Comparison

The examples assume one passenger, a New York to Los Angeles flight on 15 December, and a Y-class seat on line 2 of the availability screen.

Sabre's time-limit line, phone line and received-from line are the ones people most often mistype, because each uses a bare number prefix (7, 9, 6) instead of letters. Galileo is the opposite: letter-and-full-stop prefixes such as N., P., T. and R.. Amadeus sits in between with two-letter element codes (NM, AP, TK, RF).

A Full Booking, Three Ways

Imagine an agent, Jo Sandoval, booking Maria Lopez on the flight above. Here is the same sequence in each system, for illustration only. The seat count, class and line number would all come from the live availability screen.

Amadeus

AN15DECJFKLAX
SS1Y2
NM1LOPEZ/MARIA MS
AP NYC 2125550100-H
TK TL10DEC
RF JS
ER

Sabre

115DECJFKLAX
01Y2
-LOPEZ/MARIA MS
9212-555-0100-H
7TAW10DEC/
6JS
ER

Galileo

A15DECJFKLAX
N1Y2
N.LOPEZ/MARIA MS
P.NYCH*212 555 0100
T.TAU/10DEC
R.JS+ER

The order is the same everywhere: look, sell, name, contact, ticketing deadline, who you are, then save. Nothing is stored in the booking file until the final end entry. Until then it is only a working copy. Close the window, or ignore the transaction, and the whole thing evaporates, seats included.

Direct Sell or Sell From Availability?

Both do the same thing, so pick whichever fits the job in front of you.

• Sell from availability when you are shopping. You see what is open on the day, compare departure times, and one short entry books the line you want. It is the fastest route for new bookings, and it cannot contain a typo in the flight number because you never type it.
• Direct sell when the flight is already decided: the client forwarded an airline confirmation, you are rebuilding a cancelled PNR, or you are adding a connecting segment you looked up elsewhere. The risk is that every character is yours. A wrong date or class letter will be rejected, or sell something different from what you intended.
• Neither when you only need to know whether a flight operates. Check a schedule or the flight status page instead of tying up inventory.

Whichever you use, look at the segment line the system returns before you carry on. Day, date, route and status should all match what the client asked for.

End, Ignore and the Mistakes They Prevent

The end/ignore pair causes more lost work than any other commands. A few rules keep you out of trouble:

• Prefer ER over ET (or E). The redisplay shows the booking as saved, with its record locator, so you can confirm that what you typed is what was stored. Ending blind is how a missing segment survives until the client is at the airport.
• Read the response after ending. Warnings, such as a message that someone else changed the booking at the same moment, a segment that has changed status, or a missing mandatory field, mean the save did not complete as you expected. Redisplay the booking before you do anything else.
• Use ignore when you are unsure. If you have made a mess of a retrieved booking, ignoring discards your unsaved changes and leaves the stored version untouched. Ending a mistake saves it.
• Check the status after you sell. The action code in a direct sell (NN on Sabre and Galileo) is what you asked for. The status that comes back is what the airline answered. Anything other than confirmed (see the status code reference) needs attention before you save.

Cancelling Without Cancelling the Wrong Thing

When you cancel an element, the lines below it renumber immediately. If you cancel line 3 and then type a cancel for line 4 from memory, you may delete the wrong segment. Two habits help. Display the booking again between cancellations, or cancel from the highest number down. In Amadeus you can also remove several elements in one entry, for example XE5,7-11, so the numbers are interpreted before anything moves. Cancelling the whole itinerary (XI) leaves names and contacts in place. That is useful when you are rebuilding a trip, but it also means a booking is not gone until you have ended the transaction.

What Is Format-Variable

These areas legitimately differ between agencies, regions and system versions, so check them against your own training material or host agency before relying on them:

• Mandatory fields. Many offices require an email, a ticketing arrangement and a form of payment or agency remark before a booking will end. The list is set by the agency, not by the GDS.
• Phone entries. The city code, type letter and whether an agency number is compulsory vary. The examples above show the usual shape, not a universal rule.
• Ticketing and pricing options. Entries for issuing tickets, applying commission, selecting passenger types and choosing fare options depend on your ticketing arrangement and settlement system (ARC or BSP), so this sheet leaves them out on purpose.
• Special service requests. Passport data, meal codes and seat requests have standardised content but airline- and system-specific entry formats.
• Graphical front ends. Sabre Red 360, Amadeus Selling Platform and Smartpoint accept cryptic entries, but they may transform or pre-fill some of them. Read our Sabre Red 360 guide for how that works.

Why the Commands Differ So Much

Sabre began as a 1960s project between American Airlines and IBM. Amadeus was set up in the late 1980s by a group of European airlines. Galileo was formed around the same time by other European carriers, later absorbed United's Apollo system, and ended up inside Travelport. They were built independently, for different airlines and markets, and by the time they were competing nobody could afford to make agents retrain. The Passenger Name Record, with its names, segments and remarks, is a shared idea, but the language on top of it never converged.

What Stays the Same Across All Three

• The core PNR concept: names, itinerary segments, contact, ticketing
• Two-letter status codes like HK for confirmed and HL for waitlisted
• Single-letter booking class codes (though which letter maps to which fare rules can vary by airline; see the booking class guide)
• The general workflow: search availability, sell the segment, add required fields, end the transaction

Learning It Properly

Do not try to memorise a full table in one sitting. Pick the six entries you use daily (availability, sell, name, retrieve, end and cancel) and type them from memory until they are automatic. Add pricing and fare display next. Then learn the second system by mapping it to the first, using a table like the one above. For anything beyond the basics, go to the vendor. Travelport publishes a formats mini-guide, and Amadeus and Sabre training portals are normally available through your host agency or office. Our own GDS commands reference lists more entries, and the line-by-line guides for Amadeus and Sabre show what those entries produce.

This is a general reference, not a substitute for your GDS's own documentation or your agency's procedures.