Short answer: a PNR (passenger name record) is the database record a reservation system creates when a flight is booked. It holds who is travelling, the flight segments, contact details and ticketing arrangements, and it is identified by a short alphanumeric record locator. The PNR is the reservation; the e-ticket is the separate payment document issued against it.
What a PNR actually is
A passenger name record is a structured record created in a computer reservation system, either an airline's own passenger service system (PSS) or a global distribution system (GDS) such as Amadeus, Sabre or Travelport. The concept and its minimum contents are standardised through IATA resolutions so that any system in the chain can interpret the booking. If you want the airline-side view of the systems involved, see our companion guide to what a PSS is.
The key mental model: the PNR is a living reservation object, not a receipt. It changes over time as segments are added, tickets are issued, seats are assigned and schedule changes arrive. Agents and APIs do not "look up a ticket"; they retrieve and modify a PNR.
Record locator vs e-ticket number
New agency staff mix these up constantly, and the confusion causes real servicing errors. They are different objects with different jobs.
| Attribute | Record locator (PNR code) | E-ticket number |
|---|---|---|
| What it is | Short alphanumeric reference to the reservation record, commonly six characters | A 13-digit document number: a 3-digit airline accounting code plus a 10-digit serial with check digit |
| Identifies | The whole booking, usually shared by everyone travelling together | One flight document for one passenger |
| Issued by | The reservation system at end of transaction, before payment | The airline (via BSP, ARC or the carrier) when the ticket is issued |
| Used for | Retrieving and changing the booking, online check-in | Refunds, reissues, exchanges and revenue accounting |
| Guarantees a seat? | No. An unticketed PNR is only a held reservation | Yes, it is the proof of payment tied to the fare rules applied |
A booking therefore fails in a very specific way: a PNR can exist with no ticket attached. If the ticketing time limit passes, the airline cancels the segments and the traveller, who still has a confirmation email with a record locator on it, discovers there is no ticket. Refund and reissue work is tracked against ticket numbers, which is why our guide to airline refunds and reissues starts from the ticket, not the PNR.
What a PNR contains
GDS documentation, such as the Amadeus reservation guidelines, requires five mandatory elements before a PNR can be saved (in Amadeus terms, "end transacted"):
- Name - each passenger's surname and given name, which must match the travel document because tickets are non-transferable.
- Itinerary segments - the flights (or other services) with dates, origin, destination, booking class and status codes.
- Contact - phone or email for the booking.
- Ticketing arrangement - when and how the booking will be ticketed, or a ticketing time limit.
- Received from - who requested the booking or change, an audit field agencies rely on when disputes arise.
Around that core sit optional elements that carry most of the servicing detail: SSRs (special service requests such as wheelchair assistance or infant status), OSI messages to the airline, frequent flyer numbers, seat assignments, form of payment, fare records created at pricing time, and free-text remarks agencies use for internal notes. When a ticket is issued, the ticket number is written back into the PNR, linking the two objects.
One booking, several PNRs
When an agency books through a GDS, at least two records exist: the GDS PNR the agency controls, and the airline's own PNR in its PSS, each with its own record locator. The systems synchronise through teletype and EDIFACT messaging, and the airline locator is usually written into the GDS record. Codeshares add more copies, one per marketing and operating carrier.
This is why a traveller sometimes cannot pull up a booking on an airline website with the locator printed on an OTA confirmation: they are holding the GDS locator, not the airline one. It is also why changes made directly with the airline can leave the agency PNR out of date until a schedule change message arrives. Teams building on a travel API integration need to store every locator the supplier returns, not just the first one.
Queues: how agencies work PNRs
GDSs sort PNRs that need human attention onto queues: numbered work lists per agency office. Schedule changes, ticketing time limit warnings, waitlist confirmations, rejected name changes and airline messages all land on queues. A traditional agency starts the day by "working queues"; an online agency does the same thing with software, polling queues through the GDS API and routing each PNR to an automated handler or a support agent.
If you run an OTA and nobody, human or machine, is watching queues, you will learn about schedule changes from angry customers instead of from the airline. Queue handling is one of the mid-office features we scope early in any flight booking engine project.
Splitting and reshaping a PNR
PNRs support surgery. The most common operation is the split (or divide): when one passenger in a group of four needs to change a date, the agent divides the PNR so that passenger gets a new record locator and the change can be made without touching the other three. Splits keep an audit link between parent and child records.
Other routine operations include rebooking segments into a different booking class, cancelling individual segments while keeping the record alive, and adding infants or SSRs after creation. Every operation rewrites PNR history, a time-stamped log that experienced agents read the way developers read version control history.
Why bookings break
Most PNR-related failures trace to a small set of causes:
- Ticketing time limit missed: the PNR was created but not ticketed in time, so the airline auto-cancelled the segments
- Name mismatch: the PNR name does not match the passport, and correction rules differ by airline
- Duplicate bookings: two live PNRs for the same passenger and flight trigger airline dupe-checks that can cancel both
- Schedule change not actioned: the airline changed a flight, queued the PNR, and nobody reconfirmed the new segments
- Churning: repeatedly booking and cancelling to hold inventory, which airlines penalise with agency debit memos (ADMs)
- Stale sync: the airline PNR and the GDS or OTA copy disagree after a direct change, so one side shows segments the other has lost
None of these are exotic. A disciplined mid-office that tickets on time, monitors queues and reconciles supplier records catches nearly all of them before the traveller notices.
What this means for your booking engine
If you are building or buying a booking platform, the PNR model dictates the architecture. Your engine must store the supplier's record locator (and the airline's, when returned), track ticketing deadlines, poll or receive queue events, and keep a local copy of the itinerary that can be re-synchronised when the supplier record changes. APIs differ in how much of the PNR they expose: a full GDS integration gives you the whole record including history, while simpler flight APIs return only a booking reference and status, leaving servicing to the supplier's own tools.
Either way, treat the supplier's system as the source of truth and your database as a cache. Teams that treat their own database as authoritative eventually sell a seat the airline has already cancelled.
This article is general information about travel technology and online marketing. It is not legal, tax or financial advice, and advertising platform policies change often. Check the current policy documents and take professional advice for your own situation.