AI agents for corporate travel and expense: automating T&E without losing policy control

The AI agent that plans your vacation gets the magazine covers. The one that files your expense report gets the budget. We wrote separately about the consumer travel agent — the one that has to book a real seat at a real fare without inventing either — and the trust problem that gates it. This post is about the other travel agent, the one that lives inside the enterprise: the system that books a trip within corporate policy, reconciles it against a card feed, and turns the shoebox of receipts into a coded, audit-ready expense report without a finance analyst touching it.

It’s a less glamorous problem and a bigger near-term prize. Corporate travel and expense (T&E) is a workflow of exactly the kind agents are good at — high-volume, rule-bound, repetitive, and spread across three systems that don’t talk to each other (you book in one tool, pay with a card in another, expense it in a third, and finance codes it in a fourth). The 2026 crop of finance and travel platforms has aimed agents squarely at that seam, and the results are real enough to plan around. The catch is that T&E has two failure modes a chatbot never faces — an agent can commit real money and an agent can approve its own bad judgment — so the architecture that makes it safe is the whole story.

The drudgery the agent is actually attacking

Start with where the time and money leak, because that’s what the agent is being pointed at:

• Booking leakage. Travelers book outside the approved channel constantly — the Skift/Navan State of Corporate Travel and Expense 2026 found that a large majority book off-platform at least some of the time. Every off-channel booking loses a negotiated rate, breaks duty-of-care visibility (you don’t know where your people are), and creates manual reconciliation later.
• Manual expense reports and receipt matching. Itemizing, coding to the right GL account, matching each receipt to a card transaction — this is the archetypal knowledge-worker tax. And human audit doesn’t scale: expense-audit vendor AppZen notes that traditional manual review samples only about 10–20% of reports while its AI reviews 100%. Whatever you think of the vendor’s framing, the gap it’s describing is real: most expense reports are never actually checked.
• Approval bottlenecks. A manager rubber-stamping in-policy lunches is a waste of a manager; the exceptions are what deserve eyes.
• Fraud and duplicates. Cross-report and cross-card duplicate submissions, and — newly — AI-generated fake receipts, which surged through 2025–2026 and defeat naive “does the receipt look real” checks. The fraud side is now an AI-versus-AI problem.
• VAT reclaim and duty of care. Recoverable input VAT that never gets reclaimed because the line-item data isn’t captured; travelers stranded by disruption because nobody was watching their itinerary in real time.

Each of these is a place where a bounded agent — one that can read the systems, apply the rules, and act within limits — plausibly beats both the status quo and a rigid RPA script. Which class of automation fits is worth deciding deliberately rather than defaulting to “agent” because it’s the word of the year; T&E happens to be one of the cases where the agent genuinely earns it, because the work needs judgment (is this expense reasonable?) that a decision tree can’t encode.

The architecture: an intent layer over a deterministic execution layer

The single most important pattern to internalize — and the one the serious vendors have converged on — is the separation of reasoning from committing. An LLM is excellent at understanding “book me the 8 a.m. to Chicago, aisle, under policy” and terrible at being the system of record for whether that booking actually happened. The clearest statement of this came when Travelport built TripServices and connected 400+ European agencies to a deterministic booking API through the Model Context Protocol: the language model interprets intent; a structured API executes the transaction. The reason is blunt — AI systems have returned “confirmed” for bookings that were still pending and generated card charges nobody authorized. A model’s internal representation of “I booked it” is not a booking.

So the reference architecture has two layers, and the boundary between them is where safety lives:

The reasoning/intent layer — the agent that understands the request, searches options, checks them against policy, drafts the expense report, and decides what needs a human. This is where the LLM belongs.

The deterministic execution layer — the tool surface that actually does things, each call structured, logged, and verifiable:

• Booking/distribution: GDS content and, increasingly, IATA’s NDC offer/order APIs for richer fares and ancillaries. Suppliers are exposing these to agents directly — Sabre fronted agentic APIs with an MCP server, and Amadeus is co-developing a lodging-focused Universal Commerce Protocol with Google.
• Card and finance data: corporate card feeds with Level 2/3 line-item detail, and virtual card numbers mapped one-to-one to a booking so reconciliation is automatic and the line-item data needed for VAT is captured at source.
• Receipt extraction: OCR plus inference — SAP Concur’s ExpenseIt now embeds a Joule Receipt Analysis Agent that infers missing fields (vendor, location, expense type) from context and history.
• Policy-as-code: the travel and expense policy compiled into machine-checkable rules the agent evaluates at the point of booking or swipe. Ramp, for instance, lets a customer upload a policy document and has the agent build a reasoning graph that makes approval decisions against it.
• ERP/finance posting: the coded, approved result exported to the expense and GL systems.

