Approval workflows in accounting: controls that stop errors early
By Maren Calloway · October 27, 2026
Category: accounting-operations
An approval workflow only controls risk if the approver sees the real issue. Here is how to design routing, limits and evidence so approvals catch errors before they post.
Key takeaways
The problem Approvals exist on paper but approvers click through, because the screen shows an amount and no reason to look closer.
Core insight A control works when the approver sees what is unusual, and fails when every item looks the same.
Practical outcome Route by risk, show the one anomaly, set limits by amount and type, and review the approvals that were never questioned.
Say a controller reviews a sample of approved invoices and finds one paid twice. The approver on both was careful. Each copy looked normal in isolation.
This is the usual failure of approval workflows. The step exists, the name is on the record, and nothing was actually checked. Design decides whether a control works.
What an approval is for
An approval does one of three jobs. It confirms that the spending was authorized, that the goods or services arrived, or that the accounting is right. Mixing the jobs makes the step weak. An approver asked to confirm all three, for every item, will confirm none.
Write down which job each approval does. Then give that approver only the information needed for that job.
Types of approval workflow
- Single approver. Fast and cheap. Suits low-value, low-risk items.
- Sequential. A chain, such as manager then finance. Slow, and later approvers often rely on earlier ones.
- Parallel. Several approvers at once, each for a different job, such as budget owner and receiving.
- Conditional. The route depends on amount, vendor, account or exception type. This is the form that scales.
Most teams do best with conditional routing. Low-risk items take the short path, and unusual items take the long one.
Four design rules
Route by risk, not by habit
Set thresholds by amount, but add triggers for conditions: a new vendor, a changed bank account, an account that rarely gets postings, an invoice with no purchase order, a date near period end. These conditions matter more than the amount for fraud and error.
Show the anomaly
The approval screen should lead with what is different. "Price is 14 percent above the last six invoices from this vendor" is a reason to look. A table of fields is not. This is where an automated system helps most: it compares the item to history and states the difference in a sentence.
Keep the separation of duties
The person who enters should not approve, and the person who approves should not release payment. The idea is standard in internal control practice and is described in general terms under separation of duties. Software agents need the same treatment: give the agent its own identity, and do not let it approve its own work.
Make delegation explicit
Approvers go on leave. If delegation is informal, people share credentials. Build a delegation feature with a start date, an end date and a log entry, so a stand-in is visible.
Where automated controls fit
Automation can take over the checks that do not need judgment, and leave the judgment to people. Examples:
- Duplicate detection across vendor, number, amount and date, including near-matches.
- Three-way matching with tolerances set by finance.
- Blocking a posting into a closed period.
- Holding a payment when the bank details differ from the vendor master.
These are preventive controls. They act before the entry posts, which is cheaper than finding the error in close. The COSO internal control framework distinguishes preventive from detective controls and is a common reference for how to balance them.
Test the control, not the form
Once a quarter, test whether the approvals work. Pick a sample and ask three questions:
- How long did the approver spend on the item?
- Did the approver ever reject or query an item of this type?
- Could the approver see the reason the item was routed to them?
An approver who has never rejected anything in a year is not a sign of clean data. It is a sign of a rubber stamp. Seed the sample with a known error and see whether it gets caught.
A sketch of a workable policy
| Condition | Route |
|---|---|
| Matches PO and receipt, within tolerance, known vendor | Posts automatically; sampled monthly |
| Price or quantity variance beyond tolerance | Budget owner reviews variance |
| No PO | Manager approval, then finance review |
| New vendor or changed bank details | Finance verifies by callback; second approver releases |
| Above the payment limit | Named senior approver |
Treat the table as a starting point, and set the actual limits with your own risk owners. We do not give audit or legal advice here, so check your design with your auditors.
What to do next
Pull the last month of approvals and sort them by the time each approver took. The fastest ten percent are where your design is weakest. Ask what the approver saw on screen, and change that first.