Segregation of Duties (2026): The Four Functions, a Matrix Template and How to Test for Conflicts

TL;DR

Segregation of duties (SoD) divides critical work so that no one person can both commit and conceal an error or fraud. The four functions to keep apart are authorization, custody of assets, recording and reconciliation. A segregation of duties matrix shows which roles combine those functions, and an access review shows who holds which permissions. Neither shows the finance manager who approves requests for three teams because colleagues forward them in chat. This guide is published by Sentra, which understands how a company really runs, and acts on it before anyone asks. Sentra compares system records with how work actually moves through chat, email and calendars, and raises conflicts to a named owner.

What segregation of duties means and why auditors test it

Segregation of duties, also called separation of duties, assigns incompatible steps in a business process to different people. In accounts payable, the person who approves a payment should not also reconcile the bank account that records it. The principle is that independent review catches improper transactions that one person acting alone could hide. The COSO Internal Control Integrated Framework treats segregation of duties as a control activity, and the ACFE's occupational fraud research consistently lists weak internal controls among the conditions that let fraud go undetected.

Under Section 404 of the Sarbanes-Oxley Act, management at covered public companies assesses internal control over financial reporting. An SoD conflict is not automatically a material weakness. Under PCAOB AS 2201, a material weakness is a deficiency, or combination of deficiencies, that creates a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis. An effective independent review can reduce that possibility, so testing has to establish whether the review actually happened, not only whether the job titles differ.

The four incompatible functions

Four functions let you classify what a person does in a transaction regardless of job title.

• Authorization is approving an action, such as signing off a vendor invoice before payment.
• Custody is controlling an asset, such as holding inventory or releasing funds from a bank account. An approval does not give someone custody unless they can also move the asset.
• Recording is entering the transaction in the company's books, such as posting the invoice to accounts payable.
• Reconciliation is comparing records with independent evidence, such as matching the bank statement to recorded payments and investigating differences.

Building a segregation of duties matrix

A segregation of duties matrix puts roles in rows and the four functions in columns, then flags any combination that gives one person control over incompatible steps in the same transaction. Track vendor creation separately when you test payments. It is a sensitive master-data permission, not the same task as recording an invoice. Copy the starter matrix below and extend it for your own processes.

The AP lead's authorization and recording permissions need review, but the matrix alone does not show whether the lead can also create a vendor or release funds. Check those permissions before concluding that the lead could create a false vendor and pay it. An independent review of capped, low-value payments can lower a conflict's priority if the reviewer checks the underlying evidence promptly. Record the transaction scope and the review control beside each flagged row.

Next, map people to roles. One person may hold two roles that look safe in separate rows, so combine their permissions before deciding whether a conflict exists. Check role definitions as well as assignments, because a single standard role can contain a conflict. Remember that the matrix reflects assigned access, not current practice. Temporary access, delegated approvals and requests routed through chat to someone outside their stated role do not appear in it.

Worked example: a conflict in procure-to-pay

A buyer who approves an order and records its receipt can make an invoice look ready for payment without independent evidence that the goods arrived. Consider a purchase order for 40 laptops. Under the planned process, the buyer approves the order, a warehouse employee accepts delivery and a separate employee records the receipt from the delivery note.

The conflict develops when the warehouse employee is absent. A manager asks the buyer in chat to cover the delivery and grants temporary access to enter receipts. The buyer approves the order, signs for the laptops and records all 40 as received. Accounts payable then matches the invoice against the order and the receipt, even though the buyer supplied both. A matrix built from assigned roles shows no conflict. To find it, compare the order approver, the delivery signature and the ERP receipt entry for the same purchase, then check the chat request and the temporary access grant.

Common SoD conflicts in payroll and procurement

Payroll has a conflict when one person can add an employee and release that employee's pay, because they could create a fictitious employee and direct wages to an account they control. HR should manage employee records, someone outside HR should approve time worked, and a separate authorized employee should release payments. Whoever reviews the payroll register should check new names against HR records.

Procurement has a similar conflict when one person controls both supplier selection and vendor setup. With both permissions, a person could favor a supplier and enter its payment details without an independent check. Separate selection from vendor creation, and have an independent reviewer confirm vendor ownership and bank details. Purchases that bypass the approved route entirely are a related problem known as maverick spending.

Plante Moran describes a government director who selected a vendor owned by the director's spouse and sent checks to a personal account. It also describes a retiring staff member who flagged her own unrestricted ERP access, warning that she could have stolen for years without detection.

Why access reviews miss the conflicts that matter

An access review shows which permissions people hold, not how they use them. Suppose colleagues in three teams forward approval requests to one finance manager in chat, and the manager approves them in the ERP. The role report shows the manager's access and the transaction log shows the approvals. Neither shows whether the manager also requested, recorded or reconciled any of those transactions. The chat messages and reporting lines identify the handoff, and the transaction trail shows whether it created a conflict.

Permissions also outlast the duties they were granted for. People keep access after department moves or acquisitions, and emergency access stays open after a colleague returns. Access that survives a departure is its own risk, which our employee offboarding checklist covers. In every case, the audit question is what one person can approve in practice, not which role sits beside their name.

Compensating controls for small teams

• Map who does what. List who prepares, approves and reconciles each transaction type with the staff you actually have.
• Assign an independent reviewer. When one employee must hold conflicting duties, a manager outside the process reviews their work and the supporting evidence.
• Rotate duties where practical. Rotation makes long-running concealment harder.
• Trim access to current duties. Remove permissions people no longer need and inspect role definitions for built-in conflicts.
• Review by risk, not by volume. Focus checks on new vendor payments, bank detail changes and other higher-risk activity, and keep a record of what was checked and which exceptions were approved.

How to test for segregation of duties conflicts

Start with a matrix for one process, such as vendor setup through payment. List who can create or change a vendor, submit, approve, release funds, record and reconcile. Flag the combinations that let one person initiate an improper payment and hide it.

Pull current user roles and permissions from the ERP and related systems, including temporary access and permissions retained after a job change, and match them against the matrix. Then sample completed transactions and trace who submitted, approved, released, recorded and reconciled each one. Compare those records with the email or chat requests behind them and ask the process owner about exceptions. Record the evidence, the compensating control and the owner assigned to resolve each conflict, and monitor new grants between formal reviews so a new conflict does not wait a year for the next test.

How Sentra surfaces conflicts that live outside the system of record

Sentra understands how a company really runs, and acts on it before anyone asks. It reads email, chat, meetings and documents alongside ERP, CRM, HRIS and BI data, and works out what is true now and why. When chat shows three teams forwarding requests to one person, Sentra joins those messages with ERP approval records and HRIS reporting lines, checks whether that person also performed an incompatible step on the same transactions, and raises the finding to the control owner who can act.

A named person approves each finding before it reaches anyone else. Every claim cites its source, and permissions follow the source, which matters when a control review draws on employee conversations. Sentra replaces none of the company's systems. The ERP and the GRC tool remain the record. Sentra holds SOC 2 Type II and ISO 27001 certifications. The same permission model governs AI agents, as described in our guide to AI agent permissions.

FAQ