Why does role overlap create fraud risk in accounts receivable?

Why This Matters for Security Teams

Role overlap in accounts receivable is not just an accounting control gap. It is an identity and authorization problem that removes independent verification from a process where money, customer trust, and revenue recognition all depend on clean separation of duties. When a single user or service account can create invoices, adjust customer records, apply credits, and reconcile receipts, the same identity can both introduce and conceal irregularities. That is the condition fraudsters need. Current guidance from the NIST Cybersecurity Framework 2.0 still points to access control, accountability, and continuous monitoring as core protections, but in practice those controls only work when roles are narrowly scoped and independently reviewable. NHIMG research shows the scale of the wider identity problem: in the Ultimate Guide to NHIs — Why NHI Security Matters Now, 90% of IT leaders said properly managing NHIs is essential for zero trust, which is a useful reminder that access boundaries matter even when the workload is not human. In finance, the same principle applies to accounts receivable. In practice, many organisations discover role overlap only after a reconciliation exception, customer dispute, or audit finding has already exposed it, rather than through intentional segregation reviews.

How It Works in Practice

The fraud risk comes from collapsing three separate functions into one trust path: create, record, and verify. A healthy accounts receivable workflow should make it hard for the same identity to originate a transaction and then approve or reconcile it. If role design allows overlap, a user can issue a fake invoice, post a credit memo to hide a shortfall, or mark a payment as applied without a second set of eyes catching it. That is why separation of duties is a control objective, not a paperwork exercise. A practical control design usually combines identity governance with process design:

• Restrict invoice creation, credit approval, cash application, and ledger reconciliation to distinct roles.
• Require independent review for write-offs, manual adjustments, and customer master-data changes.
• Use role-based access control for baseline entitlements, then review exceptions through periodic access certification.
• Monitor for unusual combinations, such as the same identity opening, editing, and closing the same record.
• Preserve immutable logs so finance and security teams can reconstruct who changed what and when.

This is where NHI governance is relevant too. The Top 10 NHI Issues and the broader Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same operational truth: when identities accumulate privileges without clear ownership, auditability weakens and abuse becomes easier to hide. That applies to service accounts that post receipts, automation that updates ERP records, and human users with excessive exceptions. These controls tend to break down when ERP customisation, shared service accounts, or manual journal workflows are embedded deeply enough that finance teams treat them as exceptions rather than access-risk hotspots.

Common Variations and Edge Cases

Tighter segregation often increases operational overhead, requiring organisations to balance fraud reduction against processing speed and close-cycle pressure. That tradeoff is real, especially in smaller finance teams where one person may legitimately touch multiple steps during month-end close. The key is not to eliminate every overlap, but to make overlapping access rare, approved, time-bound, and visible. Best practice is evolving for mixed human and automated workflows. For example, an RPA bot may generate invoices at scale, but it should not also own reconciliation or exception approval. The same rule applies to API-driven billing integrations: a system account may create records, but a different identity should validate and post them. There is no universal standard for this yet, but current guidance suggests treating automation like any other privileged actor and reviewing its end-to-end authority chain. Two edge cases deserve special attention:

• Shared mailbox or shared portal access, where the real actor is difficult to attribute.
• Emergency access or temporary delegation, where short-lived exceptions can become permanent if governance is weak.

NIST CSF 2.0 is helpful here because it encourages ongoing risk management rather than one-time control design. In practice, role overlap becomes a fraud issue fastest when manual overrides, shared credentials, and weak audit trails converge in the same receivables process.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?