Travel Expense Prep Agent

Problem

The operator spends hours per trip (1–2 trips/month) on expense reports in SAP Concur. Research (F1, F7) shows capture — getting a receipt image into Concur — is largely solved by Concur's native channels (email intake, mobile app, card feed). The grill confirmed the hours go elsewhere (Q1):

No off-the-shelf product the operator can adopt unilaterally closes this gap (F7): Concur replacements (Expensify, Emburse, Ramp) are not adoptable where Concur is mandated, and Concur's own assistive features (ExpenseIt, e-receipts) are tenant-gated and still leave matching/assembly manual. Meanwhile, every agent write path into Concur beyond email is either IT-gated (API, F2) or banned (browser automation, Q3/F3). So the correct target is: an agent that does the thinking (reconcile, itemize, classify, assemble) outside Concur, and hands the operator a finished answer to transcribe and submit.

Research Inputs

Goals

• G1. Per trip, produce one prep pack that reconciles all ingested receipts against the card feed and contains everything needed to build the Concur report without further thinking (Q1, Q6).
• G2. Hold uncertain items back and resolve them in one batched Q&A per trip; never silently guess an expense type, cost center, amount, or match (Q7).
• G3. Make capture hands-free using Concur-native intake plus dual delivery, so the agent sees everything Concur sees (Q4, Q5, F1).
• G4. Cut the operator's in-Concur time for a typical trip to a fraction of today's — the binding bar is relative (≤ 25% of the phase-0 baseline, AC7); the ≤ 15-minute absolute target is an aspiration pending an operator decision (FA7).
• G5. Support both payment paths: corporate-card items (matched to feed) and out-of-pocket items (no feed; own path) (Q6).

Non-Goals

• Unattended submission — permanent. The operator reviews and clicks submit; the agent never attests on the operator's behalf (Q2, F6).
• Browser automation of Concur — permanent. No Playwright/session automation against the corporate financial system, regardless of API status (Q3, F3).
• Whole-library photo scanning. The agent never scans the camera roll; photos enter only via the one-tap Shortcut (Q4, F5).
• Re-implementing capture. No OCR-to-Concur upload pipeline of its own; Concur's native intake carries the images (Q1, F1).
• Replacing Concur, automating approvals, or handling anyone else's expenses.

Proposed Behavior (Operating Contract)

Inbound channels (capture + visibility)

1. Email receipts: operator-owned Outlook rules forward matching messages to BOTH the tenant's Concur intake address and the agent's mailbox (Q5, F4b). Concur gets the image natively; the agent gets full visibility for matching. No Graph app consent required (assumed blocked, FA1).
2. Photo receipts: a one-tap iOS Shortcut per receipt sends the photo to BOTH the Concur intake address and the agent (Q4, F5). Same dual-delivery principle; no camera-roll access.
3. Card feed: the operator exports/copies the trip's unassigned card transactions from Concur's "Available Expenses" view once per trip (manual, low volume per C4; format per FA3). The agent never logs into Concur to fetch them.

Processing (the actual value)

4. Extract structured data from every ingested receipt (vendor, date, amount, currency, tax, line items where present).
5. Reconcile: match each receipt to a card transaction with tolerance for known deltas (tips, FX conversion, pending-vs-posted amounts, date offsets). Flag in both directions: card charges with no receipt, and orphan receipts with no charge (Q6). Out-of-pocket receipts are detected and routed to their own reimbursement section rather than flagged as errors. Payment-method hints come from exactly three places: an "out-of-pocket" toggle on the iOS Shortcut, per-vendor defaults in the operator's mapping file, and batched-review answers; email receipts default to corporate card unless a hint says otherwise. Foreign-currency out-of-pocket receipts keep their original currency and amount in the pack, and rate handling (Concur applies the tenant's rate at entry) is surfaced in the batched review rather than converted silently.
6. Itemize hotel folios into the tenant's Concur categories (room rate, taxes, parking, meals, internet, other), with lines summing to the folio total (Q6).
7. Classify each line with expense type and cost center using an operator-maintained mapping file (vendor/category → expense type, project → cost center). Anything below confidence threshold goes to the held queue, not into the pack (Q7).
8. Batched review: one interactive Q&A round per trip resolving all held items (ambiguous matches, unknown expense types, missing receipts the operator may still have). Reconciliation against the card feed doubles as the capture-gap detector: a charge with no receipt means a receipt never got forwarded/photographed.

Output — the prep pack (per trip)

9. A single document containing, in Concur entry order:
   • reconciliation table: card transaction ↔ receipt ↔ expense type ↔ cost center ↔ amount, one row per report line;
   • hotel folio itemization blocks ready to transcribe;
   • out-of-pocket section (own reimbursement lines);
   • exceptions: unmatched charges, orphan receipts, and items the operator chose to exclude, each with the decision recorded;
   • a completion checklist (receipts visible in Available Receipts, totals tie out).
10. The operator opens Concur, builds the report from the pack (receipts already waiting in Available Receipts via native intake), reviews, and submits. Target ≤ 15 minutes (aspirational, FA7).

Acceptance Criteria

Architecture

Local agent on the operator's machine (C2). Components:

