Designing approval workflows that keep controls intact
An approval workflow has two jobs that pull in opposite directions. It has to stop the wrong payment, and it has to let the right one through without a week of waiting. This page covers how to design routing rules, where exceptions should go, and what an audit trail has to contain to be useful when someone asks a hard question later.
Start with the control, not the tool
Before choosing software, write down what you are trying to prevent. Paying a duplicate invoice. Paying a vendor whose bank details changed. Paying for something nobody approved. Each of those is a specific control, and each maps to a specific rule.
Teams that start with the tool end up configuring whatever the vendor ships. Teams that start with the control end up with a workflow they can explain to an auditor. The second group spends less time on rework, because the rules were written for a reason someone can repeat out loud.
Write the control in one sentence. If you cannot, the rule behind it will be just as vague when it is built into the system.
A rule that needs an exception every week is not a rule. It is a queue with paperwork.
Thresholds, vendor categories, and department ownership cover most invoices. When a rule keeps producing the same exception, rewrite the rule instead of staffing around it.
Routing rules that people actually follow
Rules should be simple enough that approvers can predict them. Amount thresholds, vendor categories, and department ownership cover most cases. The failure mode is over-routing: sending every invoice to three people because it feels safer. That creates a queue where nobody feels responsible, and approvals stall.
Each approver knows exactly which invoices land with them and why. Responsibility is obvious, and a stalled item has one obvious owner to ask.
Everyone assumes someone else already looked. Approvals wait on whoever opens the tool last, and the audit trail shows five names without showing a decision.
Two approvers with clear thresholds beat five with overlapping ones. Keep the count as low as the control allows, and write the threshold next to the approver's name so the routing is readable without opening the system.
If a rule needs an exception every week, the rule is wrong, not the exception. Log the exceptions for a month, then rewrite the threshold or the vendor category that keeps producing them.
Where to start
- Set the amount threshold where a mistake would hurt, not where a policy template says.
- Assign vendor categories to the people who already know those vendors.
- Write down what happens when a threshold is crossed twice in one week.
Exception paths and who owns them
Exceptions are the invoices that do not fit the rule: missing purchase order, price mismatch, new vendor, changed bank details. Each type needs a named owner and a defined path. A changed bank detail, for example, should never be approved by the same channel that requested it.
Stampli is built around this idea, putting communication and approval context on the invoice so the person resolving the exception sees the whole history. Without a defined path, exceptions sit in the general queue and slow everything behind them.
Route to the requester's manager, who can confirm the spend happened or return it to the vendor contact.
Route to whoever holds the contract or quote, with the original document attached next to the invoice.
Route to finance, verified by phone with the vendor using a number you already had, never the number on the request.
Segregation of duties in a small team
Small teams cannot fully separate duties; there are not enough people. What they can do is make sure the person who enters a vendor cannot also change its bank details, and that the person who approves a payment is not the person who initiates it.
Where that is impossible, add a review step and a record. The audit trail is what compensates for a small team. If two people have to do the same task, the system should show both actions, not merge them into one.
What a small team can separate
- Vendor setup and vendor bank detail changes belong to different people, even if it means a short review step for one of them.
- Payment initiation and payment approval stay with two names, and the system records both.
- Any single-person step that cannot be split gets a second set of eyes and a written reason in the record.
What an audit trail has to contain
An audit trail is not a log file. It needs to answer who approved, when, what they saw, and what changed afterward. That means the approval is attached to the document version the approver reviewed, and any later edit is recorded separately.
Electronic document storage is part of this: the invoice image, the coding, the approval, and the payment record stay linked. If any of those live in a different system, reconstructing the story later takes days instead of seconds.
When approvals span several systems
Many workflow failures are not data problems, they are human-approval problems. The invoice is coded correctly and the approver simply never opens the tool. Moxo appears in accounting automation roundups as a coordination layer that routes tasks, approvals, and follow-ups across systems. It wraps around existing accounting tools rather than replacing them.
For teams whose approvals cross AP, procurement, and finance systems, that layer addresses the gap between tools rather than the tools themselves. The practical test is whether the approver sees the request where they already work, with enough context to decide, and whether the decision flows back to the accounting system without re-entry.
What coordination fixes
Requests reach the approver in the place they already check, so decisions stop waiting on a tool nobody opened.
What it does not fix
A vague rule or an unowned exception type. Routing software moves a bad rule faster; it does not make it a good rule.
What to check first
Whether a decision made outside the accounting system lands back in the audit trail with the same detail.
Testing a workflow before you rely on it
Run a month of real documents through the new rules before you turn off the old process. Watch for invoices that bounce between approvers, rules that fire on the wrong vendor, and exceptions with no owner. Fix those before go-live, not after.
A workflow that works on ten test invoices can still fail on the four hundredth, because that is the one with the unusual vendor and the changed bank account. Volume is what exposes design flaws.
Run real documents in parallel
Keep the old process live while the new rules handle the same invoices, so you can compare what each one would have done.
Watch for bouncing invoices
An item passed between three approvers and approved by none is a routing defect, not an approver problem.
Close every exception with an owner
If a test exception has no named path, the live version will not have one either. Fix it before go-live.
Documenting the workflow for auditors
Keep a written description of the approval rules, who owns each exception type, and how changes to the rules are approved. When an auditor asks how a payment was authorized, you should be able to point to a rule and a record, not a conversation.
This documentation takes an afternoon and saves a week. It also forces the team to notice rules that exist on paper but not in the system, which is a common and quiet control gap.
What the written description covers
- The approval rules in plain language, with the amount thresholds and vendor categories that trigger them.
- The named owner for each exception type and the path it takes when it is raised.
- How a change to the rules is requested, who approves it, and where the change is recorded.
- Which system holds each part of the record, so a question can be traced without hunting through inboxes.
Signs your approval workflow needs redesign
Watch for invoices approved after payment, approvals given in bulk at month end, and approvers who routinely approve without opening the document. Each of those is a control that exists in name only. Also watch for a growing queue of items waiting on one person, which usually means the threshold is set too low.
Redesign is not a failure; it is maintenance. Approval rules drift out of fit as a company changes, and reviewing them once a year is cheaper than fixing them after an audit finding.
The record shows an approval date later than the payment date. The control ran as a formality.
Forty decisions in ten minutes is not review. It is a queue being cleared so the close can finish.
If the system can show the approver never viewed the invoice image, the approval carries little weight.
When everything waits on the same name, the threshold is probably set below the level that needs a second look.
Questions teams ask before they rebuild
Short answers to the three things that come up in almost every redesign conversation.
How we evaluate automation toolsHow many approvers should an invoice have? +
As few as the control requires. Two approvers with clear thresholds usually work better than five with overlapping rules, because each person knows exactly which invoices are theirs and why.
What belongs in an audit trail? +
Who approved, when, what document version they saw, and any changes made afterward. The approval must be linked to the record it authorized, so the trail runs in both directions.
Can approval workflows handle exceptions? +
They should route exceptions to a named owner on a separate path, so routine invoices are not delayed behind unusual ones. An exception with no owner will sit in the main queue and slow everything behind it.
Plan the rollout before the rules go live
Map the rules you already have, the exceptions they produce, and the owners who will hold each one. Then decide which parts of the chain you are moving first and what stays manual while you test. A short written plan keeps the project from becoming a configuration exercise.
Reach Finoradeks
- 8920 Corporate Drive, Building B, Austin, TX 78758, USA
- +1-512-558-7445
- [email protected]
- Monday to Friday, 9:00 AM to 6:00 PM
Finoradeks publishes comparisons and guides on bookkeeping and accounting workflow automation. We are not affiliated with the software vendors named on this page.