Plain definition
Segregation of duties separates steps that would be dangerous in one person’s hands. For a supplier payment, those steps may include creating supplier details, confirming goods were received, entering an invoice, releasing payment, and reconciling the bank account. The point is not to create bureaucracy; it is to make an error or misuse visible to another person.
Job titles alone do not establish separation. System access, temporary cover, emergency overrides, and user changes can give one person incompatible powers even where the organisation chart looks sound. Small teams may need compensating review rather than a perfect split.
Illustrative example
Suppose a purchasing requester confirms that ordered materials arrived, a master-data administrator creates the supplier record, an accounts-payable clerk enters the invoice, and treasury releases the approved payment. Each person leaves evidence in the system. The controller, who did none of those steps, reviews the weekly bank reconciliation and investigates new suppliers or unusual payment changes.
If one person could create a supplier, enter an invoice, release cash, and reconcile the bank, that person could hide a fictitious payment more easily. The separate steps give the controller a realistic opportunity to notice an unexplained change.
Separation addresses incompatible activities; it does not remove the need for appropriate approval limits, evidence, or management review.
Why it matters
It reduces the chance that a single error or abuse both occurs and is concealed.
It lets a founder test actual access and workflow instead of assuming that different job descriptions provide a control.
Practical consequence
Map the people and system permissions for each sensitive step, including administrators, temporary cover, and leavers.
Where a small team cannot split a step, add a documented independent review of supporting evidence and unusual changes, then test that the reviewer can see the full activity.