How to Read an Amadeus PNR Line by Line

An Amadeus PNR can look like a wall of cryptic codes the first time you see one. It isn't random — every line follows a consistent structure. This walkthrough takes a real-style Amadeus PNR apart line by line so you can read one confidently, whether you're new to the desk or just switching over from another GDS.

A Sample Amadeus PNR

RP/LON1A2345/LON1A2345
1.SMITH/JOHN MR
2 BA 284 H 15JUL 2*LHRJFK HK2 1120A 215P
3 AP LON 020 7946 0958
4 TK OK15JUL/LON1A2345

Line 1: The Record Locator Header

RP/LON1A2345/LON1A2345 identifies the office that created and is currently servicing the booking. LON1A2345 is the office ID — it tells you which agency location owns the PNR, which matters if you need to trace a booking back to its source.

Line 2: The Passenger Name

1.SMITH/JOHN MR is the passenger name element. The format is always SURNAME/FIRSTNAME TITLE, numbered starting from 1. Multiple passengers each get their own numbered line.

Line 3: The Flight Segment

This is the line most new agents find hardest to parse at first. Breaking 2 BA 284 H 15JUL 2*LHRJFK HK2 1120A 215P down piece by piece:

Line 4: Contact Element

3 AP LON 020 7946 0958 is an "AP" (address/phone) element. LON indicates a London-based contact number, followed by the actual phone number. Every PNR needs at least one contact element before it can be ticketed.

Line 5: Ticketing Element

4 TK OK15JUL/LON1A2345 records the ticketing arrangement — in this case a ticketing time limit or confirmation, tagged with the date and office that set it. TK OK variants and their exact meaning can vary depending on whether it's a time limit, a ticketed confirmation, or an auto-ticket instruction.

What About Multi-Segment or Multi-Passenger PNRs?

Longer PNRs simply repeat these same element types with incrementing line numbers — more passenger lines, more segment lines for connections or a return journey, sometimes additional remarks (RM) or special service requests (SSR) elements for things like meal preferences or wheelchair assistance. The reading method doesn't change; there's just more of it.

A Full Multi-Segment, Multi-Passenger PNR

The five-line example above is deliberately simple. Real bookings are rarely that short. Here's a more realistic Amadeus PNR for two passengers flying London to Singapore with a connection in Dubai, and a return home three weeks later — the kind of booking you'll actually pull up on a busy desk:

RP/LON1A2345/LON1A2345
1.KHAN/ANITA MRS
2.KHAN/RAHUL MR
3 EK 001 K 10SEP 4*LHRDXB HK2 2115 0740 11SEP E
4 EK 354 K 11SEP 5*DXBSIN HK2 0930 2050 E
5 EK 355 K 24SEP 4*SINDXB HK2 2330 0330 25SEP E
6 EK 002 K 25SEP 5*DXBLHR HK2 0900 1310 E
7 AP LON 020 7946 0958
8 AP LON RAHUL.KHAN@EMAIL.COM
9 TK OK10AUG/LON1A2345
10 SSR VGML EK HK1/S3 KHAN/ANITA
11 RM PSGR REQUESTED AISLE SEATS BOTH PAX

Nothing here is a new element type — it's the same five building blocks from the walkthrough above, just repeated. A few things worth pointing out that don't show up in the short example:

• Two numbered name lines (1, 2) — each passenger gets their own line, and every segment status code that follows a number like HK2 applies to both of them unless a later element narrows it down to one.
• Four segments instead of one — lines 3 and 4 are the outbound journey with a connection in Dubai; lines 5 and 6 are the return three weeks later. Notice the arrival airport of one segment matches the departure airport of the next (LHRDXB then DXBSIN) — that's how you spot a connection versus two unrelated one-way segments.
• Two AP lines — a phone contact and an email contact. Modern PNRs frequently carry both; Amadeus doesn't restrict you to one contact element.
• SSR VGML EK HK1/S3 — a special service request for a vegetarian meal, confirmed (HK1) on segment 3 specifically, and tied to Anita Khan by name at the end of the line. SSRs are how meal preferences, wheelchair assistance, and similar requests get attached to a booking.
• RM — a free-text remark. These are internal notes for the agency and never appear on the airline's own confirmation or the passenger's ticket.

When a Status Code Changes Mid-Booking: HL Becoming HK

A status code isn't permanent. The most common change an agent will see is a waitlisted segment (HL) clearing to confirmed (HK, or sometimes KL for "confirmed from waitlist"). This happens when other passengers cancel, no-show, or get moved, freeing up inventory the airline then allocates down the waitlist.

The important thing to understand is that this change happens on the airline's side, not automatically in front of you. If you printed or emailed an itinerary while a segment showed HL, that document is now out of date the moment the airline clears the waitlist — the PNR itself won't refresh on its own in a saved file, and a client reading an old PDF has no way to know the segment is now confirmed. You have to actively redisplay the PNR (retrieve it again) to see the current status.

When you do see a segment flip from HL to HK, treat it as a trigger to re-issue the client's itinerary, not just a status you note and move past. The client's original confirmation email or document, if it still shows the old waitlisted status, should be considered stale until you've sent an updated one.

Codes That Look Alike But Aren't

A handful of code pairs cause more confusion than the rest combined, mostly because they look similar at a glance or share a letter:

Unusual or Legacy Codes You Might Encounter

Occasionally a segment status won't match anything in a standard reference table. This tends to happen with airlines that route bookings through older host systems, regional and codeshare partners with their own internal conventions, or carriers that have only partially adopted newer distribution methods like NDC. When that happens, resist the urge to guess based on which letter it "looks closest to."

The safer path is to use Amadeus's own encode/decode and help entries (agents typically reach these through a help command referencing the status code directly) or to contact the GDS helpdesk or the airline's own reservations line. An unfamiliar code should never be assumed confirmed just because the segment otherwise looks complete — treat it as unconfirmed until you've verified it, the same caution you'd apply to HL or UN.

From PNR to Client Confirmation: What the Traveler Actually Sees

It helps to remember that almost none of what you're reading in the raw PNR is visible to the passenger in the same form. The mapping looks roughly like this:

• HK / KK segments — the passenger sees these as a normal confirmed flight on their e-ticket and in the airline's app, with no indication a status code was ever involved.
• HL segments — the passenger typically sees nothing at all until the airline emails them directly about the waitlist, or the agent tells them. The PNR's waitlist status isn't pushed to the traveler automatically.
• The TK element — entirely invisible to the client. It exists purely to track the agency's ticketing deadline.
• The AP element — becomes the phone number or email the airline actually uses if there's a schedule change or irregular operation, so accuracy here matters more than it might seem.
• RM remarks — internal-only; a client never sees these regardless of how the booking is delivered to them.

This gap between what the agent sees in the raw record and what the client sees on their confirmation is exactly why translating a PNR into a clean itinerary — rather than forwarding the raw text — matters for client communication.