Segregation of Duties (SoD)

The principle that no single person should be able to complete a transaction that could defraud the company from start to finish. It is the foundation of internal control, and in ERP it becomes a concrete authorisation-design problem.

The principle

The four functions that must be separated:

  AUTHORISE   approve the transaction
  RECORD      enter it into the system
  CUSTODY     have physical or system control of the asset
  RECONCILE   verify and review

One person holding more than one of these can commit and conceal fraud.

The classic conflicts

Conflict	The fraud it enables
Create vendor + approve invoice	Fictitious vendor, fake invoices, paid to your own account
Create vendor + release payment	Same, end to end
Approve PO + receive goods	Approve a purchase, falsely confirm receipt, split the proceeds with the supplier
Enter invoice + release payment	Fake invoice, pay it yourself
Maintain customer master + post credit memos	Write off a friend’s debt, or your own
Post journal + reconcile the account	Post a fraudulent entry and hide it in the reconciliation
Create employee + run payroll	Ghost employees
Change bank details + approve payment	Redirect a legitimate payment
Maintain inventory + perform stock counts	Steal stock, adjust the count to match
Develop code + deploy to production	Insert unauthorised logic
Administer users + transact	Grant yourself whatever access you need
Set prices + approve sales orders	Sell below cost to a related party

Each of these has a real, documented fraud case behind it. SoD rules exist because these things happened.

The SoD matrix

                      Create   Approve  Goods   Enter    Release  Post    Maintain
                      Vendor   PO       Receipt Invoice  Payment  Journal Bank Det
Create Vendor           —       ⚠️       ⚠️      ❌       ❌       ⚠️      ❌
Approve PO             ⚠️        —       ❌      ⚠️       ❌       ⚠️      ⚠️
Goods Receipt          ⚠️       ❌        —      ❌       ❌       —       —
Enter Invoice          ❌       ⚠️       ❌       —       ❌       ⚠️      ⚠️
Release Payment        ❌       ❌       ❌      ❌        —       ❌      ❌
Post Journal           ⚠️       ⚠️       —      ⚠️       ❌        —      ⚠️
Maintain Bank Details  ❌       ⚠️       —      ⚠️       ❌       ⚠️       —

❌ = prohibited combination      ⚠️ = requires a compensating control

A real matrix has 100–300 rule pairs. Vendors and audit firms publish standard rule sets; most companies start from one and adapt.

Analysis and remediation

1. Define the rule set (conflicting function pairs)
2. Map each function to the technical authorisations that enable it
3. Analyse: which users hold conflicting combinations?
4. For each conflict:
     a. REMOVE  — take away the unnecessary access (always try this first)
     b. MITIGATE — implement a compensating control
     c. ACCEPT  — formally, with documented business justification and approval
5. Monitor continuously — new conflicts appear with every role change
6. Report to audit and the audit committee

Step 2 is where the work is. “Create vendor” is not one authorisation — it’s several transactions and objects, plus any custom program that can do the same thing. Custom code is a common blind spot: a bespoke “vendor quick create” utility that bypasses the standard authorisation object doesn’t appear in the analysis, and quietly reopens the conflict.

Compensating controls

Where separation is genuinely impossible — a five-person finance department cannot separate everything:

Control	Example
Independent review	The CFO reviews all vendors created in the month, against supporting documents
Exception reporting	Automated alert when the same user creates a vendor and enters an invoice for it
Dual authorisation	Two people must release any payment
Detailed logging + review	All actions by the conflicted user reviewed monthly by someone independent
Rotation	Duties rotate periodically; mandatory holidays (a fraud often unravels while its operator is away)
Bank-side controls	Positive pay; the bank verifies payments against an approved list
External review	An external accountant reviews monthly

A compensating control must be documented, performed, and evidenced. “The manager reviews it” with no record of the review is not a control — it’s an assertion, and auditors treat it as such.

Sensitive access

Distinct from SoD: some access is dangerous on its own, regardless of what else the user holds.

- Post directly to the GL
- Change configuration in production
- Table maintenance / direct data edit
- Debug with replace
- User administration
- Change posting periods
- Delete or archive data
- Run OS commands
- Superuser / all-access profiles

These need: minimal assignment, individual justification, logging of every use, and periodic review.

SoD and the developer

Two aspects.

Your access

❌ Developer with production write access
❌ Developer who can deploy their own code without review
❌ Developer with debug-with-replace in production
❌ Developer who can grant themselves authorisations

✅ Developer works in DEV
✅ Code reviewed by someone else
✅ Deployed by a separate function (Basis/DevOps)
✅ Production access is read-only, or firecall with approval

“Developers have production access” is one of the most common IT general controls findings in a SOX audit. It is worth pushing back on, even when it makes your day harder — because when a production incident happens and you had write access, you become part of the investigation.

The code you write

Every custom object can create or destroy an SoD control:

❌ A custom "quick vendor create" utility that skips the standard
   authorisation object → invisible to SoD analysis, control bypassed

❌ A custom approval workflow where the requester can be their own approver

❌ A custom posting program that uses a technical service account
   → all postings attributed to "BATCHUSER", attribution lost

✅ Custom objects check the same authorisation objects as the standard
✅ Approval workflows enforce requester ≠ approver
✅ Postings carry the real user, not a technical account

When you build a custom transaction, tell the security team. They need to add it to the SoD rule mapping. A custom program that isn’t in the rule set is a hole in the analysis.

Tools

Tool	Notes
SAP GRC Access Control	The market standard for SAP: risk analysis, access request workflow, emergency access, role management
Pathlock, Fastpath, SafePaaS, Onapsis	Cross-platform GRC and SoD
SailPoint, Saviynt, One Identity	Identity governance with SoD policy enforcement
Custom SQL analysis	Viable for smaller systems — a rule table plus queries over role assignments

Preventive vs detective:

Preventive — the access request is blocked at the point of assignment because it would create a conflict. Far better.
Detective — periodic analysis finds conflicts after the fact. Necessary, but you’ve had the exposure in the meantime.

Aim for preventive on the critical conflicts and detective on everything else.

Small organisations

A 12-person company cannot separate all duties. The pragmatic approach:

Separate what you can — especially payment release from everything else
The owner/CFO performs the review controls personally
Use bank-side controls (dual authorisation at the bank, positive pay)
Automate exception reporting — the system does the monitoring
Mandatory holidays for finance staff
External accountant reviews monthly
Document that SoD is limited, with the compensating controls listed

Auditors accept limited SoD in small organisations if the compensating controls are real and documented. They do not accept “we trust everyone”, however true it may be.

Fraud reality

Occupational fraud research (the ACFE’s biennial studies are the standard reference) consistently finds:

Median losses in the low hundreds of thousands, with a long tail into millions
Median duration around 12–18 months before detection
Tips are the most common detection method — more than all audits combined. Which is why whistleblower hotlines matter
The most common perpetrator profile: a long-tenured, trusted employee with no prior record
Lack of internal controls is the most cited contributing factor

Billing schemes (fictitious vendors) are the most common and among the costliest. Which is exactly why “create vendor + approve invoice” is the first conflict on every SoD matrix, and why vendor bank detail changes deserve dual control and callback verification.