Executive summary: Airline IT is routinely mocked as legacy cruft, but its strangeness is the residue of solving a problem no ERP or CRM ever had: making a ticket sold by one competitor honorable, flyable, and financially settleable by another, with no shared database, decades before distributed systems existed. The paper ticket was a bearer instrument, the e-ticket was its deliberate digital replica, and every "weird" structure in the stack (PNRs, coupons, EMDs, filed fares) traces back to that constraint. Understanding why the old model was the right call is the fastest way to plan the migration away from it, because IATA's ONE Order standard must solve the same problems with new machinery.
Coupon status FLOWN is not a database design decision. It is a torn piece of paper, digitized, and then treated as accounting truth for decades. This article is about why that was a reasonable thing to do, and what it means for the IT leaders now asked to replace it.
The constraint with no enterprise analogue
In an ERP or a CRM, your data model is your private concern. You can refactor it, migrate it, or ruin it, and the only people affected work for your company.
An airline ticket is not like that. A ticket sold by Lufthansa in Bucharest can be flown on United, rebooked by an agent in Tokyo, rerouted onto Air Canada during a disruption, and settled between all of them weeks later. This is interline: the system of multilateral agreements that lets a passenger buy one journey across competing carriers. And it imposes a brutal requirement. Carrier B must honor and account for something carrier A sold, without querying carrier A's database.
The solution the industry converged on was to make the ticket a bearer instrument of value: self-contained, self-describing, parseable by parties with no access whatsoever to the issuing system. Everything the downstream carrier, agent, or clearing house needed had to travel inside the document itself.
That is a distributed-systems solution, invented before distributed systems existed. The corollary is just as important: the format had to be agreed by hundreds of airlines, thousands of agents, the distribution systems, and the clearing houses. Airline data standards are not an architecture problem. They are a multilateral treaty problem that happens to produce schemas.
The paper lineage: Warsaw 1929 to a torn coupon
The lineage is older than computing. The Warsaw Convention (1929) legally defined the passenger ticket as a document the carrier must deliver, with mandated particulars: origin, destination, stops, and the carrier's identity. A carrier that flew a passenger without delivering a compliant ticket lost its liability protections. The ticket was a legal object before it was a data object.
Physically, it was a booklet. Each leg of the journey had a flight coupon; the gate agent tore out the coupon for the segment being flown. There were additional coupons for the agent, the auditor, and the passenger. The torn coupon was physical evidence that the service had been delivered, and it was shipped to revenue accounting to trigger settlement between carriers.
That mechanism, tear paper, forward paper, settle money, is the ancestor of every coupon-status field in every airline system today. OPEN, FLOWN, EXCHANGED, REFUNDED: the lifecycle of a piece of paper, encoded.
When electronic ticketing finally arrived, it was built as a deliberately faithful electronic replica of the paper booklet. The e-ticket kept coupons, kept statuses, kept the accounting semantics, because that was what made it acceptable to regulators, agents, clearing houses, and the other 200-plus carriers who had to honor it. The Montreal Convention (1999) made the replica legally possible, allowing "any other means which preserves the information" to replace the paper document. IATA then drove the industry to 100% electronic ticketing in its billing and settlement markets by 1 June 2008, one of the great coordinated migrations in commercial history.
Notice what did not change in 2008: the data model. The industry digitized the paper, not the concept.
The coordination trap: why nobody could move first
The obvious engineering question is: why did nobody just build a better model? The answer is the most underappreciated fact in airline IT.
HTTP and the web won because the first adopters got value without anyone's permission. A better protocol rewarded whoever moved first. An airline ticket is the exact opposite: it has zero value unless everyone else honors it. A single carrier inventing a superior order model gains nothing, because its "better tickets" cannot be flown on partners, rebooked by agents, or settled through the clearing house. It loses interline and gains an incompatibility. Moving first is strictly worse until the entire industry moves simultaneously.
This is why aviation works standards-first and top-down, and why that is not a bureaucratic failure but the only operating model that can work. It is also why IATA holds the pen: a competitive, fragmented, global industry needs exactly one trusted, neutral consortium to define the shared vocabulary. History handed that seat to IATA, founded in Havana in April 1945 by 57 airlines from 31 nations, successor to a Hague-based association from 1919. For its first decades IATA even coordinated international fares through its Traffic Conferences (subject to government approval), until the US Airline Deregulation Act of 1978 and the liberalization that followed pushed it toward what it is today: the standards and settlement body through which competitors safely interoperate.
The governing principle recurs through everything IATA builds, then and now: carriers keep sovereignty over their own systems; the standards govern only the interfaces between them. Centralize what must be common; federate everything else.
Three lock-ins that kept the model frozen
Even after e-ticketing, three forces kept the coupon model in place for another decade and a half.
Money. The Billing and Settlement Plan (BSP), its US counterpart ARC, and the IATA Clearing House settle enormous sums between airlines and agents, all keyed off the ticket. The 13-digit ticket number, with its 3-digit airline accounting prefix, is effectively a globally unique, routable financial-instrument identifier. Taxes, refunds, commissions, card processing, and interline proration all anchor to it. Changing the document means rebuilding global settlement while it operates.
Regulation. Consumer-protection law, EU261 compensation, and tax and customs regimes refer to "the ticket" as a legal object, some of it with treaty lineage back to Warsaw. A data-model migration in aviation is partly a legal-affairs project.
Commerce. The distribution systems' economics were built on PNR, e-ticket, and EDIFACT messaging, with fees attached to the old workflow. Modernization threatened real revenue, and the resistance was never purely technical. Beneath it all sit reservation platforms descended from 1960s SABRE, much of that lineage running on TPF-class mainframe systems whose reliability modern stacks still struggle to match, with several genuinely catastrophic reservation-system migrations in living industry memory counseling caution.
What it cost: retail ambition outgrew the data model
The price of stability was expressiveness. The model is fare-centric, not product-centric: a journey of flight coupons priced by a filed fare. That structure has no natural slot for a bundle, a subscription, a dynamically priced offer, or a third-party product. When airlines wanted to sell ancillaries such as bags, seats, and lounge access, the industry had to bolt on a second accountable document, the EMD (Electronic Miscellaneous Document), with its own coupons and statuses. Dynamic pricing fought a filed-fare structure designed for published tariffs.
By the 2010s a single trip was scattered across three constructs with three identifiers, joined mainly by coupon status:
| Construct | What it actually is | Role |
|---|---|---|
| PNR | The reservation record | Delivery: who is traveling, on which flights |
| E-ticket | The accountable document | Fulfilment: the value instrument that gets honored and settled |
| EMD | The ancillary bolt-on | Fulfilment for everything that isn't a flight coupon |
Keeping fulfilment (issuing the accountable document), delivery (providing the service), and accounting (recognizing and settling the money) in sync across those three objects is a large share of what airline IT departments actually do all day. The retail ambition outgrew the data model, and the data model could not be changed, for all the reasons above.
The reframe: a very good 1960s system, asked to do modern e-commerce
Here is the conclusion veteran airline IT people have earned the right to hear from outsiders: resist calling it legacy cruft. This system let a passenger buy one ticket across multiple competing carriers worldwide, with the money settling automatically, decades before the internet existed. It survived deregulation, globalization, and a fifty-year traffic boom. It is a very good 1960s-to-1980s system that was kept running for sixty years and then asked to do modern e-commerce.
What changed is not that the old constraint was wrong. It is that the constraint can finally be satisfied differently. IATA's ONE Order standard (Resolution 797) collapses PNR, e-ticket, and EMD into a single order record: one reference carrying the customer, the services purchased, payment, and fulfilment status through delivery and revenue accounting. That is only possible now because portability no longer requires a self-contained bearer document. It can be achieved through governed data exchange between systems that trust each other's interfaces. The first airlines are already there. Finnair created the first native airline Orders in production, Saudia has completed its move to an Orders-based platform, and the Lufthansa Group has committed to the same direction, with the industry mainstream expected to follow toward the end of the decade. We map the full standards landscape behind that shift in the airline standards map for IT leaders.
Takeaway: respect what the old model solved
If you are planning an Offers & Orders migration, the old model is your requirements document. It solved portability, settlement, and multilateral trust so well that the industry ran on it for sixty years. Your new model must solve the same three problems, just with different machinery:
- Portability: an order must be serviceable by partners who did not create it, now via governed APIs instead of a bearer document.
- Settlement: every deliverable item still needs an auditable financial lifecycle, now as order line status instead of a torn coupon.
- Multilateral trust: partners must be able to rely on your data without seeing your systems, now via standard interfaces and verifiable identity instead of standardized paper.
Migrate the constraint, not just the data. The teams that understand why coupon status FLOWN existed will design order states that accounting, partners, and regulators can live with. The teams that dismiss it as cruft will rediscover the requirements in production.
If you are working through what this shift means for your own data architecture, our travel and tourism data practice helps airlines, OTAs, and travel-tech companies get from the old model to the new one, from canonical data models to working integrations.
