Platform · operations

Expense reports that mostly write themselves

The expense report is a form asking an employee to re-enter information that already exists — the card already knows the merchant, the amount, and the date. What is genuinely missing is the receipt image and the business purpose, and those are the only two things anyone should be asked for.

accounts-payable-agentrunning
Bill arrives [email protected]
Extracted vendor · date · lines
Coded 6420 · Cloud hosting
Matched to PO PO-2291 · within 2%
Policy checked level 2 · under $2,500
Approved M. Reyes · controller
Posted to the ledger JE-88104 · period open
Journal entry JE-8810419 Aug
6420 · Cloud hosting4,180.00
2010 · Accounts payable4,180.00
Balanced4,180.004,180.00
Card matched to receiptPolicy checked at submissionCoded to project and department

What it does

Six things, specifically.

Card feeds first

Ramp, Brex, Amex, and standard card feeds arrive as the primary record. The transaction exists before anyone submits anything, so the report is a confirmation rather than a data-entry exercise.

Receipt matching

Photographed receipts extracted and matched to the card transaction on merchant, amount, and date. Unmatched receipts and unreceipted spend are both surfaced rather than one being ignored.

Policy at submission

Limits, categories, required receipts above a threshold, and prohibited items checked when the expense is submitted rather than discovered by an approver a fortnight later.

Coding and dimensions

Account, department, location, and project applied from history and from the cardholder’s own pattern, so expenses land in the right cost centre without the employee choosing.

Approval that follows the matrix

By amount, category, and department, with delegation for absence and escalation when it stalls. It reads your existing matrix rather than introducing a second one.

Reimbursement and settlement

Out-of-pocket claims routed for payment and card spend settled against the statement, with the difference between the two kept clear rather than blended.

Start from the transaction, not the form

Most expense software still models the expense report as the primary object: an employee creates a report, adds lines, attaches receipts, submits it. The card transaction is then reconciled against it afterwards, which is backwards — the transaction is the fact and the report is a description of it.

Inverting that removes most of the work. The transaction arrives from the card feed, gets coded from the cardholder’s history, and waits for a receipt and a purpose where policy requires one. What the employee does is confirm, not compose.

The card already knows the merchant, the amount, and the date. Asking an employee to type them again is asking them to describe a fact the system already holds.

Policy checking has to happen at submission

When policy is enforced by approvers, it is enforced inconsistently — different managers apply different standards, and rejecting a colleague’s lunch is socially expensive enough that most people let it through.

Checking at submission changes who the policy is coming from. The system declines an item outside policy, with the rule stated, before it reaches a person — so nobody has to be the one enforcing it. That is a small design decision with a large effect on whether the policy actually operates.

Unreceipted spend is the number worth watching

Most companies track receipt compliance as a percentage and chase the stragglers. The more useful framing is that unreceipted spend above your threshold is an audit exposure and a tax deduction risk, and it accumulates quietly.

Surfacing it as a balance by cardholder, ageing like a receivable, changes behaviour more than a monthly reminder does — largely because it becomes visible to the cardholder’s manager rather than only to finance.

Limits

Where this does not help.

Not a card issuer

We read your card programme rather than replacing it. Ramp, Brex, and Amex remain your card provider and your controls sit with them as well as with us.

Not travel booking

Booking, itineraries, and travel policy at point of sale belong in Navan or a TMC. We handle the spend once it exists.

It cannot make people take photographs

Receipt capture depends on somebody photographing the receipt. We make it easy and we surface the gap; we cannot close it for you.

Questions

What people ask.

Do we have to change card providers?
No. We read Ramp, Brex, Amex, and standard card feeds. Your card programme and its controls stay where they are.
What if someone loses a receipt?
It becomes unreceipted spend, aged and visible by cardholder rather than quietly written off. Whether you allow an attestation instead is a policy setting.
Can expenses be coded to projects?
Yes, with project and department applied from history and the cardholder’s pattern. For services firms this is what makes project margin include travel and pass-through properly.
Does it handle mileage and per diem?
Yes, at configurable rates with the appropriate tax treatment. Mileage claims are the most common out-of-pocket category and the one people most often get wrong manually.
How is out-of-pocket different from card spend?
Kept distinct throughout, because one becomes a reimbursement liability and the other settles against the card statement. Blending them is a common source of reconciliation difficulty.

Stop asking people to retype their card statement.

Tell us your volumes and card programme and we will show you what stops being manual.