Segregation of duties is taught as an ERP problem, a matrix of transaction codes that a tool checks, and most of the losses it exists to prevent happen nowhere near an ERP. The driver who collects the cash and fills in the settlement sheet. The depot clerk who counts the cash and prepares the reconciliation. The payroll administrator who maintains the employee file and enters the hours. The treasury analyst who sets up the beneficiary and releases the wire. The developer who writes the code and deploys it. The office manager who orders, receives and approves the invoice because there is nobody else. Each is a person controlling two stages of the same transaction in a way that lets an error or a theft be committed and concealed by the same hands, and none appears in a role-based analysis of any system. The principle is universal; the tooling is not, and an auditor who can find conflicts only where a tool exists will miss most of them.
This guide was rewritten in September 2026 and expanded from the original August 2026 version. It sets out the four incompatible functions and the concealment logic behind them, gives a method for finding conflicts in any process whether or not a system is involved, works a conflict matrix for a cash-handling process, provides a universal SoD matrix template, sets out the ladder of alternatives when headcount makes separation impossible and the rules that make a compensating control count, distinguishes testing capability from testing behavior, extends the principle to IT and governance, gives a ten-test program, and finishes with a worked example at MidState Beverage, whose route cash engagement found the reconciliation performed by the person being reconciled at nine of twelve depots. The ERP segregation of duties analysis is the system-specific companion; this guide is the principle that analysis applies.
In this guide
- The four functions, and why any two in one pair of hands is the risk
- Finding conflicts in any process: the method
- The conflict matrix: a worked cash-handling example
- The universal SoD matrix template
- When headcount makes separation impossible: the ladder of alternatives
- What makes a compensating control count
- Testing SoD: capability, behavior, and the difference
- The same principle in IT and in governance
- What segregation does not do: collusion, management override and the limits
- Reporting SoD findings: exposure, cause and the recommendation ladder
- The ten-test program
- Worked example: MidState Beverage’s route cash process
- Common mistakes
The four functions, and why any two in one pair of hands is the risk
Every transaction passes through four functions. Authorization: the decision that the transaction may happen, made by someone with the standing to make it. Custody: physical or logical control of the asset, cash, inventory, a bank token, a master file. Recording: entering the transaction in the books, the system or the sheet. And reconciliation or review: the independent check that what was recorded matches what happened, the count against the record, the bank statement against the ledger, the report against the source. The principle holds that no one person should perform two of these for the same transaction stream, and the reason is concealment rather than commission. Anyone can make an error or take an asset; what segregation prevents is the same person being positioned to hide it. The custodian who also records can take cash and record less. The recorder who also reconciles can post an entry and explain it away. The authorizer who also has custody can approve a payment to themselves and hold the cheque. The fraud risk management guide covers the triangle of pressure, opportunity and rationalization; segregation of duties is the control over opportunity, and specifically over the opportunity to conceal.
| Function | What it means | Examples across processes | Concealment enabled when combined with |
|---|---|---|---|
| Authorization | Deciding the transaction may occur | Approving a purchase, a credit limit, a pay rate, an override, a journal, a payment | Custody (approve and take) or recording (approve and hide) |
| Custody | Control of the asset | Handling cash, holding stock, controlling bank tokens, maintaining master files that direct assets | Recording (take and misrecord) or reconciliation (take and clear the difference) |
| Recording | Entering the transaction | Settlement sheets, invoices, journals, timesheets, receipts, system entries | Custody or reconciliation (misrecord and confirm) |
| Reconciliation and review | Independent verification | Cash counts, bank reconciliations, report reviews, physical counts, exception review | Any of the other three; the reviewer of their own work reviews nothing |
Finding conflicts in any process: the method
The method works for a process run in a system, on paper, or by phone, because it starts from the process rather than from the tool. First, map the process as a sequence of steps, using the walkthrough the process walkthrough guide describes, and keep going until the transaction is reconciled to something independent; a map that stops at “invoice posted” has stopped before the reconciliation function appears. Second, classify each step by the function it performs; steps that combine functions are split. Third, identify who performs each step, as a role or a position rather than a name, including the people who perform it in the ordinary person’s absence, at small sites, and through system access rather than by procedure. Fourth, list every pair of steps in the same transaction stream performed by the same role, and for each pair ask the concealment question: could this person commit an error or a diversion at one step and prevent its detection at the other. Fifth, rate the pairs that survive by exposure, the value that flows through the stream, the ease of diversion, and the existence of any downstream control that would catch it. The output is the conflict matrix, and the step most often skipped is the third, because “who performs it” is asked of the procedure rather than of the roster and the access list. The table gives the classification questions.
| Question about a step | Function it indicates | Watch for |
|---|---|---|
| Does this step decide whether the transaction proceeds? | Authorization | Approvals that are formalities; approvers who also initiate |
| Does this step give the performer control of cash, goods, tokens or the master data that directs them? | Custody | Master data maintenance is custody of where money goes |
| Does this step create or change the record of the transaction? | Recording | Paper records, spreadsheets and system entries all count |
| Does this step compare the record to an independent source? | Reconciliation and review | Independence is of the person, not the document; a self-prepared reconciliation is recording |
| Who performs it when the usual person is away, at the smallest site, or through system access? | Any | The conflicts live in the exceptions and the access lists |
The conflict matrix: a worked cash-handling example
Route cash at a distributor is the clearest illustration because almost none of it happens in a system. A driver delivers, collects cash and cheques from customers, records the collections on a settlement sheet or handheld, returns to the depot, hands the cash to a clerk who counts it and prepares the deposit, and the depot reconciles the count to the settlement, with overrides for shortages approved by someone. The matrix below maps the steps to functions and to the roles that perform them at a typical depot, and the conflicts fall out of it. The driver holds custody and recording on the same collections, which is inherent to the job and is addressed downstream by the independent count and reconciliation; the design question is whether that count and reconciliation are actually independent. At a depot where the clerk who counts also prepares the reconciliation, or where the depot manager both approves overrides and performs the reconciliation, the downstream control has collapsed into the same hands as the exposure it exists to catch. The preventive, detective and corrective controls guide explains why the detective control’s independence is the whole point.
| Step | Function | Role at a typical depot | Conflict when combined with | Exposure |
|---|---|---|---|---|
| Collect cash and cheques from customers | Custody | Driver | Recording (inherent; addressed by independent count) | Daily collections per route |
| Record collections on the settlement | Recording | Driver | Custody (inherent) | Same |
| Count cash received and prepare deposit | Custody and reconciliation (count against settlement) | Depot clerk | Recording of the reconciliation; deposit preparation by the same person | Depot daily takings |
| Reconcile cash counted to settlements and post shortages | Reconciliation and recording | Depot clerk or depot manager | Custody (if the clerk counted) or authorization (if the manager approves overrides) | All shortages and overages |
| Approve overrides for shortages | Authorization | Depot manager | Reconciliation (approving the write-off of a difference one has reconciled); recording where the manager also enters the override | Written-off shortages |
| Deposit cash at the bank | Custody | Depot clerk or manager | Reconciliation of the deposit to the bank statement | Deposits in transit |
| Reconcile deposits to bank statements | Reconciliation | Head office route accounting | Should be independent of all depot roles | Whole stream |
The universal SoD matrix template
The template below is the row structure for a conflict matrix that works for any process, in a spreadsheet or in the RCM Workbench. One row per conflict pair; the process map it derives from is attached. The risk and control matrix template is where the resulting controls and compensating controls are recorded, and the templates directory lists the companions.
Segregation of duties conflict matrix. Process: ________ Process owner: ________ Matrix version: ________ Prepared by: ________ Date: ________ Approved by: ________
A. Process map reference. Steps numbered; function classification per step (authorization / custody / recording / reconciliation); performer by role including deputies, small-site variants and system-access performers.
B. Conflict pairs (one row each). Pair reference; step A and its function; step B and its function; role holding both; how the conflict arises (procedure, absence cover, small site, system access, shared credential); concealment scenario in one sentence; transaction stream and annual value; detectability by existing downstream controls.
C. Rating. Exposure (value at risk and ease of diversion); likelihood (frequency, incentives, history); rating High / Medium / Low with rationale.
D. Treatment. Chosen rung of the ladder: separate (how); system-enforce (which control); compensate (which detective control, performed by whom, how often, evidence); accept (owner, rationale, expiry). Reference to the control in the risk and control matrix.
E. Testing. Capability test performed (source, date, result); behavior test performed (data, period, result); exceptions and disposition; next test date.
When headcount makes separation impossible: the ladder of alternatives
At a three-person depot, a two-person finance team or a one-person subsidiary, the four functions cannot be spread across four people, and the honest answer to “who else could do it” is nobody. Segregation is not therefore abandoned; it is replaced by the next best thing, in a fixed order of preference, and the audit’s role is to make sure the organization chose deliberately and documented the choice. The ladder has four rungs. First, redesign the process so that separation is possible with the people available: move a function to head office or a shared service, split the stream so that no one person handles both sides of the same transactions, rotate duties so that concealment requires collusion across time, or use a second person from an adjacent function for the one step that matters most (the count, the release, the approval). Second, enforce separation in the system where the process runs through one: workflow that routes approval away from the requester, dual control on releases, and the role design the ERP analysis produces; a system-enforced separation does not need a fourth employee. Third, compensate with an independent detective control performed by someone outside the process: an owner’s review of a report that would reveal the diversion, a surprise count, an independent reconciliation at head office, an analytic run centrally over every site’s data. Fourth, accept the residual risk explicitly, with a named owner, a stated exposure, an expiry and a re-review, which is the rung small entities reach for first and should reach for last. The table gives the common small-entity conflicts with the rung that usually works.
| Conflict | Typical small-entity situation | Redesign or system option | Compensating control if neither is possible |
|---|---|---|---|
| Count cash and reconcile it | One clerk per depot | Reconciliation performed at head office from the clerk’s count and the driver’s settlement | Regional manager’s weekly review of shortages by route and clerk; surprise counts |
| Maintain vendor master and pay vendors | One accounts payable person | Vendor bank changes require the owner’s approval in the system; payment release by the owner | Monthly review of vendor master changes against payments by someone who does neither |
| Enter and approve invoices | Office manager does everything | Owner approves invoices above a threshold in the workflow | Owner reviews the full payment run with supporting invoices before release |
| Maintain employee master and run payroll | One HR and payroll administrator | Payroll provider requires owner approval of input; rate changes approved by the owner | Owner reviews the payroll register against headcount and prior period each cycle |
| Post and approve journals | One accountant | System workflow routes journals above a threshold to the owner or an external accountant | Monthly review of all manual journals by the external accountant |
| Set up beneficiaries and release payments | One treasury person | Bank dual control: the owner holds the release token | Daily bank statement review by the owner; never sufficient alone for payments |
| Receive goods and approve invoices | Warehouse lead does both | Three-way match in the system with tolerances; receipts entered by a different person | Periodic physical count reconciled to receipts by finance |
What makes a compensating control count
“We have a compensating control” is the sentence auditors hear most in response to a segregation finding, and most of the controls offered do not compensate for anything. Four conditions have to hold. Independence: the person performing the control is outside the conflicted role and could not have participated in the concealment; a manager reviewing the report prepared by the person they are meant to be checking, from data that person controls, is not independent. Timeliness: the control operates soon enough to limit the loss and to make investigation possible; an annual review of a daily cash process compensates for nothing. Precision: the control would actually detect the diversion the conflict enables, at a level of detail that matters; a review of monthly totals will not reveal a two-hundred-dollar shortage written off every week. And evidence: the control leaves a record of what was reviewed, what was questioned and what was done, so that its operation can be tested like any other control. The automated control guide covers the system-enforced alternatives; for manual compensating controls the test is the ordinary one of design and operation, with the additional question of whether the reviewer had the data, the time and the independence to catch what the conflict allows.
Testing SoD: capability, behavior, and the difference
A segregation conflict is tested twice, and the two tests answer different questions. The capability test asks who could perform both functions: it reads the roster, the procedure, the deputy arrangements, the physical access (who has keys to the cash office, who holds the bank token) and, where a system is involved, the effective access extracted as the ERP analysis describes. Its output is the list of people who hold both functions, whether or not they have ever used both. The behavior test asks who did perform both: it reads the transactions, the created-by and approved-by fields, the count sheets and their signatures, the override approvals, the deposit slips, and identifies the instances where the same person performed both functions on the same transaction stream in the period. Its output is a population of exercised conflicts with values, and it is the population that drives the rating and any substantive follow-up: the invoices entered and approved by the same person, the shortages written off by the person who counted the cash. Capability without behavior is a design finding to fix; behavior is an operating finding to investigate, and the cross-stage analytics built for procure-to-pay are the same-person tests applied to system data. For processes outside systems the behavior test is manual and sampled: count sheets against reconciliations against override approvals for a sample of depot-days, which is exactly the test that produced the worked example’s finding.
The same principle in IT and in governance
The four functions apply to technology and to the top of the organization as cleanly as to cash. In IT, the developer who writes code and deploys it to production combines recording and custody of the logic that processes every transaction, and the administrator who manages user access and also executes business transactions combines authorization with everything else; the change management guide and the privileged access guide treat these as the segregation conflicts they are, with pipelines and vaults as the system-enforced rung of the ladder. In governance, the executive who sets the budget, approves their own expenses and reviews the results, or the finance director who authorizes journals, holds the bank token and reviews the reconciliation, is a segregation failure at a level where compensating controls are the audit committee’s oversight and the external audit; the Three Lines guide covers how those oversight functions are meant to provide the independent review the principle requires. The auditor applying the framework at these levels asks the same question in the same words: can this person commit and conceal, and who would catch it.
What segregation does not do: collusion, management override and the limits of the principle
Segregation of duties prevents one person from committing and concealing. It does not prevent two people who agree to do so together, and it does not prevent the person who can instruct both of them. Collusion is the standard limit, and the response is not more segregation but detection independent of the colluding pair: analytics run centrally over the data both of them touch, rotation of duties so that a partnership has to survive a change of partner, mandatory leave so that the absent conspirator’s work is done by someone else, and the surprise count that neither knew was coming. Management override is the other limit, and it is why segregation at the top of the organization is delivered by oversight rather than by process: the executive who can instruct the clerk and the reviewer is constrained only by the audit committee, the external auditor and the whistleblowing channel. The audit reports both limits explicitly when it reports a segregation control as effective, because “effective” means effective against a single actor, and the reader should know which residual risks the control was never designed to address. The fraud risk management guide covers the detective layer that addresses collusion, and the Three Lines guide the oversight that addresses override.
Reporting SoD findings: exposure, cause and the recommendation ladder
A segregation finding is reported with three things a reader can act on. The exposure: the transaction stream, its annual value, the value on which both functions were actually exercised by one person in the period, and any losses or unexplained differences found. The cause, which is rarely “the policy was not followed”: a role designed for a headcount the site no longer has, a workflow configured to let the requester approve, a deputy arrangement that became permanent, a system that cannot enforce separation, or a control that was never independent by design; the root cause method applies. And the recommendation, expressed as the rung of the ladder that fits the organization: separate where people exist, enforce in the system where the process runs through one, compensate with a control that meets the four conditions, or accept with a named owner and an expiry, and the report should say which rung and why, because “implement segregation of duties” recommended to a three-person depot is advice the depot cannot take. The severity ratings guide covers the rating; the specific point for segregation findings is that the rating follows the exercised exposure and the absence of an independent downstream control, not the count of conflicts.
The ten-test program
The program applies to any process with a conflict matrix; for processes run entirely through a system, the ERP analysis supplies tests 4 to 6 in full-population form. Sample sizes follow the usual conventions and the selection logic goes in a sampling memo.
| # | Test | Population | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Walk through the process to the point of independent reconciliation and classify every step | The process at each site variant | Process map with functions and performers, including deputies and small sites | Map stops before reconciliation; performers recorded from the procedure only |
| 2 | Build or validate the conflict matrix | All step pairs | Matrix with concealment scenarios and ratings; owner approval | No matrix; conflicts rated by count rather than exposure |
| 3 | Test capability from rosters, access lists and physical access | All roles in the matrix; all sites | Rosters; keys and token holders; system effective access | Conflicts held through deputies, keys or access nobody mapped |
| 4 | Test behavior from transaction records | All transactions in the period where data allows; sample of 40 site-days otherwise | Created-by and approved-by; count sheets; reconciliations; override approvals | Same person on both sides with value; write-offs by the counter |
| 5 | Quantify exercised exposure | Behavior results | Values by person and pair; unexplained differences | Exposure never computed |
| 6 | Test the treatment chosen for each conflict against the ladder | All conflicts in the matrix | Separation evidence; system enforcement configuration; compensating control design; acceptance records | Acceptance as the default; compensating controls that fail the four conditions |
| 7 | Test compensating controls’ operation | All compensating controls; sample of operations | Reviewer independence; timeliness; precision; evidence of review and follow-up | Reviews signed without questions; reviewer inside the process |
| 8 | Test system-enforced separations | Workflow and role configuration | Configuration inspection; requester-exclusion rules; change history | Requester can approve; configuration changed without record |
| 9 | Test risk acceptances | All acceptances | Owner, exposure, expiry, re-review | Perpetual acceptances; IT or local management accepting on the owner’s behalf |
| 10 | Test that new sites, roles and systems enter the matrix | Changes in the period | Matrix change history; onboarding checks | Acquired sites and new systems outside the matrix |
Worked example: MidState Beverage’s route cash process
MidState Beverage distributes drinks across three states from twelve depots and three hundred routes, with roughly thirty-one million dollars a year collected by drivers in cash and cheques, about fourteen percent of revenue. Its FY27 route cash engagement, the first in the plan, applied the method above to a process that ran almost entirely outside the ERP: handheld settlements, depot cash counts on paper, reconciliations in depot spreadsheets, overrides entered in the route-accounting module. The six-person audit function mapped the process at all twelve depots, because the procedure described one process and the depots ran several.
The capability test found the reconciliation performed by the same person who counted the cash at nine of the twelve depots, in seven cases the depot clerk and in two the depot manager, and at three depots the reconciliation and the override approval were both performed by the manager. The behavior test, on a stratified sample of sixty reconciliations, five per depot, found fourteen that failed, including shortages written off by the person who had counted the cash with no second signature, and it found through the override analysis that 1,412 of the 37,400 overrides in the period had been approved by their own requester, which the automated controls test traced to the workflow’s routing rule. The exercised exposure was the value of shortages written off at the nine depots and the value of self-approved overrides; the Dayton depot’s FY26 driver theft of 18,400 dollars, discovered by a customer complaint rather than by any reconciliation, was the loss the engagement could point to. The findings were reported as F1, reconciliation not independent at nine of twelve depots, rated High and owned by the director of route accounting with a 30 June date, and F2, overrides self-approved, rated High and owned by the operations vice president.
| Conflict | Depots affected | Rung chosen | Treatment |
|---|---|---|---|
| Count cash and reconcile | 7 (clerk) and 2 (manager) | Redesign for 6 large depots; compensate for 3 small depots | Reconciliation moved to head office route accounting from the count sheet and the settlement; at the three smallest depots, a regional manager’s weekly review of shortages by route and clerk plus monthly surprise counts, with the residual risk accepted by the COO until the ERP migration |
| Reconcile and approve overrides | 3 (manager) | System-enforce | Workflow reconfigured so overrides route to the regional manager and the requester is excluded from approving |
| Enter and approve overrides | 11 managers | System-enforce | Same reconfiguration; daily override report by requester and approver to head office |
| Prepare and bank the deposit | All depots | Compensate | Head office reconciliation of deposits to bank statements within two days, already independent, strengthened with the count sheet as a third source |
The report’s recommendation used the ladder explicitly, which is why the three small depots received a compensating control and a signed acceptance rather than a demand for a fourth employee, and why the COO’s acceptance carried an expiry tied to the ERP migration that will make system enforcement possible everywhere. The FY27 plan’s validation engagement will test whether the head office reconciliation and the regional reviews operate; the issue validation guide covers how.
Common mistakes
- Looking for segregation only in systems. Cash, inventory, payroll input and treasury releases have conflicts no tool will find.
- Stopping the map before reconciliation. The independent check is the function that makes the others safe; map until you reach it.
- Recording performers from the procedure. Deputies, small sites, key holders and access lists are where conflicts live.
- Counting conflicts instead of rating exposure. The rating follows value, ease of diversion and the absence of an independent downstream control.
- Testing capability only. Behavior tests from transactions and count sheets produce the exposure and the investigation population.
- Accepting “we have a compensating control.” Independence, timeliness, precision, evidence; test it.
- Recommending a fourth employee to a three-person site. Use the ladder and say which rung.
- Letting acceptance be the first rung. It is the last, with an owner and an expiry.
- Ignoring IT and governance conflicts. Develop-and-deploy and authorize-and-review at the top are the same principle.
- Writing “policy not followed” as the cause. Role design, headcount, workflow configuration and deputy arrangements are the causes; fix those.
Related guides
- How to run an ERP segregation of duties analysis
- Preventive, detective and corrective controls
- Fraud risk management
- Process walkthroughs
- Testing automated controls and system configurations
- How to audit IT change management
- How to audit privileged access
- Internal controls and the Three Lines
- The P2P fraud analytics catalog
- The risk and control matrix template
- Root cause analysis for audit findings
- Issue validation
- RCM Workbench
Leave a Reply