If the same person can create a vendor, approve an invoice from that vendor, and release the payment, there is no independent check on any of those three actions, which is exactly the gap segregation of duties is designed to close. The control is not about distrust of any one employee, it is about removing the opportunity for an error or a deliberate fraud to go unnoticed.

Where SoD conflicts typically show up

The most commonly cited conflicts are one person controlling both vendor master data and payment approval, one person able to both create and approve a journal entry, and one person with access to both the requisition and the receiving confirmation for the same purchase. In banking and payments, this same principle is usually called a maker-checker control: the person who initiates a transaction can never be the same person who approves it. Auditors specifically test for these role combinations during SOX and financial statement audits, and larger ERPs like SAP and Oracle ship dedicated governance-risk-and-compliance modules that automatically cross-reference every user's granted system roles against a predefined conflict matrix, flagging violations before they turn into an audit finding.

Under Sarbanes-Oxley Section 404, US public companies must assess and attest to the effectiveness of their internal controls, and an unresolved SoD conflict on a financially material process can be flagged as a control deficiency or, if severe enough, escalate to a material weakness that has to be disclosed in the company's financial filings.

In smaller finance teams where headcount makes a clean split impractical, the usual fallback is a compensating control, such as a second person reviewing a report of every transaction one individual touched, rather than skipping the control entirely.

Frequently Asked Questions

What's a concrete example of an SoD conflict?

One person able to both create a vendor record and approve a payment to that same vendor. Without a second person in the loop, a fictitious vendor and a self-approved payment could go undetected.

What is a "maker-checker" control?

The banking and payments industry's name for the same underlying principle as SoD: the person who initiates, or "makes," a transaction can never be the one who approves, or "checks," it.

How do large ERPs automatically detect SoD conflicts?

Dedicated governance-risk-and-compliance modules cross-reference every user's granted system roles and permissions against a predefined conflict matrix, flagging risky combinations automatically instead of relying on a manual audit to catch them.

What happens if an SoD violation surfaces during a SOX audit?

It can be flagged as a control deficiency, or if it's significant enough, escalate to a material weakness that the company must disclose in its financial filings.