Travel & expense booking agent

Business travel involves two tedious loops: finding and booking compliant trips, and afterwards turning receipts into a correct expense report. An agent now handles both. It reads a request such as "Munich to Lisbon, 12-14 Nov, client visit", searches inventory, picks options inside policy, books after approval, and later assembles the expense report from receipts and card transactions, leaving humans to approve exceptions and spending.

Problem & value

• Today: employees book via a travel portal, a travel agency or by email, often outside policy. After the trip they photograph receipts, re-key amounts, split meals, convert currencies and apply per-diems. Finance then checks each report manually, chases missing receipts and corrects tax codes.
• AI value: fewer out-of-policy bookings, shorter reimbursement cycles, less manual audit work, fewer VAT/per-diem errors, and better spend visibility (traveller, trip and cost centre are linked).
• Evidence: vendor claims exist (e.g. Navan cites a Forrester finding of about 8 hours per week saved by finance teams on expense processing and reconciliation), but they are vendor-reported and workload-dependent; measure your own baseline [2][3].

Variants

• SMB: a travel-and-spend platform with an embedded assistant; the office manager approves.
• Enterprise: agent inside the T&E suite, integrated with HR (cost centres, approval chains), ERP and duty-of-care tooling; policy engine per country and employee group.
• Expense-only: no booking; the agent builds reports from receipts and card feeds (see DOC-002).
• Booking-only / travel-management company (TMC): the agent works the TMC's tools for complex itineraries.
• Public sector / NGOs: stricter funding rules, grant-specific cost allocation, Trennungsgeld/Reisekostengesetz rules.
• Private use: personal trip planning is a different case (PERS-003, CONV-012).

How it works

1. request (chat/email/calendar event)
2. intent + constraints extraction (dates, budget, traveller profile, preferences)
3. policy lookup (cabin class, price caps, preferred hotels, CO2 limits)
4. search via booking APIs/MCP tools (flights, rail, hotels, cars)
5. ranking + explanation ("why this option")
6. approval (manager / traveller confirms; mandatory above thresholds)
7. booking + itinerary + calendar entry ── during/after trip ──
8. receipt capture (VLM/OCR) + card-feed matching
9. categorisation, VAT/tax code, per-diem & mileage calculation, currency conversion
10. pre-submit audit (duplicates, missing receipts, policy and plausibility checks)
11. human submission/approval
12. posting to ERP + archive

• Agent core: an LLM with tool access (search, hold/book, cancel, policy lookup, expense API). Deterministic code, not the model, computes per-diems, caps and currency conversion.
• Policy as data: the travel policy is encoded as rules/tables plus a retrieved text; the model explains, rules decide.
• Human-in-the-loop: payment commitment and booking above limits need explicit confirmation; expense submission and approval stay with the employee and the approver. No auto-rejection of claims without a human decision.

Data preparation

Data comes from several places: the travel policy (PDF or intranet), receipts (paper, photos, e-mail attachments), card feeds and bank statements, calendar entries, employee master data and cost centres from the ERP or accounting system (DATEV, SAP).

Typical gaps: a policy that exists only as prose with unwritten exceptions, paper receipts in shoe boxes, duplicate or unreadable photos, inconsistent cost-centre and project codes, and per-diem rules kept in Excel.

Preparation steps: 1. Turn the travel policy into explicit rules and tables (cabin class, hotel caps, per-diem, mileage) and keep the prose as retrieval text (PREP-012, PREP-013). 2. Clean cost centres, project codes and GL accounts, and export them via API or CSV (PREP-005, PREP-011). 3. Switch to digital receipt capture at source via app or mail inbox (PREP-008, PREP-006 for old scans). 4. Collect 50-100 past, approved claims as test and gold-standard set (PREP-016, PREP-018). 5. Mask card and personal data in test exports (PREP-022).

Tools: the expense tool's own OCR, Paperless-ngx or Docling for archives, Excel or Python for code lists. Expect about 20 percent of the effort in data preparation; the policy rule-set is the biggest item. See GUIDE-003 and DATA-003.

Implementation paths

Which path for whom

