Segregation of Duties for Payments: Controls That Prevent Fraud

Hands segregating payment folders in office

Segregation of duties for payments means no single employee controls a payment from start to finish: creating a vendor, approving the invoice, releasing the funds, and reconciling the bank statement must sit with at least two different people. The single highest-priority control is maker-checker: enforce it so nobody who can add or edit a vendor can also be the one who releases payment to that vendor. If that one rule exists in your accounts payable process, you’ve closed the door most internal fraud walks through.

Two things tell you whether your controls are real or just written policy:

Pro Tip: If you can log into your AP system right now and both create a vendor and push a payment to that vendor, you’ve found your biggest exposure before an auditor does.

Key Takeaways

Enforcing maker-checker so no single person can create a vendor and release payment to it is the single highest-leverage control against payment fraud.

Point Details
Separate the four lifecycle stages Vendor creation, invoice approval, payment execution, and reconciliation each need a different person.
Watch the highest-risk pairing Vendor admin combined with payment execution is the combination behind most ghost-vendor fraud.
Build a risk-tiered approval matrix Reserve dual or triple sign-off for high-dollar, new-vendor, or cross-border payments to avoid alert fatigue.
Document compensating controls for small teams CFO sign-off thresholds and surprise reconciliations satisfy auditors when full separation isn’t possible by headcount.
Capture full audit-trail evidence Log maker, checker, timestamp, before/after values, and reason code on every payment action.
Automate enforcement where you can Platforms like Brokerpay build maker-checker approval workflows and audit trails directly into commission and agent payment processes.

Table of Contents

What Segregation of Duties Means Across the Payment Lifecycle

The accounts payable cycle has four distinct control points, and segregation of duties payments controls exist to keep them in separate hands: vendor setup, invoice approval, payment execution, and reconciliation. Each stage creates its own opportunity for someone to manipulate the process if they also control the stage before or after it.

Vendor master data is the highest-risk combination in the entire cycle. Someone who can create a vendor record and also approve or release payment to it can invent a fictitious supplier, route funds there, and delete the evidence before anyone checks the bank statement. This is the classic ghost-vendor scheme that shows up in fraud case studies year after year, and it works precisely because one person held two functions that should never overlap.

The lifecycle breaks down into four stages worth mapping individually:

  1. Vendor creation and maintenance. Adding, editing, or approving changes to vendor records, especially banking details.
  2. Invoice receipt and approval. Matching invoices to purchase orders or contracts and certifying they’re legitimate and owed.
  3. Payment execution. Initiating the actual transfer, whether by ACH, check, or wire.
  4. Reconciliation. Matching bank activity against the general ledger to confirm the payment that went out matches what was authorized.

Public-sector and university control frameworks frame this plainly: no single person should have both execution and certification authority over a payment. This standard applies just as well to a mid-size brokerage as it does to a state agency’s separation of duties overview. This is also where Sarbanes-Oxley (SOX) internal control requirements bite hardest for public companies and their subsidiaries, and where auditors spend the bulk of their AP testing time.

Which Roles Create the Riskiest Conflicts?

Six roles typically touch the payment process: vendor admin, invoice entry clerk, invoice approver, payment executor, bank reconciler, and treasury. Each one is narrow by design. Trouble starts the moment one person holds two of them at once.

The pairings that show up in nearly every fraud postmortem:

A common real-world failure looks unremarkable at first: a controller who’s “just helping out” during a staffing gap ends up with vendor-edit rights and payment-release rights in the same login. Nothing malicious happens for months. Then a bank account gets edited two days before a large invoice clears, and nobody catches it because the same person who made the edit also signed off on the payment. The red flag auditors look for isn’t a smoking gun. It’s a pattern of vendor edits clustered right before payment runs, especially on dormant or rarely used vendors.

Pro Tip: Pull a recent report of every vendor bank-detail change and cross-reference it against who approved the next payment to that vendor. If the names match even once, you have a gap worth fixing today.

Tactical Controls That Close SoD Gaps in Accounts Payable

Maker-checker is the backbone of payment authorization controls, and it only works when the “checker” is someone who genuinely cannot also act as the “maker” on the same transaction. That means separate logins, separate permission sets, and a system that physically blocks the same user ID from both steps rather than trusting people to self-police.

