abstract 3D triangles

Segregation of Duties in Accounting: Controls That Prevent Fraud

One person handling AP entry, payment, and reconciliation is all it takes for fraud to go undetected for years. Here’s how to build controls that catch it early.

ON THIS PAGE
Progress

Segregation of duties in accounting is one of those controls finance leaders understand in theory but routinely underinvest in practice. The logic is simple: no single person should be able to initiate, approve, and reconcile a transaction. The reality at most small and mid-market companies is that one bookkeeper does all three — and the fraud or error that follows is often discovered years later, after the damage is done.

A roundtable conversation between Jeanine Nosker, VP of Delivery Transformation at Consero, Vinay Pai from BILL, and Brian Koref, Head of Security at Sage Intacct surfaced a set of principles that connect cybersecurity, internal controls, and fraud prevention into a single operational argument: the controls you put in place before something goes wrong are the ones that actually protect you.

The conversation ranged from ransomware and business email compromise to vendor impersonation and insider theft. What connected every scenario was the same underlying failure: someone had too much unchecked access, and no one was watching. The lessons that follow are about how to design a finance function that can catch problems before they become catastrophic, regardless of whether the threat comes from outside the firewall or inside the org chart.

The Biggest Threat to Your Finance Function Is Probably an Email

Mid-market companies are targeted because they’re accessible. The most common vector is email — a compromised inbox that gives an attacker enough context to impersonate a CFO, a vendor, or both. From there, a well-timed request to change wiring instructions or rush a payment can move money before anyone realizes what happened.

Nosker described a real situation where a client’s email was hacked and fake payment requests arrived appearing to come from the company’s CFO and VP of Marketing — timed deliberately around the holidays when fewer people were in the office to cross-check. The reason it didn’t work was due to a process control, rather than a technical one: Consero’s team recognized the request didn’t follow standard procedure, picked up the phone, and called the named parties directly. Both confirmed they hadn’t sent anything.

“We have protocols where if something is looking like it’s going outside of the standard process, you usually follow up with a phone call.” — Jeanine Nosker

Vendor impersonation follows the same pattern. An email arrives requesting an ACH or wire instruction change. The email looks legitimate because the attacker has studied the target’s inbox. The countermeasure Nosker’s team uses is to look up the vendor’s most recent paid invoice, find the phone number listed there — not from the email — and call to verify. Asking the vendor to confirm the last invoice number or payment amount establishes authenticity without tipping off a fraudster who’s watching the email thread. The phone call breaks the chain. It introduces a second channel the attacker doesn’t control.

Koref reinforced the same point from a systems angle. Every business email compromise he’d investigated had two things in common:

  • No multi-factor authentication on email
  • Reused passwords across multiple applications.

A credential harvested from one breach becomes the key to every application that shares that username and password. Enabling MFA on email is the baseline that separates companies that survive phishing attempts from those that don’t.

Segregation of Duties in Accounting Exists to Protect Against the Trusted Employee, Not the Obvious Suspect

The fraud scenarios most companies prepare for are external: hackers, phishing, ransomware. The ones that actually drain the most money from small and mid-market companies are internal, and they’re carried out by people the owner or executive team trusted implicitly.

Nosker put it plainly:

“Having the same person that’s entering the AP bill, paying the AP bill, and then reconciling the cash is just the trifecta for committing fraud and being able to cover it up.” — Jeanine Nosker

This pattern persists because small companies don’t build controls around the position — they build them around the person. A neighbor with bookkeeping experience, a longtime employee, someone the founder has known for two decades. The assumption is that trust substitutes for structure, but it doesn’t.

Controls are not an accusation. They’re the operating assumption that anyone, in the right circumstances, might take advantage of unchecked access — and the only way to prevent that is to make sure no single person has it.

The practical implication is that segregation of duties needs to be built into workflow design, not bolted on afterward. Approval routing, role-based permissions, and payment authorization thresholds aren’t bureaucratic overhead — they’re the architecture that makes fraud difficult and detection fast.

Koref described this as the “zero trust” model applied internally: verify first, then trust. Once a user is authenticated, they only have access to what their role requires. Someone who processes vendor invoices doesn’t need the ability to approve payments. Someone who approves payments doesn’t need the ability to modify vendor banking details.

  • Separate invoice entry, payment approval, and bank reconciliation across different roles.
  • Restrict vendor master file changes — including ACH and wire details — to a designated, trained team that follows a documented verification protocol.
  • Set payment approval thresholds that trigger a second approver above a defined dollar amount.
  • Review user roles and permissions on a regular schedule, not just at onboarding. When someone changes roles or leaves, update access immediately.
  • Enable audit logs on all financial systems and actually review them — the logs exist, but most companies never look at them.

