The modern TMC technology stack: booking, mid office, back office and AI

A TMC technology stack has four layers: booking, where content from the GDS, NDC and direct connections reaches a booking tool; mid office, where quality control, policy and ticketing happen; back office, where invoicing and reconciliation happen; and an AI layer that sits across all three. The layers are well understood. The joins between them are where TMCs lose money.

Key takeaways

• 30% of corporate buyers were actively reevaluating or changing their TMC, and 39% named dissatisfaction with technology as the main reason (GBTA, February 2025). Your stack is now a retention issue.
• Four layers, three joins. Most stack problems live in the joins, not inside any single system.
• There is one question that predicts stack quality better than any feature list: when two systems disagree about a booking, which one is right? Most TMCs cannot answer it.
• Count every point where a human re-keys or re-exports data between systems. That count is your stack score, and it is the number to reduce.
• AI agents are not a fourth layer. They are an interface onto the other three, which is why a fragmented stack cannot support them.

What does a TMC technology stack actually include?

Four layers, and every TMC runs all four whether or not anyone has drawn them. Booking is where travel content becomes a reservation. Mid office is where that reservation gets checked and ticketed. Back office is where it becomes money. The AI layer is newest and sits across the other three rather than beside them.

A modern TMC is in practice a technology aggregator rather than a technology owner. Most of these layers are bought, and the differentiation is in how well they are joined.

Two things the stack is not. It is not a single product, despite how it gets sold. And it is not static: the GDS was the only content source for decades, and now it is one of several.

The reason this matters commercially has changed recently. Technology used to be an internal efficiency question. Now it is a retention question. GBTA found in February 2025 that 30% of corporate buyers were actively reevaluating or changing their TMC, with 39% naming dissatisfaction with technology as the primary driver.

Layer 1: Booking, from GDS and NDC to the OBT

The booking layer turns travel content into a reservation. It has two halves that are easy to confuse: where the content comes from, and where the booking gets made.

Content arrives from several places now. The GDS still carries most air content and remains the system most agency workflows are built around. NDC connections carry airline-direct content and ancillaries the GDS does not always expose. Low-cost carriers, hotel bedbanks, rail and direct connections each arrive on their own terms.

The booking surface is where that content gets presented. An online booking tool, or OBT, is the corporate-facing screen a traveller uses. An internet booking engine, or IBE, is the self-service engine a TMC puts behind its own brand. Agents book through the GDS directly or through an agent desktop.

One distinction worth being precise about. An OBT is the screen, not the machinery behind it. It is a front-end bound to the PNR structure and connected to a separate mid and back office that agents use. Treating the OBT as the stack is the single most common misunderstanding in corporate travel technology, and it is why buyers are often surprised by what their TMC can and cannot do.

Layer 2: Mid office, where quality control and ticketing happen

Mid office sits between the booking and the ticket. It checks that the reservation is correct before money moves, applies policy a second time as a safety net, calculates service fees, and issues the ticket.

The specific jobs are narrow and high volume. Quality control on the PNR, checking formats, missing fields and ticketing time limits. Policy checking against the traveller’s grade. Fare re-shopping inside the rebooking window. File finishing and itinerary distribution. Automated ticketing for anything in policy. Mid-office automation is what drives the touchless rate, which is the proportion of bookings that reach a ticket without an agent touching them.

This layer is also where most of the automation that genuinely works already lives. The rules are known in advance, the volume is high, and a mistake is cheap to correct, which is why it automates cleanly.

Mid office is the layer most often missing or half-built in smaller TMCs, usually because its work is invisible when it is being done properly.

Layer 3: Back office, where the money is reconciled

Back office begins once the ticket exists. Invoicing, customer and supplier ledgers, BSP and card reconciliation, commission tracking, debit memo handling, and the management reporting that comes out of all of it.

This is the layer with the hardest external deadlines. Your remittance obligation to the airlines runs on a published calendar that does not wait for your clients to pay you, and the volumes involved are substantial: ARC alone processes over $100 billion in US agency air sales annually.

