Automating Travel Receipt Reimbursement into SAP Concur

Evidence Summaries (Findings F1–F7)

• F1: Concur native receipt ingestion (prior art — closest existing solution)
  • F1a. Concur supports emailing receipt images from a verified email address to a receipt intake address (historically receipts@concur.com, landing in the user's "Available Receipts" pool). Confidence: high* (feature is long-standing; exact address/behavior should be verified in the operator's tenant). Upgraded to high (verified) in the addendum.
  • F1b. ExpenseIt (bundled into the Concur mobile app for most enterprise deployments; also an email intake variant, historically receipts@expenseit.com) OCRs a receipt and creates a draft expense entry (amount, date, vendor, suggested expense type), not just a stored image. Availability depends on whether the company licensed ExpenseIt. Confidence: medium* (licensing varies by tenant).
  • F1c. E-receipts / TripLink: participating vendors (airlines, hotels, car rental) can deliver structured e-receipts directly into Concur if the company enabled it and the user linked accounts. Confidence: medium*.
  • F1d. Corporate card transactions feed into Concur automatically in essentially all large-enterprise deployments; the user's job is matching receipts to those transactions and adding them to a report — the card charge itself does not need to be created. Confidence: high.

  Interpretation: capture of individual receipts is largely a solved problem inside Concur itself. An agent that only re-solves capture adds little; its value must come from (1) making the two inbound channels hands-free and (2) attacking assembly/submission.

  F1a: high* → high (verified) F1b: medium* F1c: medium* F1d: high
