How three vendors connect Offer, Order, Delivery and Settlement without a monolithic stack.
Airline retailing is often described as a future destination. Offer–Order–Delivery–Settlement (OODS) has four domains that are meant to be loosely coupled yet tightly coordinated. In this joint project, Turkish Technology, Ink Innovation and Sutherland demonstrate what that looks like when it is no longer theory.
The same Order flows across three systems. Turkish Technology handles the commercial side of Turkish Airlines. Ink runs the airport operation. Sutherland recognises revenue based on what has actually been delivered.
How an end-to-end OODS flow behaves as a single journey
Offer. Turkish Technology builds the product and the price
The airline commerce front end presents a contextual offer. A family itinerary with flights, bags, sports equipment, lounge or bundle options. The traveller sees one combined proposition that fits their trip.
This is the Offer domain. The airline controls products, pricing and rules. The offer is built from a product catalogue and a stock keeper that know:
- what can be sold on this route and carrier
- which combinations are allowed
- how ancillaries attach to flights and passengers
Nothing in this step depends on airport systems or accounting. It is a clean Offer layer that any compatible Order system can consume.
Order. Turkish Technology turns acceptance into a single record
The customer accepts the offer and makes the payment. Behind the confirmation sits an Order with flights as one order item, each ancillary as an explicit entitlement, with a clear linkage between passengers, segments, and services.
This is the Order domain. Order is the one place that knows what has been promised. It is built according to modern retailing standards, allowing it to be shared.
From here, the airline exposes Order and its context through APIs. Partners do not guess what was sold or reconstruct it from tickets. They read the Order and its items.
Delivery. Ink executes the airport side against the Order
In Ink’s domain, the same Order appears. Agents see the family and their flights, pre-purchased items, and any optional services still available to offer at the airport. Delivery system enabling check-in and bag drop, performing check-in, printing tags and boarding passes, and boarding the passengers. Status lines move from “booked” to “ready”, then “in progress”, then “delivered” as each step completes.
This is the Delivery domain. Ink does not own the commercial logic or accounting. It consumes Turkish Technology’ Order and emits operational events.
For each action at the airport, Ink updates the delivery status and sends those updates back to the airline. The sequence is simple:
- when airport handling can start, services move from “planned” to “ready”
- when check-in, bag-drop and boarding happen, they move into “progress”
- when the flight is closed after arrival, they move to “delivered”
Turkish’s own view and the customer app are refreshed from these delivery events. Commercial, operational and customer channels stay aligned on the same Order state.
Settlement. Sutherland uses Delivery events to recognise revenue
In Sutherland's finance platform, the same Order appears. Accountants see each line item, with its contract price, associated delivery events, and current recognition status. The accounting system tracks whether revenue remains deferred or has been earned through delivery completion. Revenue lines move from "deferred" to "recognised" as delivery events confirm fulfilment.
This is the Settlement domain. Sutherland does not own the operational logic or delivery execution. It consumes the Order and delivery events shared by the Order Management platform.
Accounting sub-ledgers, financial reports and audit trails are built from these same delivery events. Commercial agreements, operational execution, and financial books remain aligned on the same Order state, providing airlines with real-time revenue recognition and continuous financial visibility as the supply chain executes.
Lessons learned
Turkish Technology team:
“The collaboration with Ink and Sutherland demonstrated that Turkish Technology’s modular and standards-driven OOSD modules can deliver a fully integrated retailing journey without relying on legacy systems. By exposing clean, IATA-aligned Order APIs, we enabled partners like Ink and Sutherland to plug into the same source of truth and operate consistently across Delivery and Settlement. The agility of our in-house platforms—spanning offer creation, order management, product catalogue, stock handling, and our Dual Mode Adapter was evident in the speed, flexibility, and control they provided throughout the successful end-to-end workflow. The Concept Channel App also proved valuable as an innovation sandbox, allowing us to validate ideas before scaling them into real integrations. Ultimately, the project reaffirmed that modularity, interoperability, and adherence to industry standards are key enablers for building a future-ready, partner-friendly airline retailing ecosystem.”
What this OODS flow proves
Offer and Order can work as a module
An airline can own the Offer and Order domains and still share what matters with partners. The product catalogue, pricing and order structure are exposed cleanly via APIs. Any delivery system that understands the model can plug in.
Delivery is a separate, swappable layer
Delivery focuses on executing services at the airport. Because it works from the Order, not from a proprietary local record, it can sit behind any standards-aligned Order system. If the airline changes its Offer or Order provider, the Delivery layer does not have to be rebuilt from scratch.
Settlement uses events
The accounting system does not try to infer revenue timing from timetables or ticket coupons. It listens to delivery events that reflect what actually happened to each service. Accounting is driven by real fulfilment, not by assumptions.
Multi-vendor. One OODS flow
No single vendor is running the full stack. Offer–Order–Delivery–Settlement is implemented by different providers, joined by contracts and APIs. The flow still behaves as one coherent system.
For an airline, that is the core. An end-to-end OODS architecture is achievable today with a modular approach. You can start in one domain, plug in partners in the others, and extend from “offer” all the way through to “settled in the ledger” without a big replacement.
Author
