Travel Request Approval Workflow: When It Backfires

A program tightens its approval requirement and managed spend falls. Requests sit in an approver's queue for days, travelers start booking on personal cards, and the approval record stops matching what got booked. The control added to close a leakage gap widens it instead, because the gate was calibrated to catch every trip rather than the risky ones.

This guide covers five things: what approval actually controls, the four ways travelers route around it, how to measure the gap between what was approved and what got booked, what the technology automates and what it leaves to people, and how to handle executive exceptions. The payoff is a workflow you can defend to finance when managed spend moves the wrong way.

What a Travel Request Approval Workflow Actually Controls

Pre-trip approval authorizes whether a trip happens and confirms business need. That is its entire scope, and treating it as broader authorization is where bad workflow design starts. Where the thresholds themselves should sit is a separate exercise, covered in the guide to approval process design.

After authorization, vendor and cabin rules govern what a traveler may book, enforced as soft stops and hard stops inside the online booking tool (OBT). Expense approval is the third layer, reviewing what was actually spent. Each layer catches a different failure, and none substitutes for another.

Bolting a sign-off onto problems the other layers should handle only lengthens cycle time. A hotel rate over cap belongs at a hard stop during booking, not in a manager's inbox three days earlier. The reverse failure is just as common: an approver handed a trip reason with no cost attached is signing off on the concept of a trip, not a budget. Gates like that tend to lose support, and pre-trip assessments of whether a trip is justifiable are now run by 54% of companies, down from 66% a year earlier.

Why Travelers Route Around Approval

Travelers route around approval when it costs them more than it protects the company. Each pattern below leaves a trace somewhere in program data.

Approval Lag Outruns the Fare

Fares move while a request waits. If approval lag pushes a request past its ticketing deadline, the traveler resubmits at whatever the fare has become, which can make the approved trip cost more than the unapproved one would have. Once repriced, the incentive flips: book first, ask later.

Nobody Knows Who Approves

Requests stall with no owner when routing is unclear, or the approver is traveling, and the delay compounds on international travel, where more than one sign-off is usually in play. Where no formal approver list exists, and any manager can authorize a trip by email, nobody owns the decision and nothing gets escalated. The traveler then proceeds on their own judgment, outside the channel.

Rubber-Stamp Approval

A gate that never closes teaches approvers to stop reading and travelers to stop waiting. Approving out-of-policy or miscoded trips as a matter of routine adds days to cycle time and changes no decisions: the delay is real, and the control is not.

The Expense-Report Escape Hatch

Booking personally and seeking expense reimbursement afterward turns approval into a request the company can't refuse, since the trip already happened. The booking never touches a managed channel, and hotel leakage usually runs 40% or more. Nearly a third of companies running an OBT report that 20% or more of travel spend lands off platform, and missing content, not indiscipline, is the reason travelers give most often.

Reconcile the Approval Record Against What Got Booked

Every workaround above ends the same way: an approval record that describes something other than what the company bought. That gap is the one symptom worth measuring, because it tells you whether the workflow is controlling spend or just documenting intentions.

Three comparisons surface it. Approved trips against booked trips finds requests authorized and never ticketed, which usually means the traveler booked elsewhere. Booked trips against approval records finds the reverse, trips that happened with no authorization at all. Approved amounts against settled amounts finds the repricing the approver never saw.

What comes back is a leakage number attributable to the workflow itself rather than to traveler behavior in general. That distinction matters when finance asks why managed spend fell after the approval requirement tightened. Strictness predicts compliance less than the usability of the booking channel does: only 49% of business travelers always use corporate booking tools, even as 60% of travel managers report their companies tightening compliance with the prescribed process. More enforcement on a channel travelers avoid produces workarounds, not compliance.

What Approval Technology Automates and Leaves to People

Automation handles routing and record-keeping; judgment stays with people. It reliably handles:

• Routing by role, cost center, or dollar threshold
• Budget checks against a cost center before a request routes
• Escalation when a request stalls past a defined window
• An audit trail that survives a finance review

What no system decides is whether a trip is necessary, and no configuration settles an executive exception. The reconciliation described above stays manual in most mid-market programs for the same reason: it is judgment work dressed as data entry.

AI booking tools have moved one edge of that boundary. They ingest company policy, enforce it at booking, and flag out-of-policy options before the traveler commits, which shrinks the pool of trips needing review. Pre-trip approval and exception routing still live in existing finance, HR, procurement, or Travel Management Company (TMC) systems, so the boundary has shifted without moving.

Design the Workflow to Survive Executive Exceptions

A workflow the executive team ignores is a workflow nobody follows. The senior-tier carve-out gets settled politically rather than in configuration, so compliance depends on senior-leadership buy-in before it depends on anything you build.

Standing pre-authorization for defined roles removes the people most likely to break the workflow, while a higher threshold offers the same group a narrower exemption. Finance can instead swap the gate for a notification when it values the record more than the veto, which keeps senior trips out of unexplained budget variance.

None of these is clean, and which survives depends on who sponsors it. Pre-authorization breeds resentment among the employees still gated, and notification-only gives finance the record with no ability to say no.

Whichever you pick, write the exception rule into the policy before rollout. An exception negotiated after the first violation is retroactive approval of a breach, and it teaches the next traveler how the process really works.

Make the Approval Record Match What You Bought

An approval workflow is only as good as the record it produces. When that record stops matching what the company actually bought, the gate has become paperwork, and every additional day of cycle time is buying delay rather than control.

Otto the Agent works as a lightweight TMC for companies that need a managed channel without the overhead of a traditional one. It ingests company travel policy, including budgets, cabin rules, and vendor rules, and shows in-policy versus out-of-policy indicators while the traveler books in Slack, Teams, or the tools they already use. More compliant bookings stay in the managed channel, so the approval record and the booking data start describing the same trips. Otto does not handle pre-trip approval or exception routing, which stay in your existing systems. Try Otto free for a year, no credit card required, with no agent-assist fees, no minimum spend, and no contracts.

Let Otto handle compliance at the point of booking so your approval record and your booking data stop diverging.

Frequently Asked Questions

Should every business trip require pre-trip approval?

No. Retire it by category: keep it for international and out-of-policy trips, drop it for in-policy domestic trips, and track the denial rate as you go. A cluster of requests landing just under your trigger is worth checking for travelers pricing to the number.

Does adding an approval step reduce travel spend?

Not reliably. Approval defers spend and changes where it lands more often than it changes the total, because a trip blocked at the gate frequently reappears on an expense report. The effects you can actually measure are cycle time and channel mix, so judge the workflow on those rather than on a budget line.

How do I tell whether approval is causing leakage or just coinciding with it?

Compare the two periods around the change. If managed spend fell after the approval requirement tightened, and the drop concentrates in trip types the new gate started catching, the workflow is the cause. If the drop is spread evenly across trip types, look at the booking channel instead.

Who should approve travel requests?

Use one approver for routine trips and add layers only for international or above-threshold travel. If the budget sits outside the reporting line, add the cost-center owner in parallel rather than in sequence. Assign every approver a named backup, remind at 48 hours, escalate at 72.

What should a travel manager do when the approval record and the booking data disagree?

Treat the booking data as the truth and the approval record as the claim, then find where the two split. Requests approved but never ticketed point to bookings made elsewhere; trips with no matching request point to a gate travelers learned to skip. Otto's in-policy and out-of-policy indicators reduce how often the two diverge, since compliance gets settled at booking rather than reconstructed afterward.