The Model Context Protocol keeps showing up here for a reason: it’s becoming the standard connective tissue between agents and travel-tech systems, which is what lets one agent reach many suppliers without a bespoke integration per carrier. Underneath the vocabulary, though, the architecture is the same lesson as every other production agent — the agent is mostly orchestration over messy enterprise plumbing, and it’s only as truthful as the live systems it’s forced to read from.

What the vendors actually ship (and how to read their numbers)

The 2026 landscape is real products, not slideware — but the metrics are vendor-reported, so treat them as claims, not benchmarks.

• Navan runs Navan Cognition, a network of specialist agents (booking, expense, support, compliance) over a unified T&E data core, plus Ava (the traveler assistant) and a Waiver Agent that monitors airline waivers in real time and proactively nudges travelers to rebook before they’re stranded. Navan describes an architecture aimed at “zero critical hallucinations” using layered agents, AI supervisors, and combined rule-based and LLM checks — a useful design pattern to study regardless of whether you buy it.
• SAP Concur is rolling out Joule agents: the Receipt Analysis Agent above, an Expense Automation Agent that acts as a virtual delegate building the report for the employee to review before submitting, and a Pre-Submit Audit Agent. The “human reviews before submit” framing is the tell — Concur is keeping a person on the commit.
• Ramp and Brex attack the finance side. Ramp’s controller agents auto-approve low-risk, in-policy spend and escalate exceptions; Brex describes an audit agent that categorizes violations by risk and a review agent that auto-clears the low-risk and escalates the rest. Both publish high automation percentages; both were recognized in IDC’s 2025 MarketScape for AI-enabled T&E. Read the percentages as “here’s the shape of what’s automatable,” not as a guarantee for your policy corpus.

The common thread across all of them is the one worth copying: auto-clear the low-risk majority, escalate the exceptions to a human. That’s not a limitation they haven’t engineered away yet — it’s the correct design.

The two hard problems

Everything above is plumbing. Two problems are where T&E agents actually succeed or fail.

Problem one: the agent must not invent a fare, a policy, or a confirmation. A model asked for a price will happily produce a plausible one; independent testing of consumer travel chatbots has found them quoting fares well off the real number, in both directions. In a corporate context an invented fare is a broken travel budget and an invented policy is worse — an agent that confidently tells a traveler business class is allowed when it isn’t creates a compliance mess and an angry expense reviewer. The defense is grounding plus the deterministic layer: the agent may search, compare, and summarize, but price, availability, fare conditions, taxes, cancellation terms, and what policy actually says must be pulled from authoritative live systems at decision time and labeled system-verified, never generated. This is the same grounding discipline that separates every production agent from every demo.

Problem two: who authorized the money. The moment an agent can book and pay, you inherit a PCI and liability question a copilot never had: prove that the human actually authorized this purchase, at this price, for this trip. The emerging answer is Google’s Agent Payments Protocol (AP2), announced in September 2025 with 60+ partners including Mastercard, PayPal, Amex, and Salesforce, which uses three cryptographically signed “mandates” — Intent, Cart, and Payment, expressed as verifiable credentials — to carry proof of authorization through an agent transaction. Pair that with virtual cards that scope each charge to a booking, and keep card data in tokenized, PCI-scoped rails rather than in the model’s context. This is the corporate cousin of the delegated-payment problem in agentic commerce: the agent transacts, but the authority to transact has to be provable, bounded, and revocable.

Both problems point the same direction on autonomy. Receipt extraction, report drafting (with human review before submit), auto-approval of low-risk in-policy spend, and proactive disruption monitoring are safe to run with high autonomy. Out-of-policy spend, fraud-flagged items, and the final financial commitment of a booking are where a human belongs in the loop — not because the agent can’t act, but because those are the actions that are expensive to reverse.

Where Salesforce fits — and where it doesn’t

