Finance Index
What is segregation of duties in accounts payable?
Reference guide to segregation of duties AP, including control design, audit evidence, risk points, finance procedures, and compliance review.
Segregation of duties (SoD) is the principle that no single person should control a transaction end to end. In AP, that means separating vendor creation, invoice entry/coding, invoice approval, payment execution, and reconciliation - so committing fraud or concealing an error requires either collusion or a control failure, not just one person's opportunity.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Segregation of duties in accounts | Segregation of duties (SoD) is the principle that no single person should control a transaction end to end. | Keeps evidence clear and reduces control risk. |
| Workflow | The classic AP SoD map separates five functions: (1) vendor master maintenance. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Related terms | Preventive SoD blocks the conflict in the system - roles are configured so the same user cannot enter and approve the same invoice, and the software enforces it. | Helps finance decide what to do next. |
| Vendor onboarding | Because that combination is the complete fictitious-vendor fraud kit: invent the payee, bill the company, authorize the spend. | Keeps vendor records and payment decisions reliable. |
| The person who enters | No - entry and approval are the foundational AP separation. | Keeps work moving without losing accountability. |
Which duties must be separated in the invoice-to-pay process?
The classic AP SoD map separates five functions: (1) vendor master maintenance - who can create or modify vendors and banking details; (2) invoice entry and coding; (3) invoice approval - the authorization that spend is legitimate; (4) payment processing and release - building and executing payment runs; (5) reconciliation and review - comparing the subledger, bank, and GL. The highest-risk combinations are vendor creation + invoice approval (fictitious vendor schemes), invoice entry + approval (self-approval), and payment creation + payment release (unilateral cash movement). Where headcount forces overlap, the overlap must be visible and compensated by review.
What is the difference between preventive SoD and detective SoD?
Preventive SoD blocks the conflict in the system - roles are configured so the same user cannot enter and approve the same invoice, and the software enforces it. Detective SoD allows the action but catches it afterward - periodic reports of who did what, reviewed by someone independent. Preventive is stronger and cheaper to operate (the system does the work); detective is the fallback where prevention isn't feasible. Auditors accept both, but a detective control with no evidence anyone reviewed the report is no control at all.
Why can't the same person create a vendor, enter an invoice, and approve it?
Because that combination is the complete fictitious-vendor fraud kit: invent the payee, bill the company, authorize the spend. Each separation forces an independent person between the perpetrator and the cash.
Should the person who enters an invoice be allowed to approve it?
No - entry and approval are the foundational AP separation. The person creating the liability record shouldn't be the one authorizing it; even absent fraud risk, self-approval eliminates the error-catching value of a second perspective.
What does a segregation of duties matrix for AP look like and how do I build one?
Rows are functions (vendor maintenance, entry, coding, approval, payment creation, payment release, reconciliation, system admin); columns are roles; cells mark allowed, prohibited, or allowed-with-compensating-control. Build it from your actual system permissions, not your org chart - then test the system against it.
How do I test for SoD conflicts in our current AP process?
Pull actual user permissions from every relevant system (AP tool, ERP, bank portal), map each user's combined capabilities against the matrix, and flag conflicts. Then test activity, not just access: did anyone actually approve invoices they entered? Access conflicts are findings; exercised conflicts are incidents.
Is SoD legally required, or just best practice - what do SOX and auditors actually mandate?
No law names SoD specifically. SOX requires public companies to maintain effective internal control over financial reporting, and SoD is so foundational to that standard that material conflicts surface as control deficiencies. Private companies face it through lender requirements, audits, and the practical reality that fraud loss doesn't check your filing status.
We found one person who can do everything in AP end to end - how urgently do we need to fix this and what first?
Urgently - this is the highest-risk access profile in finance. First, split payment release from everything else (cash movement is the irreversible step), then separate vendor maintenance from approval. While remediating, run a look-back review of that person's activity - not as accusation, but because you now know the control didn't exist.
How should SoD extend across systems - someone with AP entry rights in the automation tool and payment rights in the bank portal?
SoD is about the person's combined capability, not any single system's roles. Inventory access across the AP platform, ERP, and bank portals together; the entry-here-payment-there combination is a real conflict that single-system access reviews systematically miss.
What is a mitigating or compensating control when SoD can't be fully achieved?
An independent check that addresses the same risk the separation would have: an owner or controller reviewing payment runs before release, monthly review of vendor master changes, bank-level dual authorization. To satisfy auditors it must be specific, documented, performed by someone genuinely independent of the conflicted duty, and evidenced.
Stampli perspective
Segregation of duties in Stampli is enforced by design, not by policy documents: role-based permissions separate processing, approval, administration, and payment functions, and the workflow distinguishes who dispatched, who approved, and who authorized at every step. Invoice approval and payment approval are separate control gates with separately assignable roles. Because every action is attributed to a named user in an immutable activity record, both the enforcement and the evidence come from the same system.