Approval processes are written for companies with a procurement function. Most businesses don't have one. There are four of you, one person does the books alongside two other jobs, and "the approval process" is asking whoever ordered it whether it looks right.
That informal version is fine until it isn't — usually the first time something gets paid that shouldn't have, or the first time an accountant asks who authorised a payment and the answer is a Slack message nobody can find.
This is a workable middle ground.
What approval is actually for
Three separate things, often conflated:
Did we order this? Someone confirms the purchase was made and the goods or services arrived. Only the person who ordered it knows.
Is it coded correctly? The right nominal account, the right VAT treatment, the right job. Usually whoever does the books, and the step that sends invoices back most often.
Should we pay it, now? A cashflow decision as much as an approval. Often the owner.
| Question | Who can actually answer it |
|---|---|
| Did we order this, and did it arrive? | The person who ordered it |
| Is it coded correctly? | Whoever does the books |
| Should we pay it, and when? | Usually the owner |
Small businesses collapse these into one step, which is why approval feels like a formality — one person is being asked to confirm three things they can't all know.
The minimum that works
You need three things recorded. Not three people — three facts:
- Someone confirmed the purchase was real.
- Someone confirmed the coding.
- Someone authorised the payment.
In a four-person business the same person may cover two of these. That's fine, as long as it's recorded rather than assumed. The failure mode isn't one person doing two jobs — it's nobody being able to say afterwards who did what.
A threshold rule beats a blanket one
Requiring approval on everything means approving the £12 stationery invoice with the same ceremony as the £12,000 one. People stop reading, and approval becomes a rubber stamp.
Set a threshold. Below it, the bookkeeper posts and it's reviewed in the monthly batch. Above it, an explicit approval before payment. This is exactly the kind of rule worth handing to software once it settles, so the small ones stop consuming anyone's attention.
Where you set it depends on the business — but pick a number where a mistake would genuinely matter and you'd want to have caught it. For many small businesses that's somewhere between £250 and £1,000.
Add two exceptions regardless of amount:
- New suppliers. First invoice from anyone gets looked at properly. This is where invoice fraud lands.
- Any change to bank details. Always. See below.
The bank details rule
The single most valuable line in any approval process.
Invoice redirection fraud works like this: someone emails, apparently from a supplier you use, saying their bank details have changed. The invoice looks right because it usually is right — often a genuine invoice, intercepted and altered. You pay the real amount for real goods into the wrong account.
The rule: any change to supplier bank details is verified by phone, on a number you already had, not one from the email.
Not a reply to the email. Not a number in the signature. The number you already have.
This costs a two-minute phone call a handful of times a year and prevents the most expensive thing likely to happen to your purchase ledger.
Making it survive contact with reality
The reason approval processes fail in small businesses is not that people don't care. It's that the process assumes attention nobody has.
Approvals must be possible from a phone. If approval requires logging into a desktop system, the person who orders things — usually not at a desk — becomes the bottleneck.
Batch the requests. One message with six invoices beats six messages. Approvers respond to a list; they ignore a trickle.
Chase automatically, not personally. The bookkeeper shouldn't spend their week reminding people. A scheduled reminder is less awkward and more reliable, and it is the single fix for invoices that stall in approval.
Record the decision, not the conversation. "Approved by Sarah, 14 March" attached to the transaction. Not a Slack thread that's gone in ninety days.
What to avoid
Approval that happens after payment. Common, and it isn't approval — it's reconciliation. If the money's gone, the control did nothing.
Everyone approves everything. Diffuses responsibility. Two approvers who each assume the other looked properly is worse than one who knows they're accountable.
A process nobody can explain. If the person doing the books can't describe the rule in one sentence, it isn't operating. It's a document.
The test
Pick a payment from three months ago and ask: who approved this, and when?
If you can answer in under a minute from the accounting system — not from someone's memory or an email search — the process works. If you can't, that's what to fix, before adding any more steps.
Cribble routes documents through Admin, Finance and Approver roles before anything reaches your ledger, and records each approval against the transaction. Nothing posts until someone signs it off.