A corporate booking does not begin and end at the moment a traveller clicks "confirm". From the first search to the final reconciled payment in the TMC's account, a single booking passes through roughly seven distinct stages — and at each one, something specific happens, something specific can go wrong, and the TMC faces a specific decision. Most discussions of travel technology describe these stages from thirty thousand feet: a booking "flows through the system". This article does the opposite. It walks the whole route at ground level, one stage at a time, showing the mechanism, the failure mode, and where the TMC adds or loses value at each step.
This is a map of the whole journey. Each stage links to a deeper article on that specific topic, so you can read the overview here and dive into any single stage when you need the detail. The throughline is simple: a booking is only as profitable as the weakest stage it passes through, because a failure at any stage costs money or trust downstream.
Stage 1: Search and Content
The journey starts with a search. What the traveller sees as a tidy list of flight and hotel options is the visible surface of a content layer underneath: inventory aggregated from one or more GDSes, NDC content from airlines, low-cost carrier content via an aggregator, and direct hotel APIs. The completeness of that content determines whether the traveller sees the genuinely best option — or only part of the picture. This is where the travel booking engine does its work, drawing on GDS and NDC content sources.
Stage 2: Policy Check at the Point of Booking
As the traveller selects an option, the system checks it against the corporate client's travel policy in real time: fare class, hotel rate cap, advance-purchase window, preferred suppliers. An in-policy booking is marked compliant; an out-of-policy booking is flagged before it proceeds. The critical word is "before" — policy enforcement only works at the point of booking, not after the trip. How this enforcement actually works, and why post-trip flagging is reporting rather than enforcement, is covered in Why Travel Policy Compliance Fails And How to Fix It.
Stage 3: Approval
A booking that needs sign-off routes to an approver. Mature programmes use a hybrid model: in-policy bookings are passively approved and flow straight through, while out-of-policy bookings are actively routed to a human. Multi-level chains, delegation, and clear approval status all live here. The depth of this stage — and why approval design is really a corporate booking tool decision — is covered in Corporate Booking Tool: A TMC's Guide for 2026.
Stage 4: Ticketing
Once approved, the booking is ticketed: the reservation becomes a confirmed ticket against a PNR (for GDS bookings) or an Order Reference (for NDC bookings). Every fare carries a ticketing deadline, and auto-ticketing controls decide when the system issues directly versus when an agent must intervene. This is also where the GDS-versus-NDC distinction starts to matter operationally, because NDC tickets are serviced differently — see NDC Fares: An Operational Decision Framework for TMCs.
Stage 5: Invoicing and Billing
With the ticket issued, the booking becomes a financial transaction. The PNR or Order Reference is converted into billable items — fare, taxes, fees, service charges, markup — and an invoice is generated. This is the first stage handled by the mid-back office rather than the booking front-end, and the handoff between them is one of the most common points of data loss. The mechanics of this conversion are covered in What Is a Mid-Back Office System for Travel Agencies?.
Stage 6: Settlement and Reconciliation
Every ticket issued has to be reconciled against BSP or ARC sales reports, and refunds, voids, and ADMs (Agency Debit Memos) tracked against the original transaction. Multi-GDS agencies multiply this work because each GDS settles separately. This is where a weak back office costs real money, and the reconciliation mechanics — including how mixed GDS and NDC bookings complicate the picture — are detailed in What Is a Mid-Back Office System for Travel Agencies?.
Stage 7: Reporting and Profitability
Finally, structured records flow into the agency's accounting system and management dashboards: sales by route, by client, by supplier, and profitability per booking. This is what turns a year of transactions into commercial intelligence — and it is only possible if the previous six stages produced clean structured data. The reporting and accounting-integration layer is covered in the mid-back office article, and the link between captured data and realised savings is explored in Business Travel Savings: How TMCs Help Corporate Clients Cut Costs.
Where the Chain Breaks: The Cost of Disconnected Stages
Read the seven stages together and a pattern emerges: the risk is rarely within a stage — it is at the handoffs between them. A booking engine that does not pass clean data to the approval layer; an approval that does not feed the ticketing queue; a ticket that does not flow into invoicing; an invoice that does not reconcile automatically. Each handoff that requires a manual export and re-import is a point where data is lost, delayed, or corrupted. The cumulative cost of these disconnects — not the cost of any single stage — is what separates a TMC that scales profitably from one whose margins erode as volume grows.
This is the core argument of Digital Transformation in the Travel Industry: What It Means for TMCs.
Asia-Pacific Realities Across the Lifecycle
Each stage carries an Asia-Pacific complication that systems built for single-market programmes tend to miss:
• Search — regional LCCs (AirAsia, Scoot, Cebu Pacific, VietJet) carry a large share of point-to-point travel and need aggregator integration to appear at all.
• Policy and approval — multi-timezone approval chains shrink the effective window before a ticketing deadline; an approver in another country may not see a request until the deadline is near.
• Ticketing — dual GDS setups (common in the region) mean tickets issue across more than one settlement system.
• Invoicing — country-specific tax and e-invoicing rules (Singapore GST, Malaysia SST and e-invoicing, Indonesian VAT, Indian GST) each require correct invoice formatting.
• Settlement — multiple IATA BSP countries, multiple currencies, and local payment methods each settle and refund differently.
• Reporting — multi-branch, multi-currency operations need clean separation in reporting without losing the consolidated view.
How the SWIFT Stack Covers the Lifecycle
Forecepts builds the stages as connected modules: SWIFT IBE handles search and content (stages 1 and the front end of 4); SWIFT CBT handles policy check, approval, and corporate booking (stages 2-3); and SWIFT Mid-Back Office handles invoicing, settlement, reconciliation, and reporting (stages 5-7). Because the modules share data, the handoffs that break disconnected stacks are automated. Other approaches exist; the point is that the stages must connect, however a TMC assembles them.
