Out-of-Policy Expense Detection and Handling

Global business travel spending runs into the trillions annually, and a fixed portion of it falls outside company policy every year, in small companies and Fortune 500s alike. That share is not shrinking on its own, and the problem is structural rather than incidental. Organizations invest heavily in detection tools but consistently underinvest in what happens after a violation gets flagged: the routing logic, the escalation paths, the documentation requirements, and the feedback loop that connects enforcement outcomes back to policy language. This piece examines why detection alone does not fix non-compliance, what a well-designed resolution workflow actually requires, and how to measure whether a compliance program is functioning or simply generating numbers that look reassuring.

The dollar figure is the least interesting part of the problem. Every non-compliant booking chips away at supplier leverage, because fewer bookings through negotiated channels means worse rates next contract cycle. Non-compliant bookings also complicate tax reporting and create duty-of-care gaps that carry real liability. If a traveler books outside the managed system during a storm or a strike, the company may not know where that person is or how to reach them.

Violations and Fraud Require Different Responses

Policy violations and fraud get lumped together constantly, and that is the first mistake worth fixing. A violation is someone going over a limit without trying to hide it: the $95 dinner on a $75 cap, the upgraded hotel room, the business-class seat on a policy that calls for economy. Fraud involves deception: personal expenses submitted as business ones, altered or invented receipts, the same taxi ride submitted twice across two reports six months apart.

This distinction decides everything downstream. It determines which escalation path a flagged expense takes, whether the fix is a conversation with a manager or a referral to legal, and whether the response is corrective or investigative. Treating every flag the same way will either over-punish someone who made an honest judgment call or under-react to someone running an actual scheme.

Catching fraud is also getting harder. Altered receipts and AI-generated documentation now pass a casual glance, which makes automated detection more necessary. The Association of Certified Fraud Examiners' 2024 Report to the Nations found expense reimbursement schemes appear in a meaningful share of all occupational fraud cases, with a median time to detection measured in years. That gap between when fraud starts and when someone notices reflects both a detection failure and a workflow failure.

Why Violations Persist Despite Written Policies

Most policies fail for structural reasons. The language is vague, the document is stale, or the approval process is slow enough that people route around it.

"Use good judgment" reads as a suggestion dressed up as a rule, and neither software nor a manager can enforce it consistently. Compare that to an explicit per-category dollar threshold: $75 for meals, $250 for hotels in a given city tier. A system can check one of those automatically. The other depends on whoever is reading the report that day.

Plenty of policies also live in a PDF buried deep on a company intranet, last updated two years ago. Employees are not always ignoring the rules deliberately. They are working from memory, or from a version of the policy that is no longer current.

When booking tools or approval chains are slow, people book around them. They go directly to a vendor, often the one offering the best personal perks rather than the one the company has a negotiated rate with. Too many approval layers with no defined response time lead travelers to skip pre-approval entirely because waiting three days for a sign-off is not practical for a $40 difference in hotel rate.

A healthy flag rate on submitted expenses sits in a moderate band. Too high, and the policy itself is probably miscalibrated. Too low, and it is under-enforced. Most programs have no idea which situation they are dealing with, because nobody is tracking it. Fixing the detection engine without fixing the underlying policy produces a flood of flags that nobody can adjudicate consistently.

Pre-Payment Detection Beats Post-Payment Audits

The traditional model reviews expense reports after reimbursement has already gone out. Relying on a post-payment audit as the only control means the program depends on clawing back funds already paid, which is slow and rarely recovers everything owed. Point-of-transaction enforcement checks policy rules the moment someone books a flight or swipes a card, not weeks later when the report lands on a desk. A violation gets blocked or flagged before it becomes a sunk cost.

Booking-tool guardrails are the first line of defense: an out-of-policy fare or hotel gets blocked or flagged with a warning at the point of selection, before the traveler finishes booking. A post-payment audit tool catches problems only after the fact. One is prevention; the other is an audit function, and they serve different purposes.

Pre-approval review by accounts payable, before a report reaches a manager, also means managers review cleaner reports and the company avoids the harder job of asking someone to return money already in their account.

Layered Automated Detection Catches More Violations

No single check catches everything, which is the argument for stacking layers rather than picking one.

The first layer sits at the booking tool: amount limits, category restrictions, blocked merchants, preferred-supplier rules, and class-of-travel restrictions enforced at the point of selection.

The second layer is receipt and document audit. Image forensics check for signs a receipt has been altered or fabricated. AI classification checks submitted amounts against vendor data and flags missing fields or figures that do not match.

The third layer is behavioral and pattern analysis: catching duplicate submissions across different reports or time periods, flagging mileage that looks padded, and spotting anomalies against an employee's own history or peer group norms.

Each layer is blind to what the others catch. A duplicate submission passes through a receipt integrity check because the receipt itself is real. An altered receipt passes through duplicate detection because it is only submitted once. A single-layer system always has a gap exactly the size of what that layer does not check for.

One requirement that does not get enough attention: every flag needs a plain-language explanation attached to it, not just a code. An approver looking at "Flag 4471" will rubber-stamp it or override it without thinking. An approver looking at "this hotel rate is 40% above the city cap and was booked eight days in advance" can actually make an informed decision.

