Segregation of duties software: separation of duties in accounting, the SoD matrix and user access reviews
Segregation of duties splits a financial process so that no single person can start it, approve it, hold the asset and record the result. The test the standards actually use is simpler than the checklists suggest: keep authority, custody and accounting in different hands. Everything else, the matrices, the conflict rules, the quarterly access reviews, exists to prove that separation held for a whole reporting period rather than on the day someone ran a report.
Two things make it hard. Job titles do not tell you what a person can do, because the permission that creates the conflict lives in the ERP rather than the org chart. And most finance teams are too small to separate everything, which is allowed but has to be documented deliberately. This page covers what the standards genuinely require, how to build a workable SoD matrix, how the testing is done, and what to do when the conflict cannot be removed.
Every standard reference on this page was checked against the published text of the GAO Green Book, PCAOB AS 2201 and AS 2110, and NIST SP 800-53 Rev 5 in August 2026. Where a widely repeated claim is not in the source, this page says so.
Scan your control and access obligations
Pick your industry and size, then choose the frameworks you report against. The scan returns the obligations that apply to an organization like yours, what moved in the last 12 months, and the primary source behind each line. No signup, nothing stored.
§ Live · Compliance scan
No signup. Nothing you pick is stored.
Sample register · fintech, US · what a scan returns
- § 01 Written AML program with a named officer
- § 02 KYC and customer due diligence
- § 03 Sanctions screening lists Changed
- § 04 PCI DSS v4.0 validation
What the standards actually say, and what they do not
You will read constantly that Section 404 of Sarbanes-Oxley requires segregation of duties. It does not, at least not in those words. The phrase does not appear anywhere in PCAOB AS 2201, the standard that governs the Section 404 audit, and the statute never mentions it either. This is worth getting right, because a control framework built on a misquoted requirement tends to be built to the wrong shape.
What actually drives the requirement is risk. If one person can run a payment process from request to reconciliation, there is no control over that process, and your own Section 404 assessment has to say so. The obligation arrives through the risk assessment, not through a named rule. Here is where each standard genuinely lands.
| Source | Does it name segregation of duties? | What it actually says |
|---|---|---|
| SOX Section 404 | No | Requires management to assess the effectiveness of internal control over financial reporting. Names no individual control of any kind. |
| PCAOB AS 2201 | No, not once | The phrase is absent from the standard. The closest reference is the note after paragraph .42: a smaller, less complex company "might have fewer employees in the accounting function, limiting opportunities to segregate duties and leading the company to implement alternative controls." |
| PCAOB AS 2110 Appendix B .B4 | Yes, as an IT risk | Lists among the risks arising from IT that personnel may gain "access privileges beyond those necessary to perform their assigned duties, thereby breaking down segregation of duties." |
| GAO Green Book 10.12 to 10.14 | Yes, directly | Paragraph 10.12: management designs responsibilities "so that incompatible duties are segregated and, where such segregation is not practical, designs alternative control activities to address the risk." |
| COSO Internal Control 2013, Principle 10 | Yes, as a point of focus | Management considers segregation of duties when assigning control activity responsibilities and selects alternative control activities where segregation is not practical. |
| NIST SP 800-53 Rev 5, AC-5 | Yes, as "separation" | Two requirements only: identify and document the duties requiring separation, and define system access authorizations to support that separation. Least privilege is a separate control, AC-6. |
Notice the pattern across the two families. Both concede the same limit in the same breath. Green Book paragraph 10.13 says segregation addresses the risk of management override but "cannot absolutely prevent it because of the risk of collusion, where two or more employees act together to commit fraud." NIST AC-5 says separation reduces "the risk of malevolent activity without collusion." Neither standard claims this control stops two people who agree to cooperate, and no software claims it credibly either.
Authority, custody and accounting: the test behind every conflict rule
Vendor material almost always lists four duties: authorization, custody, recordkeeping and reconciliation. It is a workable list. It is also not what the federal internal control standard says. Green Book paragraph 10.13 names three, telling management to "separate control activities related to authority, custody, and accounting of operations." The four-way version pulls reconciliation out of accounting and treats it as its own role, which is a sensible refinement rather than a rule handed down from anywhere.
The reason the three-way test is worth keeping in your head is that it settles arguments a conflict list cannot. When somebody asks whether two duties really conflict, ask which of authority, custody and accounting each one touches. If a single person covers two of the three inside the same process, you have a conflict regardless of what your matrix inherited from a template.
| Process | Conflicting combination | What it lets one person do |
|---|---|---|
| Accounts payable | Create or edit a vendor master record and approve or release a payment | Invent a supplier, direct funds to an account they control, and approve the run that pays it. The single most tested conflict in any SoD program. |
| Accounts payable | Enter an invoice and perform the bank reconciliation | Record a fictitious liability and then suppress the variance that would have surfaced it. |
| Payroll | Add or change an employee record and run or release payroll | Create a ghost employee and pay them. This is why HR master data and payroll processing are almost always split. |
| Accounts receivable | Apply cash receipts and post credit memos or write-offs | Divert a customer payment and clear the resulting open balance with an adjustment. Classic lapping exposure. |
| Financial close | Post a manual journal entry and approve it | Move a balance without any second pair of eyes, in the exact area where management override lands. |
| Procurement | Raise a purchase order and confirm goods receipt | Complete a three-way match alone, which is the control the match exists to prevent. |
| IT and finance | Hold developer access and migrate changes to production | Change how the system calculates and move that change live unreviewed. Sits in ITGC program change rather than in a finance process, and is missed by matrices built only from finance roles. |
| Security administration | Administer access rights and administer the audit logs | Grant themselves access and remove the record of it. Called out by name in the NIST AC-5 guidance. |
How to create a segregation of duties matrix that survives testing
A segregation of duties matrix is a grid with the same duties down the rows and across the columns, where each cell records whether one person may hold both. The concept is trivial. The reason so many matrices fail their first audit is that they were built from job titles, and a job title does not tell you what somebody can do. The conflict lives in the permission, so the matrix has to reach into the system.
- 1. Start from processes already in scope. Take the significant accounts and processes your Section 404 control matrix already covers. Building an SoD matrix for the whole company when only six processes are in scope creates work no one will maintain and no auditor asked for.
- 2. List the duties, not the roles. Inside each process, write the discrete actions: create vendor, approve invoice, release payment, post journal, reconcile bank. Duties are verbs. Roles are containers that change every reorganization.
- 3. Mark the conflicts with the three-way test. For each pair, ask whether one person would hold two of authority, custody and accounting in the same process. Record the reasoning in the cell. A matrix that says "conflict" with no rationale cannot be defended when someone challenges it eighteen months later.
- 4. Map every duty to a system permission. This is the step that gets skipped and the step that makes the matrix real. Each duty needs the transaction code, role, profile or permission set that grants it, per system. Until this exists you cannot test anything automatically.
- 5. Run your full user population against it. Not a sample. The complete listing of users and their assigned roles, including service accounts, contractors and anyone with emergency or firefighter access. Expect the first run to return far more conflicts than anyone predicted, mostly from accumulated access.
- 6. Resolve, mitigate or accept each hit, in writing. Remove the access, or design a compensating control and document it, or accept the risk at a level senior enough to mean something. An unresolved conflict sitting in a spreadsheet with no decision attached is the finding.
One warning about the fourth step. In a large ERP the same underlying capability is often granted by several different objects, so a conflict can hide behind a permission nobody associated with finance. This is the honest reason SoD analysis in SAP, Oracle and Dynamics is a specialist job rather than a spreadsheet exercise, and why conflict rule sets are sold as products of their own.
User access reviews are how separation gets proven over a period
A matrix tells you what should not be combined. A user access review is the recurring control that shows nobody drifted into a combination during the year. It matters because Section 404 is an assertion about a whole period, not a point in time, and access is the control that decays fastest. People move teams, cover a colleague's leave, get temporary rights for a close, and the temporary rights stay.
No standard sets a frequency. In practice quarterly is the common cadence for in-scope systems and privileged accounts, annual for lower-risk systems. Frequency is the least interesting decision here. Three other things determine whether the review passes.
The population has to be complete
A full extract of users and entitlements as of a date, with evidence of how it was generated. A screenshot of an active-user screen is not a population, and this is where most access-review testing actually fails.
The reviewer has to understand it
A manager who knows what the job requires, not a security administrator confirming their own provisioning. Blanket approval of a hundred lines in one click is visible in the timestamps and gets challenged.
Leavers cannot wait for the cycle
Termination revocation runs on its own trigger from HR. If a departure is only caught by the quarterly review, there is a window of up to three months, and auditors test the gap between leaving date and revocation date directly.
Access reviews sit inside the access to programs and data domain, so the same evidence serves both your SoD program and your IT general controls testing. Teams that run them as two separate exercises pull the same user listing twice and reconcile the results by hand, which is pure waste.
When you cannot segregate: what the standards allow
Most finance teams cannot fully separate every duty, and both standards say so directly rather than pretending otherwise. The Green Book acknowledges in paragraph OV4.05 that a smaller entity "faces greater challenges in segregating duties because of its concentration of responsibilities and authorities." Paragraph 10.14 gives the answer: if segregation is not practical "because of limited personnel or other factors, management designs alternative control activities to address the risk of fraud, waste, or abuse."
AS 2201 says the same thing for the audit side in its note after paragraph .42, describing a smaller company with fewer accounting employees implementing alternative controls to achieve its control objectives. So the position to take with an auditor is not that you have no conflicts. It is that you identified the conflict, could not remove it for a stated reason, and put a specific detective control in its place.
What that looks like in practice: an owner or board member reviewing the complete bank statement and the full payment register independently of the person who prepares them, monthly review of all new and changed vendor master records against supporting documentation, an approval threshold that forces a second signature above a set amount, or a periodic report of every manual journal posted and approved by the same user. Each one is detective rather than preventive, which is the trade you are making.
Two conditions decide whether this holds up. The compensating control has to be performed by someone genuinely outside the process, and it has to leave evidence that it happened, with a date and a name. A review that occurs in someone's head every month is not testable, and an untestable control is treated as absent. If the conflict is severe and the compensating control is weak, that combination is what turns into a significant deficiency or a material weakness.
Where segregation of duties software earns its money, and where it does not
Worth being straight about the split, because this category is oversold. Software is genuinely good at the mechanical half and cannot do the judgment half at all.
What it does well
- Running a full user population against a conflict rule set continuously instead of once a quarter, so a conflict introduced in week two is caught in week two.
- Resolving permissions to duties across systems, which is the part no spreadsheet handles once the same capability is granted by several objects.
- Simulating a proposed role change before it is granted, so provisioning stops creating the conflicts the review later finds.
- Holding the evidence trail: who reviewed, when, what they saw, what they decided, in a form that can be handed to an auditor without reassembly.
- Tying the conflict register to the control matrix and the deficiency log so a hit becomes a tracked item rather than a spreadsheet row.
What it cannot do
- Decide which duty pairs conflict in your business. Out-of-the-box rule sets are a starting point that always needs tuning, and an untuned rule set generates noise nobody triages.
- Judge whether a compensating control is strong enough. That is a severity assessment, and it stays with management.
- Fix an organizational problem. If four people run the whole finance function, no tool changes that arithmetic.
- Stop collusion, which both NIST and the Green Book explicitly exclude from what this control achieves.
One buying note. Conflict detection often ships inside identity governance tooling, while evidence and deficiency tracking usually live in audit management software. Teams routinely buy both and then reconcile between them, so check what your existing GRC platform already covers before adding a third system.
Segregation of duties questions
What is segregation of duties?
Segregation of duties is the practice of splitting a financial process so that no one person controls it end to end. The GAO Green Book states the purpose plainly in paragraph 10.13: separate authority, custody and accounting. If the person who approves a payment also releases the cash and also records it in the ledger, an error or a theft has nothing standing in its way.
What are the 4 segregation of duties?
Most vendor material lists four: authorization, custody, recordkeeping and reconciliation. Useful, but know where it comes from. The federal internal control standard names three, not four. GAO Green Book paragraph 10.13 says management separates control activities related to authority, custody and accounting. The four-way split is practice convention that pulls reconciliation out of accounting as its own role.
What is the difference between segregation of duties and separation of duties?
They are the same concept in two different standards families. Accounting, audit and COSO material says segregation. Security frameworks say separation: the NIST SP 800-53 Rev 5 control is AC-5, titled Separation of Duties. Nothing turns on the word. If a policy uses one term and your auditor uses the other, they are still testing the same thing.
Does SOX require segregation of duties?
Not by name, and this is widely misreported. The phrase segregation of duties does not appear anywhere in PCAOB AS 2201, the standard governing the Section 404 audit, and Section 404 itself never mentions it. What makes it unavoidable is risk: a process one person controls end to end has no control over it, so your own assessment has to flag the gap.
What is a segregation of duties matrix?
A grid with the same list of duties down the rows and across the columns, where each cell says whether one person may hold both. Cells marked as conflicts are the ones you test. A good matrix is built from transactions and system roles, not job titles, because job titles hide what somebody can actually do in the ERP.
How do you create a segregation of duties matrix?
Start from the significant processes in your Section 404 scope, list the duties inside each one, then mark which pairs are incompatible using the authority, custody and accounting test. Map every duty to the actual system role or permission that grants it. Finally run your user population against the grid. The first run always finds more conflicts than anyone expects.
How do you handle segregation of duties in a small company?
You accept the conflict and document a compensating control, which both standards explicitly allow. Green Book paragraph 10.14 says that where segregation is not practical because of limited personnel, management designs alternative control activities. The AS 2201 note after paragraph .42 says the same for smaller companies. What fails an audit is an undocumented conflict, not a disclosed one.
How do you test segregation of duties?
Pull the complete user listing with roles as of a date in the period, run it against the conflict matrix, and investigate every hit. Then test whether the conflict was ever exercised by tracing transactions. A conflict that exists but was never used is still a design deficiency. Population completeness is where most of this testing actually fails.
How often should user access reviews be performed?
No standard prescribes a frequency. In practice quarterly is the common cadence for systems in Section 404 scope and for privileged accounts, with annual reviews for lower-risk systems. What matters more than the interval is that the reviewer is someone who knows what the access is for, and that leaver revocation runs on its own trigger rather than waiting for the next review.
What is the difference between segregation of duties and least privilege?
Least privilege limits how much one person can do. Segregation of duties limits which combinations one person can hold. NIST keeps them as separate controls for that reason: AC-5 covers separation of duties, AC-6 covers least privilege. Someone can hold minimal access in two places and still sit on a conflict, so passing one test does not pass the other.
Last updated August 2026.
§ 99 · Final entry
Get on the early-access list
Leave your work email, confirm the 6-digit code, and we will email you when your spot opens. Nothing is charged before launch.
Related registers
- Continuous Compliance Monitoring
- Compliance Monitoring Software
- Compliance Software Cost
- Enterprise Compliance Software for CCOs and CISOs
- GRC Software and Governance Risk Compliance Software
- GDPR Compliance Software
- Compliance Automation Software
- AML Transaction Monitoring Plus Regulatory Watch
- SOC 2 Compliance Software Beyond Audit Readiness
- Policy Compliance Software and Policy Management Tracking
- Regulatory Change Management Software, Tools and Platform
- HIPAA Compliance Software with Security Risk Analysis
- ISO 27001 Software for ISMS Compliance and Audit Evidence
- Vendor Risk Management Software for Third Party Risk
- PCI Compliance Software Tied to PCI DSS 4.0.1
- Audit Management Software for Continuous Readiness
- SOX Compliance
- ITGC Controls Software for SOX IT General Controls Audits
- SOX Compliance Software for SOX 404 Controls
- Best Compliance Software in 2026, Compared
- CMMC Compliance Software for DoD Contractors
- Enterprise Risk Management Software
- Compliance Software Pricing Comparison
- Healthcare Compliance Software for OIG Compliance Programs
- Bank Compliance Software for Financial Institutions, BSA/AML
- AI Compliance Software
- AML Compliance Software with KYC and Sanctions Screening
- Regulatory Compliance Software with Compliance Tracking
- CCPA Compliance Software, Data Privacy Management Software
- Enterprise Risk Assessment Software, Risk Assessment Tools
- Vanta Alternative for Regulatory Change Monitoring
- Drata Alternative Focused on Regulatory Change
- Secureframe Alternative for Regulatory Change
- Sprinto Alternative for Regulatory Change
- AuditBoard Alternative (Now Optro) for Regulatory Change