Modern Airline Retailing fundamentals. A series of short explainers on MAR — the terminology, the structure, and what changes when airlines move from PNRs to orders.
Of all the concepts in the OOSD world, delivery status codes matter most if you're building or operating a Departure Control System (DCS). They're not glamorous, but they are the thing that the "Deliver" part of Offer, Order, Settle, Deliver actually turns on.
What delivery status codes are
Every service on an order has a delivery status code. The codes represent where that service is in its lifecycle, from purchased through to delivered. The sequence looks roughly like this (depending on the carriers and their revenue accounting preferences):
- When something is paid for, it moves to Ready to Proceed
- When a passenger checks in, it moves to Ready to Check In
- When a passenger boards, it moves to In Progress
- When the flight is marked as flown, it moves to Delivered
The core job of a delivery management system, the canonical thing it does, is to update these status codes. That's the delivery function. Everything else that a DCS does (manage my booking, documents, ancillary purchases, seat changes) is built around that central mechanism.
Individual and batch updates
Status changes can happen in two ways. The most common is that when a passenger boards, the delivery status updates simultaneously for every service on their order: the right to fly, the seat, the baggage allowance, everything moves together.
But status changes can also be triggered individually, for specific services. When a passenger uses lounge access, the system sends a USNRQ (Update Service Notification Request) to update the delivery status specifically for the lounge service. You can do the same for meals, for retail add-ons, for any service where you want granular tracking rather than a batch update at boarding.
There's also an SSCN (Service Status Change Notification) that does a similar job, though SSCNs are expected to be deprecated in favour of USNRQs over time.
Why this matters commercially
Delivery status codes are central to revenue recognition — OrMS knows what's been delivered and can reconcile accordingly. But they're also what make continuous retailing possible.
Because the system is API-based, retailing doesn't stop at check-in. A passenger can upgrade while waiting to board. They can change their seat after check-in. A retail offer can surface in an app at the gate. Every one of those transactions creates a new order item, and the delivery status of each one is tracked through the same mechanism.
For airlines, that's significant. It means the revenue opportunity stays live throughout the entire passenger journey, not just at the point of booking.
Q: Does the status update happen automatically when someone boards, or does the system have to trigger it?
It can work both ways. A boarding event typically triggers a batch status update across all services for that passenger. But for services like lounge access, where you want to record the specific moment of use, you'd send an individual USNRQ at that point. The system can be as granular as you need it to be.
Q: Is this how the airline proves what was and wasn't delivered for reconciliation purposes?
Exactly. The delivery status code sequence provides an auditable record of what was provided. It's designed with revenue recognition in mind — the airline has a record, per service, per passenger, of what was delivered and when.