Automating expense reports without losing the receipts

An expense claim is four things: a receipt, a category, an approver and a reimbursement. Automated expense reporting usually rebuilds the middle two — a form, a dropdown, a notification — and quietly loses the first. The receipt is the only part of the claim that is evidence; everything else is derived from it. When the receipt is missing, the derivative is an assertion, and month end becomes the work of turning assertions back into evidence.

Why does the receipt decide whether expense report automation works?

Because every other field can be reconstructed from it, and it cannot be reconstructed from them. An amount, a date, a merchant and a currency are facts on the document. The category is an interpretation. The approver is a decision. If capture stores the interpretation and drops the document, the claim cannot be defended in an audit, corrected after a misread, or compared with the bank line it should match.

The practical test is whether a claim can be settled without asking the employee anything. If the answer is no, the missing piece is almost always a document that was photographed, forwarded or handed over and never attached to the line it belongs to.

What are the capture paths, and which one loses the receipt?

Every business runs several, and the loss is different in each:

Capture path	What survives	What usually disappears
Photo taken at the counter	a clear image with a timestamp	the claim it belongs to, because it stays in the gallery
Receipt forwarded by email	the attachment, sender and date	the card transaction it should match
Monthly pile of paper	the best image quality of all	the date and the context of the spend
Capture in the app at the point of spend	image, amount, currency and date together	nothing, but adoption is the risk

The pattern is not that one path is better: the receipt and the claim are separated by time in every path except the last, and the gap is where the document is lost. Starting at the monthly pile automates the recovery of a loss, not the capture of a receipt.

What does the category actually decide?

Four things, none of which the claimant is qualified to choose:

• The account it posts to, and the budget line that absorbs it.
• The tax treatment: whether the amount is recoverable or deductible.
• Whether prior approval was required, because some categories cannot be claimed afterwards.

So the category picker is not a form field. It is a ledger entry made by the person with the least information about the ledger. The workable split is to let the claimant state what was bought, in their own words, and let the system derive the account from a mapping that finance owns and versions. When the mapping changes, past claims keep the entry they were posted under.

What is an approver actually approving?

Not the amount. The business purpose. A line manager signing a claim is asserting that the spend happened for the business, in the period claimed, for the people named, within the budget available — and that assertion needs the receipt in front of them, not a file name.

The approval screen shows the document, the purpose, the date, the attendees where relevant, the budget line it hits and any flag from card matching. If it shows only a total and a category, the approver signs a number they cannot check.

An approver who was on the trip cannot approve that claim. If the routing table says "line manager" and allows it, the control exists on paper only.

Why is the month-end reconstruction the real cost?

Because it is a second pass over the same information. Claims arrive late, receipts are missing, someone rebuilds a month of small purchases from a bank statement, categories are guessed to close the period, and the total then fails to reconcile with the ledger. Investigating the difference is paid work nobody's job description mentions.

The quieter cost: when reimbursement is slow and unpredictable, employees stop submitting small claims. The costs still happen; they stop appearing, and the month looks complete when it is not.

How should the claim be built?

1. Capture at the point of spend, from a phone, in one action: image, amount, currency, date.
2. Create the claim line at the same moment, so a document is never attached to a batch already approved.
3. Separate description from account. The claimant writes what was bought; the system assigns the ERP account from finance's mapping.
4. Match against the card or bank line where one exists, and treat unmatched lines as the exception queue rather than as errors.
5. Show the approver the evidence, and record the decision together with what was on screen at the time. That provenance is what the W3C data on the web best practices describe, and what lets a reviewer reconstruct the decision.
6. Lock the claim after approval. A later change is a correction with its own record, tied to an authenticated account rather than a shared one, as the OWASP authentication cheat sheet argues for identity before authorisation.
7. Reimburse on a fixed cycle and publish the cycle, so the delay is a known term instead of a grievance.

The order matters more than the list. Capture first, because every later control depends on the document being present.

Where this goes wrong

The receipt that lives in a chat thread. A photo sent to a manager on a messaging app is a document nobody can find at audit time. If the process accepts it there, it must move it into the claim in the same step.

Treating recognition as capture. Reading an amount and a date off an image is useful; the merchant and the line items are what make the claim defensible. A claim that stores only a total is a number with a picture beside it.

A category list long enough to be ignored. Dozens of options produce mostly "other", which is no category at all. A short list, owned by finance and mapped to accounts behind the scenes, survives real users.

Editing after payment. An approved claim that stays editable destroys the audit trail. Corrections belong in their own record.

What this does not cover

This is the mechanism, not the policy. Per-diem rates, which categories are deductible, whether a claim without a receipt may be accepted against a declaration, and how advances interact with reimbursement are decisions for the finance function and, in some countries, for a tax adviser; nothing here should be read as a rule about any of them. It also assumes a phone and a connection at the moment of spend, which is not universal, so a paper path with a scanning step still has to exist.

We build expense capture around the receipt first, because a report that cannot show its evidence is a report someone has to rebuild by hand at the end of every month.