Segregation of Duties in Accounts Payable

Segregation of duties (SoD) is the internal control principle that divides financial responsibilities so no single person controls an entire transaction from start to finish. In accounts payable, this means separating the people who enter invoices from the people who approve them, and separating approvers from the people who release payments.

SoD is one of the foundational controls in any finance function. Without it, a single employee can create a fictitious vendor, submit a fake invoice, approve it, and release payment — all without detection. With SoD in place, committing fraud requires collusion between multiple people, which is exponentially harder to execute and conceal.

For organizations subject to SOX, government contracts, or external audits, SoD is not optional. It is a specific requirement that auditors test and report on.

Common SoD Conflicts in AP

SoD conflicts occur when a single person has the ability to perform two or more actions that should be separated. In AP, the most dangerous conflicts are:

Each conflict creates a control gap that a single person can exploit. The more conflicts that exist in your AP process, the higher your fraud and error exposure.

The Three Key Separations in AP

At minimum, every AP function should enforce these three separations:

1. Invoice Entry vs Invoice Approval

The person who enters invoice data into the system should never be the same person who approves it for payment. This separation ensures that someone independent reviews the transaction before it progresses.

Without this separation, an AP clerk can enter any invoice — including one to a vendor they control — and approve it without anyone else seeing the transaction.

2. Approval vs Payment Release

The person who approves an invoice should not be the same person who releases the payment batch. This separation ensures that a second set of eyes reviews the payment before money leaves the organization.

This is the most audited SoD control in AP. Auditors consistently test whether the person who approved the invoices in a payment batch is different from the person who released the batch.

3. Vendor Master Management vs Invoice Processing

The person who creates and edits vendor records — especially bank account information — should not be the same person who processes invoices for those vendors. This separation prevents the creation of fictitious vendors that receive real payments.

Vendor master changes, particularly bank detail changes, should always require secondary approval from someone outside the AP invoice processing team.

Approval vs Payment Separation in Detail

This separation deserves special attention because it is where the largest payment fraud schemes operate.

Who Should Approve Invoices

Invoice approvers are typically the budget owners, department heads, or project managers who authorized the purchase. They verify that the goods or services were received and the charges are correct. Their approval is a business judgment: is this invoice valid and should we pay it?

Who Should Release Payment Batches

Payment release should be performed by someone in treasury or senior finance — not by the same people who process or approve invoices. The payment releaser verifies that the batch contains only approved invoices, that amounts are correct, and that bank details match verified vendor records.

Dollar Thresholds and Dual Authorization

For payment batches above a defined dollar threshold, dual authorization should be required — two authorized individuals must approve the release. This adds a second layer of verification for high-value disbursements.

Typical thresholds:

• Under $25,000: single authorized releaser
• $25,000 to $100,000: dual authorization
• Over $100,000: dual authorization plus treasury review

System Enforcement of SoD

Policy-based SoD relies on people following rules. System-enforced SoD makes violations technically impossible.

Role-Based Access Controls

AP automation platforms enforce SoD through role-based access controls (RBAC). Each user is assigned a role that defines what actions they can perform. The system prevents conflicting actions:

• A user with the "AP Clerk" role can enter invoices but cannot approve them
• A user with the "Approver" role can approve invoices but cannot release payments
• A user with the "Payment Releaser" role can release batches but cannot create or modify vendor records

System-Enforced Separations

Beyond roles, the system enforces transaction-level separations:

• The system blocks a user from approving an invoice they entered
• The system blocks a user from releasing a payment batch containing invoices they approved
• The system blocks a user from both creating a vendor and processing invoices for that vendor
• The system requires secondary approval for vendor bank detail changes

Audit Logs for SoD Compliance

Every action is logged with the user, timestamp, and action taken. If an administrator overrides a SoD control, the override is logged separately and flagged for audit review. This creates the evidence auditors need to verify that SoD controls are operating effectively.

SoD in Small Teams

The biggest challenge with SoD is that small teams often do not have enough people to fully segregate all duties. A two-person AP team cannot maintain three-way separation between entry, approval, and payment.

Compensating Controls

When full segregation is not possible, compensating controls reduce the risk:

• Management review — A manager outside AP reviews all transactions above a defined threshold
• Dual authorization — Two people must approve any payment, even if one of them entered the invoice
• External reconciliation — Someone outside the AP team reconciles the AP subledger to the GL monthly
• Periodic audits — Regular review of AP transactions, vendor master changes, and payment patterns
• System-enforced high-risk controls — Even in a small team, the system can enforce the highest-risk separations such as preventing the same person from entering and approving the same invoice

How Automation Helps Small Teams

AP automation makes SoD more achievable for small teams because:

• The system performs many of the tasks that would otherwise require a separate person (matching, duplicate detection, routing)
• Role-based access controls enforce separations that small teams cannot enforce through organizational structure alone
• Audit trails provide visibility that compensates for having fewer people involved in review

Audit Implications

What Auditors Test

SOX auditors and internal auditors test SoD controls through:

• Design testing — Reviewing role definitions, access controls, and policies to verify that SoD is designed into the process
• Operating effectiveness testing — Sampling transactions to verify that SoD controls were actually followed during the audit period
• Access review — Reviewing user access to verify that no user has conflicting roles or permissions
• Override testing — Checking whether any SoD overrides occurred and whether they were properly authorized and documented

Common Findings and Remediation

The most common SoD audit findings in AP:

• Users with conflicting roles (e.g., AP Clerk and Approver assigned to the same person)
• No evidence of secondary approval for vendor bank detail changes
• Same person approved and released payment batches
• No system enforcement — SoD exists in policy but not in system controls
• Missing documentation for SoD override approvals

Each finding requires remediation: adjusting roles, implementing system controls, adding secondary approvals, or documenting compensating controls.

Documentation Requirements

For each SoD control, maintain:

• Written description of the separation and who is responsible
• System configuration evidence showing role-based restrictions
• Periodic access review reports showing no conflicting assignments
• Override logs with approval documentation for any exceptions

Organizations using AP automation generate most of this documentation automatically through system logs and access reports.

For more on AP compliance controls, see the SOX compliance glossary entry and the audit compliance use case.