The problem
Emburse’s AI checks flag expense fraud and policy violations before a finance team approves a report. When a check flags too many legitimate expenses, reviewers stop trusting it. Some customers were disabling checks entirely, which removes the product’s value and puts the account at risk.
My role
I owned the accuracy and evaluation work for the AI compliance checks, one segment of the Assurance product. The Assurance product lead owned the full product. I wrote the proposals, requirements, and acceptance criteria; each went to the product lead for approval before engineering started.
The key insight
A long-standing, high-volume customer had quietly stopped using several checks over four months. When we dug in, it wasn’t one account: many customers had switched off the same checks.
The problem wasn’t model accuracy in the abstract. It was alert fatigue.
The trade-off
The obvious approach was to rank checks by model error rate and fix the worst first. The product lead made the key call: rank them by customers at risk instead. My job was to turn that into a plan the team could execute and measure.
Within that plan, I benchmarked candidate models on accuracy, cost, and latency together. The most accurate model isn’t the right one if it’s too slow or too expensive to run on every expense.
Gained
Effort went to the fixes most likely to protect revenue.
Gave up
Some low-volume checks with poor accuracy stayed on the backlog.
The pushback
As model and prompt versions multiplied, engineering pushed back: there was no stable way to tell whether a new version was actually better than the last. I proposed a golden dataset, a fixed set of human-labeled expenses that every version is scored against, and helped build it for several of the checks.
What I built
An evaluation framework built on golden datasets, with TP / FP / FN classification, error analysis, and pre/post-release regression testing.
A large-scale diagnosis: 3K randomized production evaluations across the US, Canada, and Europe.
A redesign of personal-expense detection: prompt strategy, requirements, and acceptance criteria, shipped across a 12-hour time-zone span.
26 Jira requirements across 7+ checks, turning discovery into an executable roadmap.
Three internal Python tools: an evaluation workspace, an LLM cost tracker, and Inspector, a support debugging app with 20+ daily users.
- Vendor
- Sample Taxi Co.
- Total
- 55.00 GBP
- Category
- Taxi → RideService
- Check result
- No violation
Results
| Metric | Before | After |
|---|---|---|
| Accuracy, personal-expense detection | 86% | 95%, shipped |
| Noisy alerts, two highest-volume checks | Baseline | 65%+ lower |
| Revenue influenced | – | $100K |
| Support analysis time per document | ~5 min | ~1 min (45+ hrs/week) |
What I’d do differently
I’d have planned earlier for managing checks as they matured. As accuracy improved, each check ended up at a different stage, with its own versions, baselines, and thresholds, and we handled that case by case. Next time I’d set up one shared way to track every check’s version and baseline from the start.