Segregation of Duties in Accounts Payable: The Complete Guide

Segregation of duties (SoD) in accounts payable means splitting the payment process so no single person can complete a fraudulent transaction alone: the person who requests a purchase cannot approve it, the person who approves cannot execute payment, and the person who executes payment cannot reconcile the books. Each handoff creates an independent checkpoint that fraud or error must survive.

It is the single most fundamental control in finance — appearing in every serious framework (COSO, SOX) — and the one most commonly violated in companies between 20 and 300 employees, usually without anyone noticing.

The Core Functions That Must Be Separated

An AP process has five natural functions. The rule: no one person should hold more than one.

• Initiation: requesting the purchase (any employee)
• Approval: authorizing the commitment (managers, per the approval matrix)
• Payment execution: releasing funds (AP or finance)
• Reconciliation: matching records to bank activity (accounting)
• Vendor master maintenance: adding or changing payee bank details

The last one is the sleeper. Giving the person who pays also the right to edit vendor bank details is how payment-diversion schemes work — one person redirects the payee, then pays the invoice, and no one else ever sees it.

Why It Fails at Mid-Size (The Team of Three Problem)

Small companies can't afford five specialists, so roles blur: the office manager requests, the owner approves, and the accountant does everything else — pays, reconciles, and maintains the vendor list. It works because everyone knows everyone.

Then the company grows. The accountant now handles hundreds of payments monthly, vendor onboarding happens informally, and nobody remembers which rules still hold. This is the zone where fraud losses concentrate: big enough for meaningful amounts, small enough that controls were never formalized.

The Minimum Viable SoD for a Small Team

You don't need five people. You need three separations that matter most:

1. Requester ≠ Approver. No one approves their own spend. Enforce this in the workflow engine, not by policy.
2. Approver ≠ Payer. Whoever authorizes never executes the payment.
3. Payer ≠ Vendor-admin. Whoever pays can never edit payee bank details — those changes need a separate confirmation.

With those three enforced, a fraudster needs a conspiracy of two — and two-person schemes are dramatically rarer, riskier, and easier to detect.

What Auditors Actually Check

• Can one person create a vendor AND release payment to it?
• Are there approval records proving separation — or just a policy document?
• Who can change vendor bank details, and is the change independently confirmed?
• Do the people performing each function have the system permissions to do others' jobs?

The last point is where most companies fail the audit: the policy says one thing, the system permissions allow another. SoD enforced only on paper is indistinguishable from no SoD at all.

How Software Enforces What Policy Can't

Role-based access makes the separations structural instead of behavioral:

• Role-based permissions mean a payer literally cannot see the approval screen
• Vendor bank-detail changes route through a separate approval queue — the payer can't self-serve a new payee
• The audit trail proves the separation existed, with named approvers at every step

Policy says "we don't let one person do everything." Enforced workflow makes it true.

Frequently Asked Questions

What if we only have two finance people?

Split the three critical functions between them plus a non-finance manager (the owner or COO can be the second approver). The key separations survive with three people wearing defined hats.

Is segregation of duties required by law?

Not directly for private companies — but it's expected under SOX for public companies, required by most lenders' covenant reviews, and demanded by auditors reviewing internal controls everywhere.

What's the difference between SoD and the approval matrix?

The matrix defines WHO approves WHAT (by amount and type). SoD defines who must NEVER hold two conflicting powers. The matrix routes; SoD separates. Both together are the control backbone.

Approvdit enforces segregation of duties structurally — role-based access, a separate vendor-approval gate for bank-detail changes, and a tamper-evident trail proving every separation. Book a live demo to see the controls running.