Because this is a Salesforce shop, the honest map matters more than the optimistic one. Salesforce does not ship a GDS/NDC booking engine, it doesn’t issue corporate cards, and it doesn’t run receipt-OCR expense audit. Anyone telling you Agentforce natively books trips or audits expenses is overclaiming. A T&E platform — Navan, Concur, Ramp — owns that core.

What Salesforce genuinely does well sits around the T&E platform:

• Traveler service and support. A travel program runs a service desk — policy questions, “my flight got cancelled, what are my options,” approvals stuck in a queue. That’s Agentforce’s home turf: case deflection and policy Q&A grounded in your own data via Data 360 retrievers, deployed on the channels employees already use.
• Approval orchestration. Routing a travel or expense exception to the right approver with the right context is native Flow territory — Salesforce even ships a Trailhead pattern for a travel-approval data model — and an Employee Agent can sit in front of it.
• Duty-of-care workflows. When disruption hits, the service and case machinery that reaches affected travelers and coordinates a response is exactly what Service Cloud plus an agent is built for.
• Authorized payments. Salesforce being an AP2 launch partner matters if agent-initiated spend ever touches the CRM side of your stack.

The realistic pattern is integration, not replacement: the T&E platform books and reconciles; Salesforce grounds the traveler-facing service, orchestrates the approvals, and handles the duty-of-care response — wired together over APIs. Getting that boundary right is most of the architecture work, and pretending one platform does all of it is how these projects end up disappointing.

What to actually do

Don’t start by trying to automate the whole T&E lifecycle end to end. Start where autonomy is safe and the pain is loud: expense-report drafting with human review, and auto-approval of the low-risk in-policy majority so approvers only see exceptions. Insist on the two-layer architecture from day one — reasoning in the model, commitment through deterministic, logged APIs — because retrofitting that boundary after an agent has already generated a phantom confirmation is a bad week. Ground every fare, policy, and total in a live system and label it verified; never let the model be the source of a number or a rule. And decide the payment-authorization story — AP2 mandates, virtual cards, tokenized rails — before an agent ever touches a checkout, not after.

The travel budget is one of the largest controllable line items in most enterprises, and T&E is one of the most-hated workflows employees touch. An agent that clears the low-risk 90% and escalates the rest — bounded by real policy, grounded in real fares, committing through real APIs — is one of the more defensible enterprise-automation bets on the board right now. Just remember which travel agent you’re building: not the one that dreams up a vacation, but the one that keeps the trip inside the lines and the receipts in order.

Understanding the basics

What can an AI agent actually automate in corporate travel and expense?

Realistically: booking within policy (searching options, checking them against corporate rules, and holding or booking through a supplier API), receipt extraction and expense-report drafting, auto-approval of low-risk in-policy spend with exceptions escalated to a human, card-to-booking reconciliation, duplicate- and fraud-detection, and proactive disruption monitoring. What stays with a human is the exceptions, out-of-policy spend, fraud-flagged items, and the final financial commitment of a booking. The pattern across the leading vendors is the same: clear the low-risk majority automatically, escalate the rest.

How do you stop a travel agent from inventing a fare or a policy?

By separating reasoning from execution and grounding every fact. The agent can search, compare, and summarize, but price, availability, fare rules, taxes, cancellation terms, and the corporate policy itself must be pulled from authoritative live systems at decision time and treated as system-verified, never generated by the model. Bookings must be committed through a deterministic, structured API — not inferred from the model’s own belief that it booked something — because AI systems have returned false “confirmed” statuses and generated unauthorized charges when the commit was left to the language model.

Does Salesforce Agentforce do travel and expense?

Not the core of it. Salesforce doesn’t ship a booking engine, issue corporate cards, or run receipt-OCR expense audit — a dedicated T&E platform like Navan, SAP Concur, or Ramp owns that. Agentforce fits around it: traveler service and policy Q&A grounded in Data 360, approval orchestration through Flow, and duty-of-care workflows during disruption, integrated with the T&E platform over APIs. The right design is Agentforce alongside a T&E system, each doing what it’s built for — not Agentforce pretending to be the booking and expense engine.

---

Mapping where an agent fits in your travel and expense stack — and where Salesforce should sit next to your T&E platform rather than trying to replace it? Talk to us — drawing that boundary and grounding the agent in real systems is the work we do.