It is also the layer that produces client reporting. For a TMC that matters more than it sounds, because the spend analysis an account manager presents at a review is generated from back office data. Clean data produces a report. Messy data produces two days of spreadsheet work per account per quarter.

Back office is not a replacement for accounting software. The pattern that works is travel-specific reconciliation exporting cleanly into a general ledger package.

Layer 4: AI agents, and why they are not really a layer

AI is usually drawn as a fourth box on top of the other three. That is misleading, and the misunderstanding causes real procurement mistakes.

An AI agent does not hold data or own a process. It reads state from the layers beneath it and acts on them. An agent that reads an inbound travel request, extracts the dates and travellers, checks the policy and returns a quote is doing nothing the stack could not do. It is removing the human who used to move information between the layers.

Which produces an uncomfortable consequence. If your three layers do not share state cleanly, there is nothing for an agent to read. A stack where the booking tool does not feed the mid office, and the mid office does not feed the back office, cannot support agents at all, no matter what is bought.

This is why AI has exposed stack problems that felt tolerable for years. Humans are extremely good at compensating for bad joins. They copy, re-key, check twice and remember context. Agents cannot do any of that, so the join quality that a team quietly absorbed becomes a hard blocker.

The practical reading: AI readiness is not an AI question. It is an integration question wearing a different hat.

How TMC systems connect from booking to accounting

Four layers means three joins, and the joins are where the work actually breaks. Here is the path a single booking takes.

Step	Moves from	To	What usually goes wrong
1	Content sources	Booking tool	Content gaps, NDC not supported in the same flow as GDS
2	Booking tool	Mid office	PNRs arrive without the data the checks need, or arrive late
3	Mid office	Back office	Service fees and policy outcomes do not carry through
4	Back office	Accounting	Export rather than integration, reconciled by hand

The most common failure mode in a TMC stack is fragmentation: a booking engine that does not share data with the booking tool, and a booking tool that does not feed the back office. Every join that fails gets patched by a person, and that person becomes load-bearing.

Notice the pattern in that table. Nothing in it is a product failure. Each layer may be working exactly as sold. The failure is at the boundary, which is precisely where no single vendor is accountable.

The question most TMCs cannot answer

Here is a question worth putting to your own operations team this week. When the GDS and the back office disagree about a booking, which one is right?

Most TMCs cannot answer it, and the hesitation is the finding. It means there is no agreed system of record, which means every disagreement gets resolved by whoever is looking at it, using judgement rather than a rule.

The symptoms are familiar. Two versions of the same spend figure arriving at a client review. A refund that exists in one system and not another. A reconciliation that balances only after someone adjusts something manually and does not write down why.

The fix is not technical. It is a decision. Name one system as authoritative for each type of fact: the GDS for what was booked, the mid office for what was checked and ticketed, the back office for what was invoiced and owed. Then make every other system a reader of those facts rather than a second author of them.

This costs nothing and it is the single highest-return thing most TMCs could do to their stack. It also has to happen before any agent is deployed, because an agent asked to read from two systems that disagree will confidently pick one.

How to measure your stack: count the handoffs

Feature comparisons do not tell you whether a stack is good. Handoff counts do.

Take one booking of each type you handle: a simple point-to-point, a multi-city, a reissue, and a refund. Walk each one from request to invoice. Every time a person re-keys information, exports a file, copies a reference number or opens a second system to check something, make a mark.

That total is your stack score. Lower is better and the number is usually higher than anyone expects, because each individual handoff feels trivial to the person doing it.

Three things this measurement does that a feature list cannot. It finds the joins rather than the layers, which is where the problems are. It is comparable over time, so you can tell whether a purchase actually worked. And it is honest about the exceptions, since the reissue and refund walks will produce far higher counts than the simple booking, and that gap is your real automation opportunity.

