Segregation of duties rests on one idea: no single person should be able to both commit an error or fraud and conceal it. In practice that means separating custody of assets, authorization, recording, and reconciliation. This matrix lists the specific duty pairs that conflict, shows who can do what by role, and gives compensating controls for teams too small to separate everything. Pair it with our software category guides to see which tools fit your team. Once you have a shortlist, check the vendor profiles and the finance glossary for unfamiliar terms, then use our head-to-head comparisons before your first demo.
Built for: Controller, CFO, Accounting manager, Internal audit
+1 more inside
List roles and system access as they really are. Use the ERP, bank portal, and payroll system user listings, not the org chart. Access that was granted during a busy close and never removed is where most conflicts hide.
Fill the role-by-function grid. For each role, mark whether it performs (P), approves (A), or reviews (R) each function, or has no access. Then check each row against the conflict pairs.
Resolve or compensate each conflict. Remove access where you can. Where the team is too small, document a compensating control, name who performs it, and keep evidence that it happened.
Recheck quarterly and on role changes. Review access against the matrix at least quarterly and whenever someone joins, leaves, or changes role. Temporary cover arrangements should have an end date.
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Duty A and Duty B should not sit with the same person. If they must, apply the compensating control.
| Process | Duty A | Duty B | Risk if combined | Compensating control (small teams) |
|---|---|---|---|---|
| Procure to pay | Create or edit vendor master | Enter or approve invoices | Fictitious vendor paid | Monthly review of vendor change log by controller |
| Procure to pay | Enter invoices | Release payments | Unauthorized or duplicate payment | Payment run approved by second person in bank portal |
More free templates finance teams use alongside this one.
A risk control matrix is the map auditors use to decide what to test. A good one starts from what could go wrong in the financial statements and works back to the control that stops it, not the other way round. This template pairs each risk with a control, classifies it, names an owner, and ties it to the assertion it protects, with example rows for procure-to-pay, order-to-cash, close, and IT general controls.
Most approval matrices fail in one of two ways: every invoice goes to the CFO, or nobody can say who approves a $40,000 software renewal. This approval matrix separates PO-backed invoices, where approval already happened at the purchase order, from non-PO spend, where the invoice is the only control point. It also names a backup for every approver so invoices do not sit in someone's inbox while they are on leave.
Accounts payable fraud rarely looks like fraud at the time. It looks like a routine email from a known vendor asking to update bank details, or an urgent request from an executive who is travelling. This checklist covers the controls that stop the common schemes: independent verification of bank changes, red flags for business email compromise, duplicate payment checks, bank-side protections, and dual approval on payment release.
It is a table showing which roles perform, approve, or review each financial activity, alongside the pairs of duties that should not be combined. It is used to design roles, review system access, and document compensating controls where conflicts remain.
Common conflicts include creating vendors and approving payments, initiating and approving wires, preparing and approving journal entries, handling cash receipts and posting to AR, and adding employees and processing payroll. Each allows one person to create and conceal an error or fraud.
They use compensating controls: a detective review performed by someone outside the conflict, such as the controller or CFO reviewing the vendor change log, approving bank payment releases, or reviewing all manual journals after close. The review must be documented to count as a control.
Quarterly access reviews are a common practice, plus a review whenever someone joins, leaves, or changes role. System implementations and upgrades are also a trigger, because new roles are often configured with broader access than intended.