Four controls do most of the heavy lifting:

  1. Enforce maker-checker at the system level, not the policy level. A written rule that “invoices over $5,000 require a second approver” means nothing if the software lets one login submit and approve. The control has to be baked into permissions, because distinct permissions and enforced workflows are what actually reduce internal fraud risk, not simply having more employees on staff.
  2. Require two-person verification for any banking-detail change. Vendor banking edits should trigger a mandatory secondary review, ideally from someone in treasury or a controller who wasn’t involved in the original vendor setup. This single control stops the majority of business email compromise and vendor impersonation schemes.
  3. Build tiered authorization by dollar amount, entity, and currency. A small reimbursement doesn’t need the same scrutiny as a large wire transfer to a new international vendor. Set thresholds that escalate approval requirements as the risk rises, and separate the “approve” action from the “release” action so a single approver can’t also push the button that sends money out the door.
  4. Lock out same-user edit-and-approve sequences programmatically. If your AP platform allows configuration of hard blocks (not soft warnings) that prevent the same user ID from creating and approving the same record, use them. Soft warnings get clicked through under deadline pressure.

Firms handling customer funds face an added layer here. FINRA’s own inspection priorities call out insufficient segregation of customer assets as a recurring finding, with examiners expecting documented controls and periodic evaluation of reserve accounts and check handling. That standard is written for broker-dealers, but the underlying logic transfers directly to any business holding client trust funds, earnest money, or escrow balances: the person who can move the money should never be the only person who reconciles it.

Building a Risk-Based Approval Matrix for Payments

An approval matrix works when it maps specific actions against specific risk levels, not when it’s a vague org chart that says “manager approves purchases.” Start by listing every payment action your AP process performs, then rate each one by potential dollar exposure and fraud likelihood.

A workable matrix follows this logic:

Risk-based, tiered design matters more than most finance teams assume. A static, blanket rule that flags every transaction for review creates alert fatigue, and reviewers start rubber-stamping everything, which defeats the entire purpose. Academic research on risk-based control design makes this point directly: dynamic tiering that reserves real scrutiny for genuinely high-risk transactions outperforms a one-size-fits-all approval rule every time.

Exception handling needs its own documented path. When a legitimate business need requires bypassing a normal control (a vendor needs an emergency payment before the standard verification window closes), that exception should still require a named approver, a written reason, and a follow-up review within a set number of days. An exception without a paper trail isn’t a shortcut. It’s a gap waiting to be found by whoever audits you next.

Hand stamping emergency payment document

What If Your Team Is Too Small to Fully Separate Duties?

Full separation isn’t always possible. A three-person accounts payable team can’t always assign four distinct people to four distinct lifecycle stages, and auditors know this. What they expect instead is documentation showing you identified the gap and built a specific, reviewed mitigation around it.

The standard mitigation path looks like this:

  1. Document the specific conflict. Name the two combined roles and the reason full separation isn’t feasible right now (headcount, budget, transition period).
  2. Require CFO or controller sign-off above a defined threshold. If the person handling both vendor setup and payment execution processes anything above a defined threshold, a senior leader outside that workflow must independently approve it before release.
  3. Run periodic independent reviews. A person with no operational role in AP should sample a set percentage of transactions each month, checking for unusual vendor edits, duplicate payments, or approval patterns that look automatic rather than genuinely reviewed.
  4. Schedule surprise reconciliations. Announced reviews get worked around. Unannounced ones catch what routine reconciliation misses.

Guidance on internal control practices is consistent on one point: documented compensating controls implemented at the highest practical level in the org chart are audit-defensible, provided they’re specific and reviewed on a regular cadence, not a one-time memo filed and forgotten.

Pro Tip: Auditors don’t expect small teams to hit textbook separation. They expect you to be able to produce, on request, exactly who reviewed what transaction and when, going back at least a full quarter.

How Technology Enforces Duty Separation in Payment Systems

Role-based access control (RBAC) is what turns a written policy into something a system actually enforces. The strongest RBAC designs group permissions by risk domain, payments, vendor management, reconciliation, rather than mapping roles loosely to job titles. A role built around “AP clerk” tends to accumulate permissions over time as people move jobs and nobody revokes the old access; a role built around a specific risk domain stays narrow by design.

