Segregation of duties (SoD) means no single person can start, approve, record and hide a transaction on their own. You design it by splitting four functions across different people, listing the combinations that must not sit together in a conflict matrix, and testing both people and system access against that list. Where a small team cannot split everything, you add a compensating control, such as an independent review.
Last reviewed: 17 October 2026. Facts checked. We searched for how SoD is described and found consistent use of four functions (authorisation, custody, recording, reconciliation), process-wise conflict matrices, role-based access rules in ERP systems, and compensating controls for small teams. Sources were mostly vendor and public-sector guidance. We did not open COSO or NIST SP 800-53 directly, so we do not cite their wording. The matrix below is an example for you to adapt.
The four functions to keep apart
| Function | What it means | Example |
|---|---|---|
| Authorisation | Approving a transaction | Approving a purchase order |
| Custody | Holding the asset | Handling cash or stock |
| Recording | Writing it in the books | Posting the invoice |
| Reconciliation | Checking records against reality | Bank reconciliation |
The idea is simple. Someone who can both handle an asset and record it can take it and cover the entry. Someone who both approves and records can create a payment to a person who does not exist.
A conflict matrix for common processes
A conflict matrix lists duties down one side and across the other. A mark in a cell means the two duties should not be held by the same person. Here is a starter for the purchase-to-pay cycle.
| Duty | Create vendor | Raise PO | Approve PO | Receive goods | Post invoice | Release payment | Reconcile bank |
|---|---|---|---|---|---|---|---|
| Create vendor | X | X | X | X | |||
| Raise PO | X | X | X | ||||
| Approve PO | X | X | X | X | |||
| Receive goods | X | X | |||||
| Post invoice | X | X | X | X | |||
| Release payment | X | X | X | X | |||
| Reconcile bank | X |
Read it by row. The person who releases payments should not create vendors, approve POs, post invoices or reconcile the bank. Make a similar matrix for each process, using the cycles you audit. For revenue, include creating customers, raising invoices, issuing credit notes, collecting cash and writing off debts. For payroll, separate employee master changes, attendance input, salary processing, bank release and review of the payroll register.
Treat the matrix as a draft. Some marks may not suit your business, and you should add duties that are specific to your systems.
Step by step: design it
- List the process steps. Walk the process from start to end with the people who do it.
- Tag each step as authorisation, custody, recording or reconciliation.
- Build the matrix for the conflicts that matter most, those that allow loss or misstatement.
- Map duties to roles, not people. Roles survive when staff change.
- Translate roles into system access. In an ERP, this becomes a rule set of incompatible permissions, enforced through role design.
- Record exceptions. Where a conflict is accepted, document who accepted it and why.
When you cannot split the duties
A five-person finance team cannot separate everything. Use compensating controls, which are controls that reduce the risk another way. Sources commonly name supervisory review, exception reports and independent reconciliations. Examples:
- The owner or director reviews the bank reconciliation each month and initials it.
- A report of all vendor master changes goes to someone outside accounts payable.
- Payments above a set limit need a second approver in the banking portal.
- Job rotation or mandatory leave, so someone else sees the work.
A compensating control must be performed, evidenced and independent. A review nobody signs is not a control.
How to test it
Test three things.
Design. Does the matrix cover the right conflicts, and do the role definitions follow it? Ask for the role list and the permissions behind each role.
People. Pull the user list for each key system with the roles each user holds. Compare it with the conflict matrix. Flag any user who holds two roles that conflict.
Activity. Even if access is clean, check what happened. Look for transactions where the same user created and approved, or where the creator and releaser of a payment are the same. This is a data test, and it can run over the full population, not a sample.
For any conflict you find, ask three questions. Is there a business reason? Is there a compensating control? Was there actual misuse? Report the exposure even if you find no misuse, because the opportunity is the finding.
Common findings
- Super-user or admin accounts with business rights.
- A user moved departments and kept old access.
- Shared logins, which make activity impossible to trace.
- Approval limits that exist on paper but not in the system.
- Temporary access for a project that never ended.
Where it fits in your audit
SoD sits inside access controls, which are part of the IT general controls described in our ITGC guide and the SOX IT controls testing article. For each process, the SoD design belongs in your control matrix: see key controls examples with RCM rows and our purchase-to-pay RCM checklist. Rank where to test first using a risk assessment matrix.
You can structure the control rows in the internal audit RCM builder, and track access-related testing in the ITGC audit workbook.
Frequently Asked Questions
What is segregation of duties in simple words?
It means splitting a task among different people so that one person cannot commit and hide an error or fraud alone. The usual split is between approving, holding assets, recording and checking.
What is a segregation of duties matrix?
It is a grid of duties that shows which pairs should not be done by the same person. You build one per process and use it to review user roles and system access.
Can a small company achieve segregation of duties?
Not fully. Small teams rely on compensating controls such as owner review of reconciliations, exception reports and dual approval for large payments.
How is SoD different from access control?
Access control decides who can use a system. SoD decides which combinations of access are unsafe. You can give each user valid access and still create a conflict.
How often should SoD be reviewed?
Review whenever roles change, a system is upgraded or staff move, and as part of regular access reviews. Choose a set frequency and document it.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error