Run it once a year and before any major purchase. If a vendor cannot tell you which handoffs their product removes, they are selling a layer rather than a join.

How to build a TMC technology stack without replacing everything

Full replacement is how these projects fail. The realistic approach is to fix joins in a fixed order and leave working layers alone.

Name your systems of record first. Costs nothing, blocks nothing, and every later decision depends on it.

Fix the mid office to back office join next. This is where service fees, policy outcomes and ticketing data either carry through or get re-entered. It is also upstream of reporting, so fixing it improves client-facing output without touching anything client-facing.

Then the booking to mid office join. Harder, because it often means changing how PNRs are queued and what data they carry.

Then the back office to accounting join. Ask for a named integration rather than a CSV export.

Add agents last. Not because they are unimportant, but because an agent deployed onto broken joins produces fast, confident errors, and the team will conclude the technology does not work.

One caution on single-vendor stacks. Buying all four layers from one provider does solve the join problem, and it moves your risk from integration to dependency. Neither answer is universally right. What is wrong is choosing without noticing the trade.

Where VantisCorp fits in the stack

We build the mid office, back office and booking layers for TMCs, white-labelled, so your corporate clients only ever see your brand. Being specific about which parts, since that is the point of this article.

Booking. A hotel booking engine with supplier connections across bedbanks, wholesalers and channel managers, and room mapping so the same property from four suppliers appears once rather than four times.

Mid office. PNR quality control, automated ticketing of in-policy bookings, file finishing, itinerary distribution and reissue queue routing.

Back office. Invoicing generated from the booking record, reconciliation with exception reporting, commission tracking, ledgers and client reporting. It exports into your accounting package rather than trying to replace it.

AI. A booking agent that reads corporate travel requests from an inbox, checks them against the traveller’s grade and budget, and returns flight and hotel options as a quote. This is the only part of our platform that is AI. The mid office and back office are conventional automation and we do not describe them otherwise, whatever the rest of this market has started calling rule-based processing.

On the joins, which is what this article argues actually matters: the booking engine, mid office and back office read from the same records, and we integrate outward to Zoho Books, Zoho CRM, Zeal CRM, Zeal Desk, Stripe, Razorpay, Gmail and Outlook rather than asking you to export.

Frequently asked questions

What technology stack does a TMC need?

Four layers: a booking layer connecting content sources to a booking tool, a mid office for quality control and ticketing, a back office for invoicing and reconciliation, and an AI layer that reads across the other three. Every TMC runs all four whether or not they have been formally chosen.

What is the difference between an OBT and an IBE?

An online booking tool is the corporate-facing screen employees use to book within policy. An internet booking engine is the self-service booking engine a TMC runs under its own brand. Both are booking surfaces, and neither is the full stack behind them.

Should a TMC buy one integrated platform or best-of-breed systems?

A single platform removes the integration problem and creates a dependency. Best-of-breed keeps your options and leaves you owning the joins. The mistake is not picking either one, it is picking without pricing the trade-off.

How do TMC systems connect from booking to accounting?

Content reaches a booking tool, the booking creates a PNR, the mid office validates and tickets it, the back office invoices and reconciles it, and the accounting package takes the result. Three joins, and most problems live in them rather than inside any one system.

Do we need to replace our GDS to modernise?

Usually not. Most modernisation work happens in the mid office, back office and the joins between them, with the GDS left in place as a content and booking source.

What should a TMC automate first?

Mid office quality control and ticketing. High volume, rule-bound, cheap to correct when wrong, and upstream of everything else, so automating it improves the data that reporting and reconciliation later depend on.

Conclusion

Stop evaluating your stack as four products and start evaluating it as three joins. Name a system of record for each type of fact, count the handoffs on one booking of each type, and fix the mid office to back office join before anything else. Add agents last, because an agent deployed onto broken joins produces confident errors faster than a person would. Technology has become a reason corporate clients leave rather than an internal efficiency question, which means the joins are now a retention problem as much as an operational one.