• SMB: Path A, because mature EU products (Perk, Spendesk, Circula, Candis, Moss) cover German travel expense rules and DATEV connectors at SMB prices.
• Enterprise: Path A, because travel and expense is a commodity function where Concur, Navan or Emburse bring booking inventory that cannot be rebuilt economically.
• Developer: Path B, because booking APIs (Duffel, Sabre MCP) and cloud LLMs allow a custom policy engine without self-hosting the supplier side.

Path A — Buy (recommended for most SMBs)

• Travel + expense suites with agents: SAP Concur (Joule agents: Expense Automation Agent, Pre-Submit Audit Agent; announced March 2026, early-adopter programme with general availability expected later in 2026) [1], Navan (Expense Agent) [2], Emburse (autonomous expense agent, 2026) [3], Perk (formerly TravelPerk, EU/Barcelona), Spendesk (EU/Paris), Yokoy (EU/Zurich, Swiss), Pleo (EU/Copenhagen), Moss (EU/Berlin), Circula and Candis (EU/Germany) for expense and spend.
• Check: EU hosting, DPA, German Reisekosten rules (per-diem tables, Kilometerpauschale), DATEV/ERP connectors, agent actions logged and bounded, true GA status (many agents are still pilots).
• Choose A when: standard policies, existing card programme, no unusual approval logic.

Path B — Build on cloud APIs

• Models: frontier LLMs with tool use via EU regions (Claude on Bedrock/Vertex EU, Azure OpenAI EU Data Zone, Mistral). Mistral OCR or a VLM for receipts.
• Booking inventory: Sabre's MCP server for flights and hotels (Sabre reports nearly 80 customers piloting or in production; company claim) [4]; Duffel (REST; handles merchant of record and accreditation, per third-party guide); Amadeus Self-Service APIs (search tier; booking needs an enterprise agreement); rail via DB, SNCF or Trainline business APIs; hotels via TMC content.
• Orchestration: an agent framework or n8n/Power Automate with MCP tools; approvals via Teams/Slack; expense posting through the accounting API.
• Choose B when: you want a custom policy engine or a single assistant across several systems.

Path C — Self-host (open source)

• Models: open-weight tool-calling LLMs (Qwen3, Mistral Small/Medium open releases, gpt-oss) served via vLLM or Ollama; Docling/PaddleOCR or Qwen-VL for receipts.
• Stack: n8n or Camunda, an MCP gateway, an open-source expense tool (e.g. ERPNext/Odoo Expenses) and rule engine for policies.
• Booking still depends on third-party supplier APIs; self-hosting only covers the intelligence layer.
• Hardware: HW2 for a ≤30B model and a receipt VLM; low volume per employee.

Path D — Custom training

Rarely justified. Possible for receipt categorisation or an anomaly classifier trained on your own approved/rejected claims (a few thousand labelled reports); mostly handled by prompting plus rules.

State of the art (2026)

• Suites embed agents: SAP Concur's March 2026 Fusion announcements (Joule agents, Microsoft 365 Copilot integration) and Navan, Emburse and others position "autonomous expense" as a feature, shifting the employee to review and submit [1][2][3].
• Distribution is opening to agents: Sabre positions its MCP server as the access layer for AI agents in travel search and booking; analysts note NDC (airline content standard) and MCP (tool protocol) are different layers [4]. Expect rapid change and mixed maturity across suppliers.
• Receipts: VLM-based extraction is reliable for amounts and dates on clean receipts; handwritten, crumpled, multi-currency and itemised restaurant receipts remain error-prone (see DOC-002).
• Limits and failure modes: hallucinated availability or fares, stale prices between search and booking, mis-booking of non-refundable fares, wrong date/time-zone interpretation, double booking, poor handling of disruptions and rebooking, mis-categorised expenses, and prompt injection via supplier emails or receipts. Agents should hold or book only through whitelisted tools with spend caps.

Shared resources & combinations

• Receipt capture (ocr-docparse + vlm) is shared with DOC-002 and DOC-001.
• Agent framework / MCP tooling and workflow engine are shared with AGENT-002, AGENT-003 (portals with no API) and AGENT-012 (calendar-aware scheduling).
• Downstream: ANOM-009 (expense fraud detection), AGENT-006 (reconciliation and close), AGENT-025 (agent governance and audit).
• Intake: AGENT-001 for travel requests arriving by email.

Effort, cost & KPIs