Software Providers Build Security In — But Companies Have to Turn It On

Cloud-based financial software has made enterprise-grade security accessible to mid-market companies in a way that would have been cost-prohibitive ten years ago. Pai described a layered security model at BILL built around two principles:

  1. Defense in depth: no single control is the last line of defense — firewalls, encryption at rest and in transit, penetration testing, bug bounty programs, and anomaly detection all stack on top of each other so that a failure at one layer doesn’t mean total exposure.
  2. Zero trust: Authentication precedes access, every time, on every device, regardless of whether the login looks familiar.

“Instead of trust but verify, you really start off with verify and then trust.” — Vinay Pai

Koref made a point that gets lost in most security conversations: compliance and security are not the same thing. A company can pass a SOC 2 audit and still be vulnerable if it isn’t actively monitoring its environment, reviewing access, and treating security as an ongoing process rather than a checkbox. The certifications matter, but they’re a floor, not a ceiling.

The catch is that most of the security capabilities built into modern financial software are optional. Multi-factor authentication, session timeouts, role-based permissions, single sign-on, and audit log retention exist in Sage Intacct, BILL, and most enterprise-grade platforms. But the vendor doesn’t configure them for you, and they don’t review your user list when someone leaves the company. That’s the customer’s responsibility.

Koref was specific: if an employee exits and their account isn’t disabled promptly, they retain access to every application tied to that login until someone manually removes it. A single sign-on platform like Okta solves this — disable the account in one place and access disappears everywhere — but only if the company has set it up.

Pai added one counterintuitive point: the cloud is more secure than storing financial data locally. A spreadsheet sitting on a laptop is unencrypted, unmonitored, and impossible to revoke remotely if the machine is lost or stolen. A file in a properly configured cloud environment has encryption, access controls, audit history, and remote wipe capability.

Fraud Prevention Is a Process Problem Before It’s a Technology Problem

Every tool discussed— MFA, approval routing, role-based permissions, anomaly detection — is only effective if the underlying process is sound. Technology enforces controls; it doesn’t design them.

A company that has BILL but has given every staff member full administrative access has not improved its security posture. A company that has Sage Intacct but has never reviewed its user list has audit logs that no one reads. The controls have to be designed deliberately, and someone has to own the responsibility of maintaining them.

Nosker described the manual finance environment she worked in early in her career:

  • Paper approval templates attached to every bill
  • Check stock sitting in a cabinet with a stamp signature
  • Approval processes that amounted to a blank check and a rubber stamp signature

Modern financial software eliminated that particular attack surface, but it introduced new ones: email-based approval requests, electronic payment instructions, and digital vendor master files that can be changed without any physical artifact.

“You have to put those controls in place and assume that somebody is going to try to purchase things on the corporate credit card when they’re not supposed to, or write themselves a check to cover their rent for the month.” — Jeanine Nosker

The operating principle Nosker landed on is the right one: design controls as if fraud is inevitable, so that the structure catches it early when it’s attempted. A company that builds controls assuming no one would ever do that is a company that finds out years later how wrong it was. A company that designs its finance function assuming someone might is a company where fraud is difficult to commit, easy to detect, and impossible to sustain.

Outsourcing the finance function to a provider that manages many clients introduces natural separation of duties that small companies can’t achieve with a one- or two-person internal team:

  • The person entering invoices is different from the person approving payments.
  • The team handling vendor master changes is a dedicated group trained specifically in verification protocols.

Build Controls Around the Position, Not the Person — Then Let Consero Help You Hold the Line

If your finance function is running on trust instead of structure — one person managing AP entry, payment, and reconciliation; vendor changes handled without a verification step; user permissions that haven’t been reviewed since onboarding — the exposure is real and the fix is operational, not just technical.

Consero works with PE-backed and mid-market companies to build finance functions with segregation of duties, approval workflows, and controls designed to catch problems before they become losses. If you want to know where your current setup has gaps, a 30-minute conversation is a good place to start.

Recommended

You May Also Like...

Explore industry insights designed to help your business grow, streamline operations, and stay ahead in a competitive market.

Get Finance That Works by Next Quarter

Speed matters. That’s why our team gets to know your business quickly. Configures what you need. And deploys everything in roughly 90 days.
Book a Consult

🍪 Cookie Notice

We use cookies to ensure the proper functioning of our website and to enhance your user experience. By continuing to browse this site, you acknowledge and accept our use of cookies as described in our Cookie Policy.

Accept Cookies