• F2: Concur write APIs are IT-gated
  • F2a. SAP Concur Platform APIs (v3/v4: Expense Reports, Expense Entries, Receipts/Image API, Quick Expense) exist and can create expenses and reports. Confidence: high.
  • F2b. API access requires an OAuth client registered at the company level (App Center partner app or company-internal app created by the company's Concur admin). An individual employee cannot self-serve API credentials. Confidence: high.
  • F2c. Therefore any "agent creates/edits/submits reports via API" path has a hard dependency on corporate IT approval. Confidence: high (direct consequence of F2b + stated context "corporate IT controls what integrates with Concur").
  Confidence: high F2a/F2b verified in addendum
• F3: Browser automation of the Concur web UI

  Technically feasible (Playwright + persisted session), but: enterprise SSO (SAML + MFA) sessions expire; Concur UI changes break selectors; automating an authenticated session with stored credentials/cookies may violate the employer's acceptable-use policy; and a mis-click in a financial system of record has compliance consequences.

  Risk profile: high confidence Violates this employer's policy? unknown — grill
• F4: Outlook / Microsoft 365 access
  • F4a. Microsoft Graph with delegated Mail.Read is the clean way to scan the mailbox; but large-enterprise tenants commonly disable user consent for new app registrations, requiring admin consent. Confidence: medium* (tenant-specific).
  • F4b. Policy-safe fallbacks that need no IT action: an Outlook rule that forwards matching messages to the Concur intake address directly (capture without the local agent seeing them), or local access to the mailbox via the operator's own logged-in client. Confidence: medium.
  F4a: medium* F4b: medium
• F5: iPhone photo channel

  Options, in increasing automation: manual export; iOS Shortcut ("share receipt → send to agent/email"); iCloud Photos sync to a Mac the agent runs on, with the agent classifying which photos are receipts. All are operator-controlled, no IT dependency. On-device classification of "is this a receipt" is well within current local/LLM capability.

  Feasibility: high Which one fits the operator's habits: grill
• F6: Compliance shape of expense reports

  Submitting an expense report is a personal financial attestation; most corporate policies hold the employee responsible for accuracy regardless of tooling. Fully unattended submission shifts nothing legally and creates real risk (duplicate claims, wrong expense type, personal expense on company card). Industry pattern for expense automation (including Concur's own ExpenseIt and competitors like Expensify's SmartScan+auto-submit) is "auto-draft, human confirms" — Expensify's fully-automatic submission is notable precisely because it is bounded by policy rules engines the company configures.

  Pattern: high confidence Operator's risk appetite: grill
• F7: Why existing solutions don't already settle this

  Concur mobile app + ExpenseIt + card feed already gets a diligent user to "photograph everything promptly, match in the app." The residual pain this idea targets is: (1) nobody forwards/photographs promptly — receipts pile up across two channels; (2) matching, itemization (hotel folios: room vs tax vs parking vs meals), expense-type selection, and report assembly is manual; (3) it requires being in Concur. No off-the-shelf product the operator can adopt unilaterally (without IT) closes that gap. Expensify / Emburse / Ramp are whole-system replacements — not adoptable here since Concur is mandated.

  Confidence: medium-high

Constraints Carried Into The Spec

• C1

  No IT dependency may be a hard prerequisite for the MVP path (IT approval is slow/uncertain); IT-approved API access is an upgrade path.

• C2

  The agent runs on operator-controlled endpoints (laptop/phone).

• C3

  Corporate acceptable-use policy bounds credential/browser automation.

• C4

  1–2 trips/month → low volume; batch processing per-trip is fine; latency is irrelevant, correctness dominates.

Open Uncertainties (Feed The Grill)

• U1

  Where the operator's hours actually go (capture vs assembly).

• U2

  Whether ExpenseIt / e-receipts / verified-email intake are enabled in this tenant (starred findings F1a–F1c).

• U3

  Whether IT would approve an API app; whether browser automation violates policy.

• U4

  Graph consent posture of the M365 tenant.

• U5

  Operator's acceptable end state: unattended submit vs review-and-click.

• U6

  Photo-channel habit fit (Shortcut vs iCloud sync vs manual).

Source Audit

Staleness note: Concur product packaging changes; anything starred is potentially stale as of the Jan 2026 cutoff.

Addendum — Web Spot-Check Of Load-Bearing Starred Findings (2026-07-04)

Added during the spec review cycle (both reviewers recommended de-staling the two findings the architecture leans on hardest). Method: live web search, July 2026.

• F1a upgraded to high (verified)

  SAP's current docs and Concur community confirm: with a verified email address on the SAP Concur profile, receipt images sent to receipts@concur.com land in the user's Available Receipts. Verification is per-address via emailed code; address count limits apply (3–5 depending on product mix). Tenant-level enablement still needs the phase-0 check (FA2 in the spec).

  VerifiedSources: WEB-1, WEB-2, WEB-3
• F2a/F2b upgraded to high (verified)

  SAP Concur Developer Center confirms company-level authentication: registering an OAuth app and obtaining clientId/clientSecret requires Company Admin plus Authentication Admin permissions via OAuth 2.0 Application Management. An individual employee cannot self-serve API credentials — the API path is IT-gated as concluded.

  VerifiedSources: WEB-4
• Not spot-checked

  F1b (ExpenseIt licensing), F1c (e-receipts), F4a (tenant Graph consent posture) — tenant-private; remain starred and phase-0-gated.

  Remain starred (*)

Confidence And Limitations

• Graded per finding (high / medium-high / medium; starred * = tenant-verify)

  The base run used model knowledge only (no web access; Jan 2026 cutoff), so "high" means high for knowledge-based research. Anything that could have changed since the cutoff is marked (*) and must be verified against the operator's actual tenant before implementation. Live web verification of current Concur intake addresses, current API program terms, and this employer's actual tenant configuration and acceptable-use policy were all unreachable in the base run (no web access; tenant-private) — marked (*) and U2–U4. The 2026-07-04 addendum later verified the two load-bearing starred findings (F1a, F2a/F2b); F1b, F1c, and F4a remain starred and phase-0-gated. Staleness: Concur product packaging changes; anything still starred is potentially stale as of the Jan 2026 cutoff.

  Limitations required No unsupported claims

Reusable Conclusion

Receipt capture is a solved problem inside Concur (email intake, mobile app, card feed); the value of an agent lies in reconciliation, itemization, classification, and assembly. Every write path into Concur beyond email is IT-gated (API, company-admin OAuth registration) or fragile/policy-risky (browser automation of the SSO'd UI). The realistic architecture is a local agent that aggregates and classifies receipts from Outlook and iPhone photos, pushes them into Concur via the supported email channels, and then either drafts reports via an IT-approved API app or assists a short human review/submit step — which of the two is the contract is a grill question, not a research answer. Refresh this conclusion if Concur product packaging changes or when the starred, tenant-private items (ExpenseIt licensing, e-receipts, Graph consent posture, tenant intake enablement) are verified against the live tenant in phase 0.