Approval workflow controls are the rules that make an approval trustworthy: limits tied to a person's delegated authority, thresholds that cannot be dodged by splitting a request, separation of duties between requester, approver, releaser and configurer, and an append-only audit trail. Define each as a control with an owner, a test and evidence.
When a CFO, controller or CIO asks how approval platforms handle "per-action approvals with delegated approvers and audit trails," the real question is whether the controls will stand up when someone checks them. This guide takes the control and audit view. Designing the approval matrix, including delegation rules and basic role conflicts, is in our approval workflow design guide. This guide adds a control matrix with tests and evidence, anti-splitting logic, separation of duties for workflow builders, IT ticket routing and protection of the log itself, plus a way to evaluate any platform without ranking vendors. If you need these controls built into a custom system, see workflow automation and AI development for approvals with AI steps.
Key takeaways
- Treat each approval rule as a control: a risk, a rule, an owner, a test and the evidence it leaves.
- Authority belongs to a person and a limit, not to a screen. A delegate can never approve beyond their own authority.
- Thresholds need anti-splitting logic, or they are decorative. Aggregate by commitment, not by document.
- Separation of duties also covers the people who build and change the workflow: the author, the releaser and the configurer.
- The audit trail must be append-only, time-stamped and protected from administrators, and it must record the rule version that routed each item.
- Auditors test whether controls operate, so re-perform them yourself first.
What controls should an approval workflow have?
An approval workflow needs controls for who may approve, how much, in whose absence, who must be a different person, what happens on change, and what is recorded. The matrix gives each an owner, evidence and a test. Controls are preventive (they stop the event) or detective (they find it afterwards); use both.
| Risk | Control | Owner | Evidence | How to test |
|---|
| Unauthorised spend | Approver limits stored per person and role | Finance controller | Approval record with limit applied | Submit above the limit; confirm upward routing |
| Self-approval | System blocks approver equal to requester | Process owner | Block log | Try to approve your own request |
| Splitting to avoid limits | Cumulative check by vendor, requester and period | Finance controller | Split-detection report | Submit three requests just under the limit |
| Misuse of delegation | Dated, scoped, capped delegation | Process owner | Delegation register | Delegate beyond own limit; use an expired one |
| Approval and payment in one hand | Releaser differs from approver | Finance controller | Role conflict report | Assign both roles to one user |
| Rule tampering | Matrix changes need a different approver and are versioned | Internal control lead | Change log with approver | Edit the matrix without approval |
| Change after approval | Material edits send the request back | Process owner | Version history | Raise the amount after approval |
| Missing record | Append-only audit log | IT security | Immutable event log | Attempt to edit or delete an entry |
| Control drift | Periodic review of roles, delegations and overrides | Internal control lead | Review sign-off | Sample and re-perform the review |
How should delegated authority work?
Delegation rules (dates, scope, caps, no chains, on-behalf-of recording) are set out in our approval workflow design guide. The control view adds three tests: a delegate cannot exceed the delegator's limit or their own authority, expired delegations fail, and delegations are reviewed for leavers.
Keep two layers apart. A delegation of authority policy says which roles may commit the company to what amounts; a system delegation is a temporary hand-over inside the workflow, such as covering leave. The second must stay inside the first. This is also the practical answer to "the CFO is a bottleneck": raise limits for lower roles under policy and allow documented delegation, rather than sharing credentials.
How should approval thresholds be set so they cannot be avoided?
Base thresholds on the total commitment, not the individual document, and test them against splitting. Define bands with exact boundaries, a fallback approver for every row, and a rule that aggregates related requests over a rolling period. A threshold that sees one invoice at a time is decorative.
Anti-splitting controls that work:
- Aggregate by vendor, requester, cost centre and contract over a rolling window, not only the calendar month, because splits cluster at period ends, and route the combined total.
- Identify vendors by tax number and bank account, not by name, so a duplicate vendor record cannot reset the running total.
- Treat a material change as a new approval. Amount, vendor or bank details changing after approval sends the request back.
- Define boundaries exactly: "up to and including" or "below", gross or net, and which exchange-rate date applies. Version the matrix and record which version routed each item.
- Run a detective report of requesters with several items just under a limit, for example within 10 percent below it, and review it monthly. Urgent overrides need a reason and go to a second person.
What is separation of duties in an approval workflow?
Separation of duties means no single person can complete a risky transaction from start to finish, because conflicting steps sit with different people. The basic conflicts, such as approver and payment releaser, are listed in the approval workflow design guide. The control view adds the people who change the workflow.
| Conflict | Why it matters | Control |
|---|
| Requester and approver | Self-approval | System blocks the same user |
| Configurer and approver of items routed by their own rules | Changing the rules to suit a request | Configurers cannot approve items routed by a matrix they can edit |
| Developer and production deployer of a workflow | Releasing untested or unreviewed changes | Separate roles and environments |
| Author and release approver | Approving your own change | A named reviewer other than the author signs off the release |
They enforce it by controlling who may build, test, approve and release a workflow, and by separating the identity that builds from the identity that runs. Ask for these controls directly and test them on a demonstration tenant; do not assume a capability from a feature list.
| Area | Control to look for | Question to ask |
|---|
| Environments | Separate development, test and production | Can a builder edit a production workflow directly? |
| Roles | Fine-grained permissions: build, review, deploy, administer | Can build and deploy be separate roles? |
| Version control | Every change stored with author, date and difference | Can we compare and roll back versions? |
| Service accounts | Named owners, least privilege, credentials in a secrets store | Who owns each automation identity, and does the log show the human who triggered it? |
| Change log | Configuration changes are logged and protected | Can administrators alter the change log? |
NIST SP 800-53 covers restricting who can change system configuration (CM-5) and protecting audit information (AU-9), and ISO/IEC 27001:2022 Annex A (5.3) covers segregation of duties. Use them as reference points, check the current text, and ask your auditor how they apply.
They differ in granularity, delegation rules, evidence and how far they can be tuned to your policy. Compare any platform with the criteria below, using your own scenarios, and judge the result by testing, not by a ranking. Capabilities change, so check current documentation.
| Criterion | What to test |
|---|
| Per-action approval | Can approval attach to one action (release payment, change bank details) as well as a whole document? |
| Approver logic | Thresholds, roles, entities and cumulative totals |
| Delegation | Can a delegate exceed the delegator's limit? Do expired delegations fail? |
| Audit log | Append-only, exportable, with before and after values and the rule version |
| Admin protection | Can administrators delete or edit log entries? |
| Reporting and fit | Overrides and role conflicts reported; how much of your policy is configuration rather than custom code |
If your policy does not fit configuration, a custom approval layer around your ERP is an option; see workflow automation.
What patterns give IT ticket routing a reliable audit trail and approval history?
Record every state change in an append-only event log, version the routing rules, and link each approval to the ticket event it authorised. The aim is to answer who assigned, approved or changed what, when and under which rule, even after the rules, the team or the tool have changed.
Patterns that work:
- Event log per ticket. Created, routed, reassigned, priority changed, approval requested, approved or rejected, status changed, reopened. Each event has actor, time, and before and after values.
- Routing rule versioning. Store the rule version that routed each ticket, so a reassignment can be explained after the rules change. Manual reassignment and priority changes need a reason code.
- Approvals as first-class events. For changes and access requests, record the approver, any delegate, the decision and the exact scope approved, such as access level and end date, so a later edit cannot widen it.
- One clock and one export. A single synchronised time source for all events, and a feed to your central log store so events survive tool changes.
- Comment history. Preserve edits to comments and approvals; do not overwrite.
How do you protect the audit trail itself?
Make the log append-only through the application, restrict direct database access, send copies to a separate store, synchronise time and set retention to match policy. Then test it: try to edit or delete an entry as an administrator, and confirm the attempt is refused and itself recorded.
Where tamper evidence matters, add hash chaining, so each entry carries a fingerprint of the one before, or use write-once storage. Record who reads the log as well as who writes to it, and keep a copy in a separate store under different administrators. Confirm retention periods with your auditor or counsel; they vary by country and record type.
How do you test approval controls before an audit?
The basic test cases (self-approval, amounts either side of each limit, delegation inside and outside its dates, edits after approval) are in the approval workflow design guide. Audit preparation adds three tests: re-perform a sample the way an auditor would, check that evidence is retained and retrievable, and try to tamper with the log.
- Re-perform a sample. Pick items across bands, entities and months and trace each from request to payment using only the system's records. An item you cannot trace is a finding.
- Check evidence retention. Retrieve last quarter's delegation register, matrix versions and override reports without asking an administrator to rebuild them.
- Attempt tampering. As an administrator, try to alter a log entry and to edit the matrix without the second approver.
These tests support audit readiness; whether controls satisfy a regime such as SOX is for your auditors and compliance team to confirm, and no software claims it alone. Keep the scripts and results as evidence.
Worked example (illustrative)
A distributor sets an accounts payable matrix: up to 5,000 the budget holder; 5,001 to 25,000 the finance manager, with the CFO as fallback when absent; above 25,000 the CFO. The finance manager goes on leave and delegates to a senior accountant whose own authority is 5,000. The system caps the delegate at 5,000, so a 12,000 invoice cannot be approved by the accountant and routes to the next level named in the matrix for an absent approver, here the CFO.
In another week a requester submits three invoices of 4,900 to the same vendor. Each is under 5,000, but the aggregation rule totals 14,700 and routes all three as one commitment to the finance manager band. In the audit export, each approval shows the approver, any delegate, the rule version and the time. All figures are invented.
When this is the wrong approach
A formal control matrix is more than a small team with a handful of approvals needs; a checklist and a monthly review may do. Controls cannot fix a broken process; if approvals happen by email or chat, fix adoption first. An audit trail is no substitute for judgement: consequential decisions should stay with people, as the human-in-the-loop design guide explains for AI agents.
Glossary: delegation of authority, who may commit the company, up to what limit; separation (segregation) of duties, conflicting steps held by different people; preventive control, one that stops the event; detective control, one that finds it afterwards; append-only log, entries can be added but not changed; hash chaining, each log entry carries a fingerprint of the previous one.
How Timeline Digital approaches approval controls
Founded in 2013 and based in Islamabad, Timeline Digital builds custom approval workflows remotely, with configurable matrices, delegation rules and audit logs designed to support your controls, confirmed per project with your own auditors. A free pilot of 2 to 3 key modules is tested by your team before the final agreement; the schedule is set from your requirements in the Plan step, and source code transfers on full payment. Discuss Your Project.