Travel & Hospitality AI agent · Expense
Corporate-Travel Policy & Expense AI Agent
Check each claim against your policy and the accountable-plan rules, surface duplicates, outliers and exceptions as signals for a named approver, and route what cannot be substantiated to payroll.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named approver
- Signals only
- After launch
- Agent Care
What this agent does
A signal for an approver, not a verdict
In
- 01
Ingesting the claim, the receipts, the trip record and the policy in force for that traveller.
- 02
Normalising amounts, merchants, cost centres and trip legs, each carried with its own record.
Reason
- 03
Testing each claim against business connection, substantiation and the return of excess.
- 04
Reading a per diem as settling the amount only, and asking for time, place and business purpose.
- 05
Watching the substantiation and return windows, and surfacing a claim before either closes.
Decide
- 06
Raising duplicates, outliers and policy exceptions as signals for an approver to weigh.
- 07
Routing what cannot be substantiated to the approver, and onward to payroll as a wage item.
Out
- 08
Retaining the claim, the policy read against it, the substantiation, the edits and the approval.
- 09
Executing write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent checks and routes; a named approver decides, and the employer answers for how the arrangement itself is treated.
Example workflow
One claim, submission to approval
- 1Claim submittedExpense tool, card feed, receipt capture or a traveller's own submission
- 2Context assembledReceipts, the trip record, the cost centre and the policy in force for that traveller
- 3Claim reviewedPolicy read, substantiation, flags
- 4Controls appliedBusiness-connection checks, substantiation checks, window checks, flags and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is reimbursed at any of them — the agent is checking, and the approver's lane opens at the confidence gate.
Goes to the named approver to release.
Adds a finance read first.
Approver releases
The claim is held with its policy read, its flagged lines and the confidence.
Approve · Query · Send to finance review
Approved — released for payment
- 6Expense systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedFlag outcomes, override rates, substantiation gaps and items reclassified after payment
Overrides
Every approver override is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Paying out a claim, or moving money against one.
- Waiving substantiation for time, place or purpose.
- Extending a substantiation or repayment deadline.
- Calling a claim fraudulent, or naming a person.
Automation boundary
Agent acts unaided
- ✓Read each claim beside the policy in force for that traveller.
- ✓Test business connection, substantiation and return of excess.
- ✓Surface a duplicate or an outlier as a signal to weigh.
- ✓Flag what an approver must decide, and hold the claim there.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
- Deciding whether a trip is safe for an employee.
- Approving or refusing travel against a risk score.
- Treating an unsubstantiated item as written off.
- Changes to policy, thresholds or approval limits.
Example output
One claim, annotated
Everything the agent raises is attached to the claim and the policy it was read against.
Expense review output · single claim
Illustrative example- Claim
- Two-night domestic trip
- Flagged line
- Meal claimed on a per diem, with no business purpose recorded against it
- Amount claimed
- $142.60
- Source of record
- Policy and trip record
- Confidence
- 88%
- Standing
- Signal for the approver
As received
Taken from the claim, the receipts and the policy in force — nothing on this side is decided by the agent.
Records used
- Policy in force
- Trip and card record
- Prior approver reads
Why this is flagged
A per diem settles the amount and nothing else — time, place and purpose are still missing.
What the score decides
Below the configured threshold the claim picks up a finance read before it reaches the approver.
Action
ApproveQuerySend to finance reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every claim
From the claim and the policy
Check against the policy
Read each claim against your written policy, the trip record and the accountable-plan requirements.
A flag is not a finding
Routine claims reach the approver already checked and already carrying what substantiates them.
Send review to what money turns on
A duplicate, an outlier or an exception is a signal an approver weighs. The agent does not detect fraud and does not say that anyone committed any.
Build an evidence trail
The claim, the policy and substantiation behind it and the approver who released it stay on the report.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Expense platforms
- SAP Concur
- Expensify
- Navan
- Coupa
- Brex
Card and payment feeds
- Corporate card issuers
- Bank and settlement feeds
Travel and booking data
- Booking tools
- agencies
- Itinerary and trip records
Agent
Corporate travel policy & expense
- Reads the claim
- Checks the policy
- Holds for approval
Finance and payroll
- ERP
- general ledger
- Payroll systems
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the payment
The layers nest. What each one misses is named in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a claim may stand
- L3
- Puts the release in an approver's hands
- L4 – L5
- Keep the claim and the substantiation behind it
- L6
- Reverts to policy checking when signals degrade
How Nestack evaluates it
Evaluate the review workflow — not only the decision on one claim.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the claim the approver reads
- E1Final-output evaluationDid the policy read match the policy actually in force for that traveller?
- E2Step-level evaluationDid the agent use the right trip record, cost centre and policy version?
- E3Tool evaluationDid it read and write the correct claim and the correct report?
- E4Confidence calibrationDo low-confidence claims actually attract more approver overrides?
- E5Slice evaluationHow does performance change across specific claim types?
- E6Business outcomeHow many claims were reclassified or corrected after payment?
Floor — the payroll position the employer carries
Failure modes
Where each failure originates in the agent
Seven failure modes, placed at the stage each one originates.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- CZ-03
Wrong policy version read
A claim is checked against a policy that no longer applies.
Stage gathers
Claims, receipts, trip records and the policy
02 · Reasoning
2 modes
- CZ-04
Per diem read as complete
The amount is taken to settle time, place and purpose too.
- CZ-06
Flag read as a finding
A signal is written up as though it accused a person.
Stage proposes
Policy read, substantiation and confidence
03 · Tool / write
2 modes
- CZ-02
Released without an approver
A claim reaches payment with no person behind it.
- CZ-05
Substantiation window missed
A claim passes the deadline before anyone is asked.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- CZ-01
Risk note read as clearance
A travel-risk line is taken as a decision that a trip is safe.
Stage returns
The claim the approver releases for payment
05 · Change / Version
1 mode
- CZ-07
Silent policy regression
A model or rule change loosens what the agent will pass.
Stage tracks
Model, prompt, policy rules and threshold config
- Sev-1 · a claim released unapproved
- Sev-2 · a wage event passes as expense
- Sev-3 · policy data degrades, claim to review
Affected slices
Overall quality can hide one bad cohort
Every number in this table is a ratio, and the denominator is what matters. Routine receipted claims sit at the bottom The cohorts that carry it are named, not averaged away..
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Per diem claims | 7.2% | 3.5× | Review | |
| Claims near a window edge | 4.5% | 2.2× | Review | |
| Flagged duplicates and outliers | 2.9% | 1.4× | Watch | |
| Routine receipted claims | 1.6% | 0.8× | Normal |
Bar: approver-override-rate lift vs. routine-receipted baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
A cycle ends in a standing test
A cycle is done when the miss has become a test the next release has to survive. That suite is what the next claim through review is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Approver-override rate rises in a claim slice.
- 02
Diagnose
The claims themselves come first — the receipts, the policy version read against them and the flags raised — and they are read until the cause narrows to one.
- 03
Improve
Version-stamp the change and attach the claims that exposed it.
- 04
Verify
The affected cases run again, and a fail stops the release.
- 05
Learn
It becomes a standing test, and the policy notes change with it.
Learn → Detect
The return edge. The next detection is measured against a longer suite.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, review workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Expense and travel policy discovery and boundaries.Week 1
- 02Expense, card and trip source assessment.Week 1, Week 2
- 03Policy, substantiation and approval-limit rule mapping.Week 1, Week 2
- 04Claim ingestion and normalisation.Week 2
- 05Policy-check logic and record binding.Week 2, Week 3
- 06Confidence scoring and flag routing.Week 3
- 07Approver release workflow.Week 3, Week 4
- 08Expense and payroll integration.Week 5
- 09Substantiation and window cases.Week 4, Week 5
- 10Guardrails and approval controls.Week 4
- 11Claim-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne entity, one policy | ProductionProduction expense systems | AdvancedMultiple entities / policies |
|---|---|---|---|
| Introduced at Pilot | |||
| Checking against your policy | ✓ | ✓ | ✓ |
| Approver release | ✓ | ✓ | ✓ |
| Review-quality baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by cost centre | — | ✓ | ✓ |
| Approval workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Expense-system integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-entity policy sets | — | — | ✓ |
| Multi-stage finance approvals | — | — | ✓ |
| High claim volume | — | — | ✓ |
| Multi-entity approval controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your written policy and approval limits
→Claim ingestion and policy mapping
Week 102Claims you have already reviewed
→Review baseline, policy extraction and record binding
Week 203Your substantiation rules and who approves
→Policy, substantiation and approval-limit rule mapping
Week 104Access to relevant APIs, feeds or exports
→Expense, card and trip-record assessment, then integration setup
Week 205Claims you would not want reimbursed
→Substantiation cases and failure-mode testing
Week 406What must reach an approver before money moves
→Confidence scoring, flag routing, guardrails and approval controls
Week 307Named approvers to release claims
→Approval workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy, which is why week 5 doubles up rather than padding.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Expense workflow discovery, policy mapping and the automation boundary
W2Expense-system integration and the review baseline
W3Review workflow, confidence logic and approval controls
W4Substantiation cases, window guardrails and failure-mode testing
W5Payroll integration, pilot claims and targeted corrections
W6One reporting cycle reviewed under finance, then handover
- Reading the band
- A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
- At the end of W6
- The last checks clear on live claims and monitoring moves to Agent Care.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Travel & Hospitality AI agent
Build an expense agent that flags, and never accuses.
An approval outside the accountable-plan rules is not a policy exception; it is a payroll-tax event, and it attaches to everything paid under the arrangement rather than to the item that was waved through. So bring the three things that decide it — your written policy, the substantiation you actually require, and the named approver who releases money. This is a finance and tax control, not a spend-tracking tool.
- Typical delivery
- 4–6 weeks
- Deployment
- Your expense stack
- Named approver
- Signals only
- After launch
- Agent Care available
Nestack Agents · Corporate travel and expense
AGT-TH-13 · Agent Care available after launch
