Approvals are a trust problem
Every finance team has an approval workflow. Few trust theirs. People forward payment requests by email, ask for sign off on a messaging app, and keep the real record in a spreadsheet. The official system exists, but the work happens around it.
When that happens, the workflow has failed at its only job. An approval process is not there to slow money down. It is there to make a promise: that every payment of a given kind was seen and agreed by the right person, and that you can prove it later. If the people using it do not believe the promise, they will route around it.
So the design question is not "how many steps?" It is "what would make a finance lead comfortable relying on this?"
Start from risk, not hierarchy
The common mistake is to copy the org chart. A manager approves up to one limit, a director to a higher one, and the finance head signs off on everything above that. It looks tidy and it is often wrong.
Risk does not follow seniority. A small payment to a brand new beneficiary is riskier than a large one to a supplier paid every month. A change to bank details matters more than the invoice it affects. A payment just under an approval threshold, repeated several times, matters more than a single large one.
Better rules ask about the payment itself:
- Is the beneficiary new, or has the account changed recently?
- Is the amount unusual for this payee or this category?
- Does the payment sit near a threshold?
- Is the requester also the person who set up the payee?
Amount still belongs in the rules, but as one input among several. A workflow built this way asks for more scrutiny where it is needed and leaves routine payments alone.
Separate the roles, then enforce it
The oldest principle in financial control is segregation of duties: the person who requests a payment should not be the person who approves it, and neither should be the person who releases it. Most teams agree with this and most systems quietly permit exceptions.
Enforce it in the software, not in a policy document. If the requester cannot approve their own request, say so in the system and make it impossible rather than discouraged. Do the same for the person who creates a payee. This is not about distrust of individuals. It is about making sure no single compromised account, or single moment of pressure, can move money alone.
There will be edge cases: a two person finance team, an absent approver, an urgent supplier. Design for them openly, with a defined delegate or an emergency path that is logged and reviewed afterwards. An exception with a record is a control. An exception made through a side channel is a hole.
Make the state obvious
Finance teams lose trust in workflows when they cannot tell what is happening. A request has been sitting for three days. Is someone reviewing it? Has it been missed? Was it approved and not sent?
A trustworthy workflow shows, at a glance:
- Where the request is, in plain words, and with whom.
- What happens next, and what is being waited on.
- What has already happened, with who, when and why.
"Pending" is not a state. "Waiting for second approval from the finance lead" is. Rejections should carry a reason in the approver's own words. Without one, you get a second request, then a third, then a phone call.
Keep an audit trail that cannot be edited
An audit trail is useful only if everyone believes it was not altered. Record each action as an append only entry: who, what, when, from which context, and what the values were before and after. Do not let users, including administrators, edit or delete history. If a mistake was made, the correction is a new entry that points to the old one.
When an auditor, a regulator or a worried director asks "who approved this and why?", the answer should take seconds and should not depend on anyone's memory. The same record also protects the people approving. Knowing that their decision is documented fairly, with the information they had at the time, makes them more willing to use the system instead of avoiding it.
Respect the approver's time
A control that is painful gets bypassed. Approvers are busy and often not at a desk. If the process demands that they log in, find a request and chase supporting documents, they will approve in batches without reading, or delegate informally.
Give them what they need in one place: the payee, the amount, the reason, the supporting invoice, and anything unusual flagged clearly. Let them approve or reject from a phone. Send reminders that escalate sensibly, not noise that trains people to ignore it.
A short test
Before shipping a workflow, ask four things. Can one person move money alone? Can anyone tell, in ten seconds, where a request stands? Can history be changed? Would an approver on a bad day still do the right thing with this screen?
If the answers are no, no, no and yes, the team will trust it, and trust is what turns a control from a formality into something people actually use.