Every segregation-of-duties framework is written for an organisation with more finance staff than yours. In a ten-person team the same person often maintains the vendor master, enters the invoice and prepares the payment run — not through negligence, but because there are ten people and the month still has to close.
The usual response to this is a policy document stating that duties are segregated, which everyone signs and nobody can evidence. The better response is to accept the constraint, design compensating controls deliberately, and document them. Auditors are used to compensating controls. What they cannot accept is a control gap that nobody has acknowledged.
Start with the four conflicts that actually matter
Commercial SoD rulesets ship with hundreds of conflict pairs. In a small team, four of them carry most of the risk:
- Vendor master maintenance combined with payment processing — the single highest-value fraud path in most mid-market companies.
- Purchase order creation combined with goods-receipt confirmation — enables fictitious receipts and quantity manipulation.
- Journal entry posting combined with bank reconciliation — allows a discrepancy to be reconciled away rather than explained.
- Customer credit-limit maintenance combined with order release — quietly converts a credit policy into a suggestion.
Fix these four properly before opening a two-hundred-row conflict matrix. Depth on the paths that carry real money beats breadth across paths that do not.
Map conflicts to permissions, not to job titles
This is where most SoD exercises quietly fail. The matrix is built at the level of job titles — "the Accounts Payable Officer does not approve payments" — while the actual system permission that allows payment approval is attached to a role three people hold, including a superuser account created during implementation and never revoked.
Export the actual role-to-permission and user-to-role assignments from your ERP and test the conflict matrix against that. Every engagement of this kind we have run has surfaced at least one account with more access than anyone believed, and usually the account belongs to someone who left.
Design compensating controls that generate evidence
A compensating control is only real if it produces evidence a third party can inspect months later. "The Finance Manager reviews payments" is not a control. These are:
01
A defined exception report, reviewed on a schedule
Not "reviews payments" but "reviews the report of all vendor bank-detail changes in the period, weekly, and signs it". The report is the artefact, the signature is the evidence, and the schedule is testable.
02
Dual authorisation above a threshold
Enforced in the system, not in policy. Set the threshold from your own payment distribution — usually where roughly 80% of value sits above and 20% of transaction count. Below it, rely on detective controls.
03
Independent reperformance on a sample
Someone outside the process — an internal auditor, a director, a colleague from another function — re-performs a small sample of reconciliations quarterly and records what they checked.
04
System-enforced immutability
No backdating beyond the closed period, no deletion of posted entries, mandatory audit-trail retention. These are configuration decisions that remove entire conflict classes without needing headcount.
Automate the detection, because sampling misses
Annual sample-based testing catches systematic error and misses the single transaction that matters. Continuous control monitoring is cheap once the data is in one system: a scheduled query set that flags duplicate vendor bank details, payments to accounts changed within seven days, invoices just under an approval threshold, weekend or after-hours journal entries, and users transacting outside their normal pattern.
Route each exception to a named owner with a response deadline. The value is not in the sophistication of the queries — it is in the exception reaching a person who has to close it.
Write down what you decided not to do
The deliverable that gets the least attention and pays back the most is a short register of accepted risks: this conflict remains, here is why full separation is impractical at current headcount, here is the compensating control, here is who reviews it, here is the trigger — a headcount or volume threshold — at which we revisit.
That register turns an audit finding into an audit discussion. It also means that when the team grows to sixteen people, the decision is already documented and the remediation is a scheduled item rather than a rediscovery.
Written by the Techlyst Governance Practice. If any of this describes your situation, a 45-minute consultation will tell you which phase you actually need — book one here.