• Ingest: watcher on the agent mailbox (forwarded emails + Shortcut photos); per-trip workspace keyed by trip dates.
• Extract: OCR + LLM extraction to a normalized receipt record (vendor, date, amount, currency, payment hint, line items). Folio documents get line-item extraction.
• Reconcile: deterministic matcher (amount/date/vendor with tolerance windows) with LLM assist only for ambiguous candidates; every match carries a confidence and its evidence.
• Classify: rules-first from the operator's mapping file; LLM fallback proposes, never decides — low-confidence proposals go to the held queue. The confidence threshold is operator-configurable with a conservative default (start strict; loosen only after real trips demonstrate precision). AC6 records the configured value; disabling the threshold defeats the Q7 contract and fails AC6.
• Review loop: one batched Q&A per trip (chat or generated checklist); answers persist back into the mapping file so repeat vendors stop asking.
• Render: prep pack as a single self-contained document.
• Storage & data boundary: all persisted data (receipt records, trip workspaces, mapping file) lives on the operator's machine; no Concur credentials stored anywhere (Q3). Whether receipt/folio contents may be sent to a cloud LLM API for extraction/classification is an unresolved policy question — see FA6. Until phase 0 resolves it, the design treats cloud LLM processing as unapproved: the contract is "no receipt data leaves operator-controlled systems except the existing corporate channels (Outlook → Concur intake) and whatever LLM path FA6 approves."

Grill Record

Conducted after research, per the loop. Each answer traces to what it changed in this spec.

Flagged Assumptions

Named, unverified; each has a verification step in Rollout phase 0.

• FA1 — Graph consent blocked. The M365 tenant is assumed to block user app consent (Q5, F4a). If wrong, Graph delegated read is a cleaner ingest path — an optimization, not a contract change.
• FA2 — Tenant email intake enabled. Verified-email receipt intake (F1a*) is assumed available in this tenant. If disabled, capture falls back to the Concur mobile app for images while the agent still receives everything for matching; AC1 then becomes: (a) an image captured via the Concur mobile app is visible in Available Receipts, (b) unchanged for the agent-mailbox leg (both message shapes still reach the agent).
• FA3 — Card export workable. Assumes the operator can export or copy unassigned card transactions from Concur per trip (CSV, copy/paste, or screenshot+OCR fallback). If no method works, AC3 cannot be met and the reconciliation core needs a redesign — this is the highest-risk assumption.
• FA4 — ExpenseIt availability unknown (F1b*). The design does not depend on it; if present it only improves Concur-side draft entries.
• FA5 — Agent mailbox and local data-at-rest are policy-compatible. Receipts contain corporate travel data. The agent's mailbox must sit inside the corporate tenant (dedicated folder or alias read locally) unless the employer's DLP policy explicitly permits external forwarding; the same phase-0 policy read confirms that persisting receipt/folio contents in a local per-trip workspace on the laptop is acceptable.
• FA6 — LLM processing locality unresolved (raised in review; operator has not answered). Extraction, matching assist, and classification use an LLM. Whether sending receipt/folio contents to a cloud LLM API is acceptable under the employer's acceptable-use/DLP policy is unknown. Until resolved, the contract treats cloud LLM use as unapproved (see Architecture, Storage & data boundary). If policy forbids cloud, extraction runs on a local model and extraction quality becomes a feasibility risk (R6). Resolved in phase 0 by the operator against the actual policy.
• FA7 — Absolute time target unvalidated (raised in peer review; operator has not answered). Whether ≤ 15 minutes in-Concur is a hard bar or an aspiration is an operator decision, and no feasibility estimate exists for hand-transcribing a large trip (multi-line folio + a dozen transactions) from the pack. The binding criterion is therefore relative (AC7: ≤ 25% of the phase-0 baseline). Phase 0 records the baseline and typical per-trip line volume so the operator can set the absolute bar; if transcription volume makes even the relative win marginal, the real payoff shifts to v2 API assembly. Coupled to FA6: a local-only LLM (R6) inflates the batched review and pressures the same target.

Risks

• R1. FA3 fails — no reasonable card-transaction export. Impact: core reconciliation blocked. Mitigation: three fallback formats (CSV, paste, screenshot OCR); verified in phase 0 before any build.
• R2. Matching ambiguity — tips, FX, pending-vs-posted deltas cause false non-matches. Mitigation: tolerance windows + held-queue routing (never silent), tuned over the first two trips.
• R3. Forwarding-rule gaps — receipt emails that don't match rule patterns never reach Concur or the agent. Mitigation: reconciliation itself detects the gap (charge with no receipt) and the batched review asks; rules updated as vendors accumulate.
• R4. Habit dependency — value depends on the one-tap Shortcut habit. Mitigation: card-feed reconciliation catches forgotten photos; worst case the batched review lists what to photograph from the wallet.
• R5. Tenant/product drift — starred findings may be stale; Concur packaging changes. Mitigation: the two findings the architecture leans on hardest were web-verified on 2026-07-04 (F1a verified-email intake, F2 company-admin-gated API — see the research report addendum); remaining starred items (ExpenseIt, e-receipts, Graph consent) are tenant-private and verified in phase 0 against the live tenant, not documentation.
• R6. Local-only LLM mandate (if FA6 resolves to "no cloud") — extraction/classification quality on a local model may be materially worse, inflating the held queue and batched-review length. Mitigation: the hold-and-ask contract (Q7) degrades gracefully — quality loss shows up as more questions, never as silent wrong lines; measure held-queue size in phase 2 and revisit if review exceeds the time it saves.

Rollout

Alternatives Rejected