Expenses that sort themselves out.
A self-initiated redesign of the SAP Concur expense flow. Travellers snap a receipt and only confirm what the app isn’t sure of, policy is checked before anyone submits, and approvers see the few claims that need them instead of the whole pile. Not affiliated with or endorsed by SAP Concur.
Role
Product designer (solo, self-initiated)
Timeline
November 2026
Scope
Receipt capture (iOS), approvals (web)
Tools
Figma
01 · In brief
The short version.
Problem
Filing expenses means retyping what’s already on the receipt, then finding out days later that something broke policy.
My role
Solo product designer: desk research, journey mapping, flows, iOS and web UI, and a reusable design system.
Approach
Follow one claim from receipt to reimbursement as the traveller, the approver and finance, then remove every step a person doesn’t need to take.
Output
Four iOS capture screens, a web approvals dashboard and a set of success targets. A concept, not a shipped product.
02 · Challenge
Expense tools still make people do the computer’s job.
Most of the work in an expense report is copying what’s already printed on the receipt. Mistakes surface after submitting, and approvers get every claim in one long list. The GBTA Foundation puts the average report at $58 and 20 minutes to process, with roughly one in five containing errors that take a further 18 minutes and $52 to fix (as cited by Corpay, 2026).
How might we
How might we make a clean expense take seconds, and only ask a person to step in when something actually needs them?
03 · My experience
Filing expenses was always the part of a work trip I put off.
I’ve filed claims in expense tools at work, and the same three things kept going wrong. I’d photograph a receipt, then retype the merchant, date and amount anyway because the scan got one of them wrong. A claim would bounce back days later for a rule I couldn’t see when I submitted it, like a meal cap I didn’t know existed. And every receipt from the same trip asked for the same trip details again.
04 · Desk research
What people say in public reviews.
I read reviews of SAP Concur on G2, Capterra and the App Store. Ratings are good overall (4.0 on G2 from 7,232 reviews, 4.3 on Capterra), and many people like snapping receipts on their phone. The complaints cluster in the same three places.
Scanning that half-works
“It is constantly attaching receipts to the wrong transactions.” App Store review
Errors that don’t explain themselves
“Error codes that do not adequately explain how to correct the errors.” Territory manager, Capterra, May 2026
Too many clicks
“The user interface feels clunky and unintuitive, often requiring too many clicks to perform basic tasks.” Procurement manager, Capterra, Oct 2026
Sources: g2.com, capterra.com and the US App Store listing, checked 11 Nov 2026. Quotes are chosen to show recurring themes, not a representative sample.
05 · Who it’s for
Who I designed for.
I mapped the three people every claim passes through, from the public reviews above and my own experience. These are proto-personas, not interview findings, so the quotes are illustrative.
06 · Direction
Principles before pixels.
Before drawing screens, I wrote three rules and checked every screen against them.
07 · Receipt capture
Typing becomes the exception, not the job.
The camera captures on its own once the receipt is steady. Fields the app is confident about are filled and ticked. Anything it isn’t sure of, like the currency on a German hotel bill, gets one clear question. Policy is checked straight away, and expenses group themselves into a trip.
08 · Approvals
A dashboard built around decisions.
Claims that pass every check are approved in one batch. The few that don’t open beside the list with the receipt, the rule they broke and the employee’s reason, so each decision takes one screen.
09 · Before and after
What changes for the approver.
A simplified version of a typical approval queue today next to the redesign, using the same 128 claims.
10 · Edge cases
The messy claims that break simple flows.
Split costs and guests
A team dinner can be split by person. Guests are named once and remembered for next time.
Foreign currency
When a receipt matches a card payment, the card’s exchange rate is used, so nobody types a rate.
Per diems and mileage
These have no receipt, so they’re built from the trip dates and a route instead of a photo.
11 · Measuring success
Targets, set before testing.
These are targets set before testing, not results. Each one maps back to a pain point.
12 · Options I rejected
Options I rejected.
Each rule in the direction section came from turning down the way expense tools usually work.
✕ Rejected
A shutter button
✓ Instead
The camera captures on its own once the receipt is steady.
✕ Rejected
Checking policy after someone submits
✓ Instead
Policy is checked the moment a receipt is added, so problems are fixed on the spot.
✕ Rejected
Every claim in one long list
✓ Instead
Clean claims are approved in one batch. Approvers only see the exceptions, each with a reason.
✕ Rejected
Rule codes in error messages
✓ Instead
Rules in plain words, the same on the phone and in the approver’s flag.
13 · Reflection
What I’d take from this.
Design for everyone who touches it
Most of the wasted time isn’t with the person filing. It’s with approvers and finance, so they shaped the design as much as the traveller.
Remove, don’t add
The strongest changes are steps that no longer exist: no retyping, no surprise rejections, no reviewing clean claims.
What I’d test next
Whether approvers trust a one-click batch, or want to spot-check clean claims first.
Next project