Who is accountable when segregation of duties fails in accounts receivable?

Accountability usually sits with the process owner and the control owner, not just the person who exploited the overlap. Finance leadership must define the roles, and internal control or audit teams must verify that the separation is real in the system, not only on paper.

Why This Matters for Security Teams

segregation of duties in accounts receivable is not just an accounting preference; it is a control that prevents one person or one workflow from creating, approving, reconciling, and writing off the same transaction path. When that separation collapses, the issue is usually not limited to a single bad actor. It becomes a governance failure that exposes finance leadership, process ownership, and system control design. NIST’s NIST Cybersecurity Framework 2.0 frames this as an accountability and control-design problem, not only a user-behaviour issue.

For NHI and agentic environments, the same logic applies when service accounts, workflows, or AI-driven automations can move through multiple financial steps without a hard separation of authority. NHIMG research on the DeepSeek breach shows how quickly exposed credentials and overbroad access can turn a technical gap into operational exposure. In practice, many security teams encounter SoD failures only after an exception, write-off, or reconciliation dispute has already been processed without independent review.

How It Works in Practice

Accountability should be assigned on three levels: the business process owner, the control owner, and the system owner. The process owner defines what duties must remain separate. The control owner ensures the control is designed and operating effectively. The system owner configures the ERP, billing, and workflow tools so a single identity cannot complete conflicting steps without detection or approval. That distinction matters because a control that exists only in policy language is not enforceable.

In practice, teams should verify segregation in the system path, not just in job descriptions. That includes role mapping, approval routing, exception handling, audit logs, and periodic testing of whether a user can both create and approve credits, adjust invoices, or post write-offs. The NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations toward clear ownership, control monitoring, and continuous validation.

For broader NHI hygiene, the same principle shows up in secret handling and identity sprawl. NHIMG’s The State of Secrets in AppSec highlights how fragmented secrets management weakens central control, which is a close analogue to SoD failure in finance systems. A practical AR control stack usually includes:

• Separate roles for invoice creation, cash application, approval, and write-off
• JIT elevation only for rare exception handling
• Periodic access recertification tied to actual transaction capability
• Automated detection for conflicting permissions and conflicting workflow ownership

These controls tend to break down when shared service teams, emergency overrides, or manual spreadsheet workarounds bypass the ERP workflow because the system no longer enforces the intended separation.

Common Variations and Edge Cases

Tighter segregation often increases operational overhead, requiring organisations to balance fraud prevention against month-end speed and staffing constraints. That tradeoff is real, especially in small finance teams where the same people handle collections, posting, and reconciliation. Current guidance suggests compensating controls can be acceptable, but there is no universal standard for this yet, and they should not be treated as equivalent to true separation.

Edge cases usually appear in shared service centers, outsourced AR processing, and systems with emergency access or temporary backfills. In those environments, accountability becomes sharper, not weaker: leadership must document who approved the exception, who monitored it, and how the conflict was remediated afterward. The DeepSeek breach is a reminder that once privileged access is too broad or too exposed, the organisation is accountable for the control failure even if the original misuse came from an external actor.

For audit, the key question is not only who clicked the button, but who allowed the same identity to have the ability in the first place. That is why finance leadership, internal control, and audit all share accountability for making segregation real in the application, not just documented in policy.

Related resources from NHI Mgmt Group

• Who is accountable when segregation of duties fails in regulated systems?
• Who is accountable when layered security fails but identity trust was never rechecked?
• Why do segregation of duties conflicts still happen in mature IAM programmes?
• How should security teams build a segregation of duties matrix that reflects real access?