• Path A: days to weeks of configuration (policy, cost centres, card/ERP connectors); per-user monthly fees plus booking fees.
• Path B: 2-4 months for a production agent including booking APIs, accreditation or TMC contracts, and testing.
• Path C: 3-6 months; the largest cost is integration, not GPUs.
• Cost drivers: supplier integrations, policy complexity per country, traveller support and exception handling.
• KPIs: policy compliance rate, share of trips booked in-tool, average booking time, report preparation time, touchless (no-edit) expense lines, reimbursement cycle days, missing-receipt rate, duplicate or fraud findings, cancellation or error cost from agent bookings.

People & change

Involve: management and the finance or travel owner (policy, limits), IT (ERP, card and SSO integration), the DPO, legal or compliance (tax rules, retention, liability), the works council, and a pilot group of frequent travellers and approvers.

Works council: yes where one exists. The agent evaluates individual booking and expense behaviour, flags anomalies and logs actions, so it is suited to monitor employees (§87(1) no. 6 BetrVG, objective suitability suffices per BAG). Inform it in good time under §90(1) no. 3; a works agreement should rule out use for performance assessment. Public sector: Personalrat.

Data protection: card feeds, travel patterns and calendar data are personal data (location, possibly health or religion via meals and hotels). AVV with every provider (Art. 28 GDPR), DPO involvement, DPIA if systematic evaluation of people is planned (GUIDE-005, GUIDE-010).

AI literacy: support travellers and approvers with a short briefing on what the agent may book and how to correct it (GUIDE-006).

Communication and pilot: start with one team, read-only suggestions, then booking within limits. Typical concerns are being monitored and wrongly rejected claims; answer with transparency about audit rules and no automatic rejection: a human approver always decides (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: typically minimal risk; AI literacy (Art. 4) applies. Becomes sensitive if the agent monitors employee behaviour or scores employees (employment-related Annex III uses, e.g. performance monitoring) — keep audit flags about claims, not people. Emotion recognition at work is prohibited (Art. 5) and is not part of this use case [5].
• GDPR: itineraries, locations, passport/frequent-flyer data, meal choices (can reveal health or religion
• special categories under Art. 9, so avoid storing them), card data. Needs DPA, minimisation, retention limits, and works-council involvement in Germany (§87 BetrVG) where tracking is possible.
• Tax / compliance: German per-diems (Verpflegungspauschalen under §9 (4a) EStG; domestic 14/28 EUR, foreign rates updated by BMF from 1 Jan 2026) and meal reductions, mileage rates, GoBD-compliant receipt archiving and VAT recovery on foreign invoices [6]. Compute these deterministically.
• Security: least-privilege booking credentials, spend and rebooking caps, payment tokenisation (virtual cards), prompt-injection defences, logging of every agent action.
• Duty of care: keep traveller location data separate from the booking agent unless necessary.

Getting started

1. Baseline: trips per month, out-of-policy rate, report preparation time, reimbursement cycle.
2. Write the travel policy as explicit rules and tables (caps, classes, approvals, per-diem rates).
3. Pilot expense-only first (receipts + card feed + pre-submit audit); the risk is low and value is visible.
4. Add booking for one route type (e.g. domestic rail and hotels) with human approval for every booking.
5. Review error logs monthly, tighten tool permissions, then widen scope; involve the works council early.

Sources

1. SAP News — SAP Concur Fusion 2026: AI capabilities, integrated travel and expense — https://news.sap.com/2026/03/sap-concur-fusion-2026-ai-capabilities-integrated-travel-expense-enhancements-global-partnerships/
2. Navan — AI travel expense processing — https://navan.com/blog/ai-travel-expense-processing
3. Emburse — AI agent that automatically does your expenses — https://www.emburse.com/company/news/emburse-unveils-new-ai-agent-that-automatically-does-your-expenses-for-you
4. Sabre — MCP is the new NDC — https://www.sabre.com/resources/newsroom/mcp-is-the-new-ndc-is-this-travels-shift-to-streaming-moment/
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. IHK Region Stuttgart — Auslandsreisepauschalen ab 1. Januar 2026 (BMF letter of 5 Dec 2025) — https://www.ihk.de/stuttgart/fuer-unternehmen/recht-und-steuern/steuerrecht/lohnsteuer/auslandsreisepauschalen-ab-1-1-2020-4647466