Approval rules for a small team's expenses
Approval and review answer different questions, and a system that runs them through one queue does neither well. Review asks whether the extracted data matches the document. Approval asks whether the spending was appropriate. One is a data-quality task that anyone competent can do; the other requires authority and context about the business.
For a team of a handful of people, a workable approval design has three or four rules, not a policy document. The value is in choosing which three.
Why the two must stay separate
A review queue is worked by whoever is doing the books, quickly, against the image. Its triggers are technical: low confidence on a field, arithmetic that does not reconcile, a possible duplicate.
An approval queue is worked by whoever owns the budget, and its triggers are about money and policy: a large amount, an unusual category, a vendor nobody recognises, a missing business purpose.
Merge them and you get one of two outcomes. Either the bookkeeper is approving spend they have no authority over, or the budget owner is being asked to verify that a total was read correctly — a use of their attention that guarantees they will stop reading carefully. Both end in rubber-stamping, and a rubber-stamped approval is worse than none, because it leaves a record of consent that means nothing.
What an approval rule is made of
Four parts, and the fourth is the one people forget.
A trigger. The condition that sends an item for approval.
An approver. A named person, or a role with exactly one person in it at any time. “The management team” is not an approver.
A decision set. Approve, reject, or send back for information. Two options is usually too few — most rejections are really requests for a business purpose.
A default when nobody acts. Silence has to mean something specific. If it means the item sits forever, your month-end will be blocked by an expense from three weeks ago that everyone has forgotten.
Approval after the money has already gone
This is the part that differs from the purchasing process most teams imagine they have. When someone pays with a company card and photographs the receipt, the spend already happened. Approval cannot prevent it.
So what post-spend approval actually decides is allowability: whether this goes through as a business expense, whether it needs a note attached, whether it is coded to the category the spender chose. That is still worth doing — it is the point at which someone with context looks at the coding, and it is where a pattern gets corrected before it becomes habit — but calling it a control over spending is a misdescription that leads teams to over-engineer it.
Pre-spend approval exists too, for planned purchases above a threshold, and it is a different mechanism with a different trigger: a request, not a receipt. Do not try to run both through the same queue.
Thresholds set by consequence
Pick the amount by asking what would actually hurt if it were wrong or inappropriate — not by choosing a round number that feels responsible.
A threshold set too low is the single most common way an approval system dies. Every coffee goes to the director, the director approves forty items in one sitting without reading them, and the one item that needed a conversation goes through with the rest.
Two refinements worth having. A per-category threshold, because the amount that warrants a look is much lower for some categories than others — a modest sum on client entertainment may deserve more scrutiny than a larger one on materials. And a cumulative trigger, because a recurring small charge can matter more than a one-off large one; a subscription nobody has looked at in a year is exactly the sort of spend that no per-transaction threshold catches.
The rules worth having
Above your threshold. The base case.
A vendor nobody has used before. Not because it is suspicious, but because this is where a category precedent gets set, and correcting the first one prevents correcting fifty later.
Categories that require a purpose. Entertainment, travel, gifts, anything where the expense’s legitimacy depends on facts not printed on the receipt. Only the person who spent the money knows them, and they know them now rather than later.
No receipt attached. Worth approving specifically, because the substitute record needs to be written while the memory is fresh — the missing-receipt problem is about time, not paperwork.
Four rules covers most small teams. Adding a fifth should require pointing at something that went wrong.
Timeouts, absence, and the audit trail
Give every item a deadline and a default. Auto-approve after a period is a legitimate choice for low-consequence items and an indefensible one above your threshold; either way the behaviour should be a decision you made rather than a queue that grows.
Name a delegate before you need one. The approver goes on holiday, and the failure mode is not that nothing gets approved — it is that someone approves things in their name from a phone.
Record who decided and when, not just the state. “Approved” as a flag tells you nothing in six months. Approved by a named person on a date, with any note they left, is the thing that answers the question you will actually be asked.
Keep it out of chat. An approval given in a message thread is invisible to the books, unsearchable, and gone when the workspace history rolls over. If the decision matters enough to require an approver, it matters enough to live on the record.
The failure to design against
Everything requires approval, one person approves everything, and they do it in a single weekly sitting without opening any images. The system reports full compliance. Nobody has looked at anything.
The fix is always the same: fewer triggers, higher thresholds, and enough context on each item that deciding it takes seconds. Approval is only worth having if the approver is actually reading, and the way to get that is to ask them less often. Assembling the item so it can be decided at a glance is the part automation genuinely helps with.