SAP Concur's Pre-Spend Planner, an agentic AI tool, aims to flag budget impact before an expense even occurs rather than catching it afterward. That approach shifts the model from reactive enforcement to proactive forecasting.

Flagged Expenses Need a Defined Workflow

Significant investment goes into detection infrastructure, but few organizations build a clear workflow for what happens once a flag fires. Flags accumulate, approvers are unsure what they are authorized to decide, and violations sit unresolved until someone remembers to look.

The fix starts with risk-based approval tiers, because not every flagged expense deserves the same scrutiny. A $12 overage on a lunch receipt does not warrant the same review as a $4,000 entertainment expense involving a foreign government official. Low-impact items should auto-approve once a receipt is attached, with no human review required. Mid-tier spend goes to a manager with a defined response window. High-exposure items, such as large dollar amounts, high-risk categories, or anything involving an FCPA-adjacent vendor, go to finance with full documentation required.

Category-specific rules should layer on top of that. Travel above a certain threshold, entertainment involving outside parties, or payments to a new vendor may need a different approval chain regardless of the dollar amount alone.

Escalation paths must be spelled out explicitly. What happens to a report that sits untouched past its deadline? Who owns it at that point? Does the system notify someone automatically? Any automated action, such as an auto-denial or auto-escalation, needs a window during which a person can step in and reverse it, with the reason for that reversal recorded.

Every action on a flagged expense, whether approved, denied, escalated, or overridden, needs a record of who acted, when, and why. That documentation is what allows a compliance program to survive an external audit.

Consequences and Overrides Must Inform Policy

A policy without stated consequences is a suggestion. If the document does not say what happens when a rule gets broken, approvers have no real authority to enforce anything and employees have no reason to think twice.

Consequences should scale with severity and be spelled out in the policy itself: denial of reimbursement for a minor overage, a formal write-up for repeated or deliberate violations, and termination with referral for outright fraud.

When a manager overrides a flag, the system should capture why. A pattern of overrides on the same rule indicates either that the policy threshold is miscalibrated or that there is a cultural norm of waving through violations because pushing back feels uncomfortable. Without override data, those two situations look identical from the outside, and they require completely different responses.

The ACFE's 2024 findings show that the overwhelming majority of fraud perpetrators displayed behavioral indicators before anyone caught them. Earlier flags, tracked systematically over time, could shorten that multi-year median detection window significantly. Most flags, however, get resolved in isolation and then forgotten, disconnected from whatever enforcement or policy outcome follows.

All exception data, including overrides and aging flags, should feed a scheduled policy review: a recurring process where thresholds and language get adjusted based on what enforcement data shows, rather than a dashboard nobody opens.

Track KPIs That Reflect Actual Compliance

Booking-channel compliance rate, meaning the share of spend flowing through managed, policy-approved channels, is the foundation metric. Preferred-supplier share indicates whether negotiated rates are being captured or leaking to outside vendors. Exception-approval rate, the share of flagged items approved anyway, serves as a warning indicator: a high number suggests either that the policy is out of touch with operational reality or that approvers are waving flags through without scrutiny. Average advance-purchase days works as a proxy for booking discipline, since last-minute bookings correlate with out-of-policy fare choices. Flag-to-resolution time, meaning how long a flagged expense sits before a decision is made, measures the handling workflow directly, and long aging times point to a workflow problem rather than a detection one.

Total bookings, total spend, and report volume reward scale and activity rather than discipline. A program can increase booking volume every quarter while compliance quietly deteriorates, and those numbers will still look strong on a slide.

A zero on a violations dashboard can mean two completely different things. Genuine compliance is one possibility. A broken detection system catching nothing is the other. Both produce the same number, and the measurement approach has to be rigorous enough to distinguish between them, or the metric becomes actively misleading.

Key Questions to Ask Expense Platforms

On detection: does the system stop a violation at the point of booking, or only flag it after the report is submitted? Does it run layered checks across receipt forensics, duplicate detection, and behavioral anomaly scoring, or is it a single rule engine? Does every flag come with a plain-language explanation, or just a code that means nothing to the person reviewing it?

On handling: does the platform support tiered approval routing based on amount and category, or does everything land in one queue regardless of risk level? Can escalation paths and response windows be configured, and does the system automatically surface items aging past their deadline? Is there a logged trail with timestamps and actor records for every approval, denial, and override?

On human control: can an automated denial or escalation be reversed by a person within a defined window? Does override data feed back into how the policy gets updated, or does it disappear into a log nobody revisits?

Platforms including SAP Concur, Coupa, Expensify, Brex, Emburse, and Navan vary considerably in where their strengths sit across this lifecycle. Some are strong on receipt capture and reporting interfaces but thinner on point-of-transaction enforcement. Others handle escalation routing well but never close the loop back to policy review. Most modern platforms catch violations reasonably well. The harder test is whether a platform completes the full cycle: flag, route, resolve, and feed that outcome back into how the policy itself is written. Letterbrace treats detection as a set of signals rather than a single score, tracking catch rate, false-positive rate, and time-to-flag together, on the basis that optimizing for one number alone tends to hide weaknesses in the other two.

Most platforms on the market today are strong on flagging violations and weak on closing the loop afterward. That gap between identifying a violation and resolving it systematically is where compliance programs leak money, time, and organizational trust.