An approval workflow is the set of rules that decides who must approve a request (a purchase, invoice, expense, contract or change) before it takes effect, in what order, within what time, and what is recorded. A sound design routes by an approval matrix, enforces segregation of duties, handles absence through controlled delegation and keeps a complete audit trail.
Most approval problems are not software problems. They come from rules nobody wrote down, approvers who sign anything to clear their inbox, and edits made after approval that nobody re-checks. This guide works through the design decisions in the order you will meet them, then gives a test plan and a checklist. It applies whether approvals live in an ERP, a workflow tool or a custom ERP build.
What is an approval matrix and how should you design one?
An approval matrix is a table that maps the attributes of a request (type, amount, department, entity, category) to the approvers it needs. It should be data the business can maintain, not logic buried in code.
Common routing dimensions:
- Amount. Bands, each adding an approval level.
- Department or cost centre. The budget holder approves spend against their budget.
- Legal entity. In a group, each company has its own signatories. Our guide to multi-entity ERP governance covers entity-level controls.
- Category. IT, capital expenditure, contracts or marketing may need a specialist approver whatever the amount.
- Vendor status. A first purchase from a new vendor may need an extra check.
An illustrative matrix for purchase requests (the thresholds are examples; set your own):
| Request | Condition | Approvers | Order |
|---|---|---|---|
| Purchase request | Up to 1,000 | Budget holder | Single |
| Purchase request | 1,000.01 to 10,000 | Budget holder, then department head | Sequential |
| Purchase request | Above 10,000 | Budget holder, department head, then finance director | Sequential |
| Any purchase | Category: IT hardware or software | Add IT lead | Parallel with budget holder |
| Any purchase | Capital expenditure | Add financial controller | After department head |
| Any purchase | New vendor | Add procurement vendor check | Before first approval |
| Contract | Term over 12 months or auto-renewal | Add legal review | Parallel with finance |
Three rules make a matrix workable. Define boundaries precisely (does 1,000 fall in the first or second band?). Give every row a fallback approver, so a gap in the matrix never means "no approval needed". And version the matrix: record which version routed each request, so an audit can see the rules that applied at the time.
Should approvals be sequential or parallel?
Use sequential steps when a later approver relies on an earlier one, and parallel steps when approvers check independent things. Many workflows mix both.
| Pattern | How it works | Use when | Watch for |
|---|---|---|---|
| Sequential | Each approver acts after the previous one | Budget holder confirms need before finance checks funds | Slow; one absent approver blocks everything |
| Parallel, all must approve | Several approvers act at once; all required | IT and finance check different aspects | One rejection should stop the others |
| Parallel, any one approves | First approver from a group decides | A pool of equally authorised approvers | Make sure the group really is equivalent |
| Conditional step | Added only when a rule fires | Legal review only for certain contracts | Conditions must be tested at their boundaries |
How should escalation and approval deadlines work?
Every step needs a target turnaround, reminders before it is missed, and an escalation path after. A timeout should never approve a request automatically.
A typical pattern: a reminder when half the target time has passed, a second reminder at the deadline, then escalation to the approver's manager or a named deputy. Measure deadlines in business days on the right calendar for each entity, since public holidays differ by country. Report on steps that regularly breach their target: a step that always escalates is usually in the wrong place or held by the wrong person.
How should delegation and out-of-office rules work?
Delegation lets an approver hand their authority to someone else for a defined period. Without controlled delegation, people share passwords or approve from their phones on holiday without reading.
Rules worth enforcing in the system:
- A start and end date on every delegation; no open-ended delegations
- A scope: all requests, or only certain types, entities or amounts up to a cap
- The delegate must hold a role that could approve in their own right, or the delegation needs a further sign-off
- A delegate can never approve their own request
- No chains: a delegate cannot re-delegate
- The record shows "approved by A on behalf of B", never just B
- Delegations are themselves logged and reviewable
How do you enforce segregation of duties?
Segregation of duties means no single person controls a transaction from start to finish. At minimum, the requester, the approver and the person who releases payment should be different people, and the system should enforce it rather than rely on habit.
NIST SP 800-53 (Rev. 5) includes separation of duties as control AC-5: organisations identify duties that need separating and set system access so they are separated. In an approval workflow that becomes rules like these:
| Duty | Must not also | Why |
|---|---|---|
| Raise a purchase request | Approve the same request | Self-approval |
| Approve an invoice | Release its payment | Approval and payment in one hand |
| Maintain vendor bank details | Release payments | Redirecting payments |
| Configure the approval matrix | Approve requests routed by it | Changing the rules to suit a request |
| Post the goods receipt | Approve the invoice for the same PO | Confirming your own delivery claim |
Small teams cannot always separate every duty. Where they cannot, use compensating controls: a regular after-the-fact review of transactions where one person held two roles, signed off by someone independent.
What should happen when a request is edited after approval?
Changes to material fields after approval should restart approval; changes to non-material fields should be logged without restarting it. Decide which fields are which before you build.
- Material (restart approval): an amount increase beyond a set tolerance, vendor, bank details, legal entity, cost centre, category, currency, payment terms
- Non-material (log only): description wording, an extra supporting attachment, an internal note
- Decreases: many organisations let amounts go down without re-approval, but record the change
Once approved, lock the record. Changes go through an amendment that keeps the approved version intact, so anyone can compare what was approved with what was paid.
What should an approval audit trail record?
An audit trail should answer who did what, when, to which record, with what result, and what the data looked like before and after. NIST SP 800-53 control AU-3 sets out similar content for audit records: the type of event, when and where it occurred, its source, its outcome and the identity of those involved.
| Element | Example |
|---|---|
| Who | User ID, and "on behalf of" for delegations |
| What | Submitted, approved, rejected, recalled, edited, escalated, delegated |
| When | Timestamp with time zone |
| Which record | Request ID and version number |
| Before and after | Field-level changes, such as amount 4,800 to 5,600 |
| Why | Approval or rejection comment; mandatory on rejection |
| Rule applied | Matrix version and the row that routed the request |
| Channel | Web, mobile or email link |
Make the trail append-only: no one, including administrators, should be able to edit or delete entries through the application. Make it easy to read too, as a timeline on each record, so managers use it and do not only discover it during an audit.
How should notifications and mobile approval work?
Notifications should carry enough context to decide (requester, amount, purpose, budget status) and a link that opens the request after sign-in. Avoid one-click approval links in email that work without authentication; a forwarded email should not carry approval authority.
Mobile approval earns its place when approvers travel or work on site. Show the key fields and the attachments on a small screen, require the approver to open the request before acting, and record the channel in the audit trail. For high-volume approvers, a daily digest with batch review of low-value items reduces noise; keep high-value items as individual notifications.
How should exceptions be handled?
Exceptions need defined paths, because people will improvise if the system gives them none.
- Emergency purchases: allow a retrospective approval route, clearly flagged and reported monthly
- Rejections: require a reason; let the requester amend and resubmit as a new version
- Recall: let the requester withdraw before final approval
- Approver leaves the organisation: reassign their open items automatically to the fallback approver
- No matching matrix row: route to the fallback owner; never pass through unapproved
Where can AI help, and where must people decide?
AI is useful for preparing decisions: classifying a request into the right category, suggesting a cost centre or account code, routing to the right matrix row, flagging likely duplicates and summarising long supporting documents. If requests arrive as documents, extraction is covered in our intelligent document processing guide.
People must make the decisions that carry accountability: approving spend, overriding policy, granting segregation-of-duties exceptions and accepting a new vendor. Record AI output as a suggestion with the person who accepted or changed it, and never let a model's classification lower the approval level a request needs without a rule check.
How do you test an approval workflow?
Test the rules, not only the screens. Each matrix row, boundary and control needs a test case with a predicted result.
| Test | Example case | Expected result |
|---|---|---|
| Band boundaries | Requests at exactly 1,000.00 and 1,000.01 | Each routes to the band you defined |
| Every matrix row | One request per row and condition | Correct approvers, correct order |
| Segregation of duties | Requester tries to approve own request | Blocked, attempt logged |
| Delegation | Delegate approves inside, then outside, the delegation period | Allowed, then blocked |
| Edit after approval | Increase amount above tolerance | Approval restarts |
| Escalation | Leave a step idle, with a test clock | Reminders, then escalation; no auto-approval |
| Concurrency | Two parallel approvers act at the same moment | One consistent final state |
| Audit trail | Review the trail after each test | Every action recorded with before and after values |
| Mobile | Approve from phone with attachments | Same rules, channel recorded |
Then run a short parallel period with real requests, comparing the workflow's routing with what the current process would have done.
Approval workflow design checklist
- Approval matrix written as data, with exact band boundaries and a fallback approver per row
- Matrix versioned, with the version stored on every request
- Sequential and parallel steps chosen by dependency, not habit
- Turnaround targets, reminders and escalation; no automatic approval on timeout
- Delegation with dates, scope, cap and "on behalf of" recording
- Segregation-of-duties rules enforced by the system, with compensating controls where needed
- Material and non-material fields defined; re-approval rules built and tested
- Append-only audit trail with before and after values
- Notifications that need sign-in to act
- Exception paths for emergencies, recalls, leavers and unmatched requests
- AI limited to suggestions, recorded as such
- Test cases for every row, boundary and control, signed off by finance or internal audit
When is a new approval system not the answer?
If your ERP or accounting system already supports configurable approvals that cover your matrix, configure it before you build anything. If the matrix itself is not agreed, software will only encode the argument. And if a request already needs five approvals, adding automation will not fix the delay: fewer levels with clearer authority will. Our introduction to business process automation and the collection of business process automation examples help decide what is worth automating first.
How Timeline Digital approaches approval workflows
We start from your approval matrix and controls, then build the workflow, delegation, audit trail and integrations around them; see our workflow automation service. Timeline Digital starts with a free pilot of 2 to 3 key modules before the full project, so your finance team can test the approval rules on real requests before the wider rollout is agreed.