Effective technical enforcement covers a few non-negotiables:

The trap most finance teams fall into is treating each system in isolation. A company might enforce perfect RBAC inside its accounting platform, then connect a separate ERP or a bank’s payment portal where the same employee holds broader rights that recreate the exact conflict the first system prevented. Cross-system access reviews aren’t optional if you run more than one platform touching payments. Quarterly reconciliation of who has access to what, across every connected system, is the only way to catch a gap that a single-platform review will always miss. Platforms that integrate approval routing and audit logging into one connected workflow close this gap more reliably than policy alone, because automated permission enforcement doesn’t depend on someone remembering to check a second system.

Your Step-by-Step Checklist for Implementing SoD

Turning policy into enforceable practice takes four phases, and skipping the mapping step is the most common reason implementations stall halfway through.

  1. Map the current state. Pull a full list of who has which permissions across every system touching payments, including manual processes like check signing. Most teams find at least one person with more combined access than they realized.
  2. Define the target state. Build your approval matrix: roles, dollar thresholds, currency and entity variations, and documented exception paths. This is the design work from the approval matrix framework above, applied to your actual org chart.
  3. Configure systems to match. Set RBAC permissions, workflow gates, and audit-trail capture inside every platform touching AP. Document compensating controls wherever full separation still isn’t feasible given headcount.
  4. Test, sample, and finalize. Run a sample of recent transactions through the new matrix to confirm it catches what it’s supposed to catch. Finalize written policy only after testing, not before, and schedule a recurring access review, quarterly at minimum, so permissions don’t quietly drift back toward conflict over time.

Mapping the procure-to-pay cycle end to end before assigning any new roles is the step most guides on implementing AP segregation of duties treat as foundational, and for good reason: you can’t fix a conflict you haven’t found yet. A brokerage moving from manual approvals to a structured payout workflow typically discovers two or three overlapping roles during this mapping step alone, before any new software gets configured.

How BrokerPay Applies These Controls to Commission Payments

Real estate brokerages face a version of this problem that’s specific to their business: commission splits, referral fees, and co-op payments routed manually or, worse, through Venmo and Zelle, where there’s no maker-checker step, no audit trail, and no RESPA-compliant record of who approved what.

Brokerpay builds the controls described throughout this guide directly into commission payment workflows:

Brokerages that map their payment initiation, approval, and reconciliation responsibilities onto a single enforced system, rather than juggling spreadsheets and personal payment apps, close the exact gap this article describes.

What the Data Actually Supports

Most advice on segregation of duties treats it as a compliance checkbox: hire more people, split the titles, file the policy. That misses the actual mechanism. SoD isn’t about headcount. It’s about whether permissions and workflow gates physically prevent one person from completing a payment alone, and a five-person AP team with airtight system enforcement beats a fifteen-person team running on shared logins and good intentions.

The conventional advice also underrates alert fatigue. Teams that flag every transaction for review end up reviewing nothing carefully, which is worse than a narrower, risk-tiered matrix that reserves real scrutiny for the payments that actually warrant it.

If you take one thing from this guide, prioritize the audit trail before the org chart. A documented, timestamped record of who approved what survives an examiner’s questions even when your team is too small for textbook separation. Fix that first, then build the roles around it.

— Wes

Get Commission Payments Off Venmo and Onto a Compliant System

Brokerpay is built for brokerages that recognize the exact gap this article describes: personal payment apps have no maker-checker step, no audit trail, and no RESPA-compliant record when an agent split or referral fee gets disputed months later.

Brokerpay

Instead of routing commission payments through Venmo, Zelle, or manual check runs, Brokerpay gives brokerages a single platform with approval workflows, role-based permissions, and a full audit trail for every agent split, referral fee, co-op payment, and cap calculation. That means the vendor controls and maker-checker structure covered above aren’t something your team has to build from scratch inside a spreadsheet; they’re already configured into how the platform routes and records every payment. If your brokerage is still approving commission payments over text message or a payment app, take a look at Brokerpay’s commission payment platform and see how the approval and audit-trail structure applies to your own office.

Sources

For deeper guidance beyond this article, the UCLA control practices guide covers compensating controls in detail, FINRA’s oversight report outlines custody-related expectations, and the University CFO division’s overview offers a clear public-sector framing of certification versus execution authority.