Most expense tools implement one document: the claim. An employee travels, spends money, uploads receipts, and a manager approves the reimbursement. It works, in the sense that people get paid back. What it does not do is control the spend, because by the time anyone looks at it the flight has been taken and the hotel has been slept in.
Ask any manager how many expense claims they have refused outright. The honest answer is almost none, and it is not because the claims were all reasonable. It is because refusing a claim for money already spent punishes an employee for a decision the company failed to intervene in, which no reasonable manager wants to do.
The two-step chain
Travel authorisation request, before the trip
The traveller states the purpose, destination, dates and estimated cost, and asks permission to commit that spend. Nothing has been booked, so refusal costs nothing and a cheaper alternative can still be chosen.
Line manager approves
The question at this level is whether the trip is necessary at all. The line manager is the only person who genuinely knows.
Department head approves
The question changes: does this trip fit the department's plan and priorities this quarter, alongside every other trip being requested.
Finance approves
The question changes again: does the budget carry it. This is the level that sees committed travel spend across the whole organisation rather than one department's view of it.
The trip happens, then the expense claim
The claim is raised with receipts and linked back to the authorisation, so the reviewer is comparing actual against a number the organisation already agreed rather than judging it cold.
Accounts Payable pays
A separate role releases the money. Accounts Payable cannot approve, and the approvers cannot pay. This is the step that makes the whole chain worth having.
What an auditor actually tests
Auditors rarely start by asking whether a policy exists. They pick a sample of transactions and try to trace each one end to end, and what they are looking for is whether the controls the policy describes actually operated. Three questions come up almost every time.
- Was the spend approved by somebody who could not also pay it? This is separation of duties, and it is usually the first thing tested, because a single person who can both approve and release money is the shortest path to a loss.
- Was the approval given before the commitment or after it? An approval dated after the flight was booked is evidence that the control is ceremonial.
- Can the sequence be reconstructed from records rather than from memory? A timeline showing who approved what and when, with delegations recorded as delegations, is the difference between a control that operated and a claim that it did.
The most common way separation of duties quietly stops being true is not fraud. It is a shared login: an approver on leave gives a colleague their password so the queue keeps moving. The records then show the absent manager approving from two countries away, and the control has failed without anyone intending it to.
Why the two-step model gets skipped
Because it looks like friction, and in a badly built system it is. If authorising a trip takes four days and three chase emails, people will book first and apologise later, and the control will be worked around rather than followed. Any organisation adding this step has to make each approval cheap: actionable from a phone, actionable from an email without signing in, delegable when somebody is away, and visible when it is stuck.
That is the whole design problem. The control is not the hard part; keeping it cheap enough that people use it is. A policy nobody follows provides exactly the same assurance as no policy at all, and costs more to maintain.