Segregation of duties in accounts receivable and revenue control

At a glance

What this is: This is an analysis of how segregation of duties in accounts receivable limits fraud and misstatement by separating credit approval, billing, collections, and reconciliation.

Why it matters: It matters to IAM and governance teams because the same control logic used to prevent privilege concentration in finance also underpins NHI, autonomous, and human access separation.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read SecurEnds' guidance on segregation of duties in accounts receivable

Context

Segregation of duties in accounts receivable is a classic control problem: when one person can approve credit, create invoices, collect cash, and reconcile accounts, errors and fraud become much easier to hide. In identity programmes, the same concentration problem appears whenever one identity, role, or process owns too much of the lifecycle.

The lesson for IAM teams is not finance-specific. Whether the subject is a finance clerk, a service account, or an autonomous workflow, governance fails when creation, use, and verification collapse into one path. Controls work best when the actor that initiates an action is not the same actor that can confirm the outcome.

For non-human identities, this is the same logic that drives lifecycle separation, access reviews, and offboarding discipline. If a single credential can both perform and validate work, oversight becomes ceremonial rather than preventative.

Key questions

Q: How should organisations implement segregation of duties in accounts receivable?

A: Start by separating credit approval, invoicing, collections, and reconciliation into different roles or accounts. Then enforce that separation with system permissions, exception approvals, and regular access reviews. The goal is to prevent any one person from creating, receiving, and confirming the same transaction end to end.

Q: Why does role overlap create fraud risk in accounts receivable?

A: Role overlap removes independent verification. When one identity can issue invoices and reconcile them, it can hide errors, misstate revenue, or divert payments without a meaningful challenge path. Fraud becomes easier because the actor can both perform the action and close the record.

Q: How do organisations know if AR segregation of duties is actually working?

A: Look for evidence that no single user can approve credit, create invoices, collect cash, and reconcile accounts. Effective SoD also leaves a clear audit trail and regularly flags entitlement conflicts. If exceptions are common or reviews are skipped, the control is only partial.

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

A: 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.

Technical breakdown

How segregation of duties works in the AR control chain

Segregation of duties in accounts receivable divides the revenue cycle into separate control points. Credit approval sets customer risk and terms, billing creates the invoice, collections receives the payment, and reconciliation verifies that the ledger matches reality. The control is effective because each step depends on evidence produced by a different role, which makes concealment harder and review more meaningful. In IAM terms, this is a separation between authorise, execute, and verify functions. When those functions converge in one identity, the control collapses into self-approval.

Practical implication: define distinct permissions for approval, creation, receipt, and reconciliation so no single account can complete the full cycle.

Why role overlap hides fraud and revenue misstatement

Role overlap is dangerous because it removes the independent checkpoint that exposes anomalies. A user who can both issue invoices and reconcile them can inflate revenue or bury a misapplied payment without leaving a meaningful challenge path. The same pattern appears in identity governance when an account can provision access and then certify that access later. In both cases, the audit trail exists, but the reviewer is not independent enough to challenge the action. That is why SoD is less about job titles and more about preventing self-justifying control loops.

Practical implication: map conflicting permissions to prevent any identity from both creating transactions and closing the review loop.

Dual authorisation and audit trails as compensating controls

When headcount is small, organisations often rely on compensating controls such as dual approval, independent review, and event logging. These do not replace segregation of duties, but they reduce the chance that one person can act without challenge. Audit trails are only useful if they are reviewed by someone who did not perform the original action. The same pattern matters in NHI governance, where logs without lifecycle control merely document exposure instead of preventing it. Controls must be designed so evidence is checkable by a separate owner.

Practical implication: use dual approval for high-risk transactions and require independent review of exception logs and reconciliation reports.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Privilege concentration is the real governance failure behind weak AR controls. The article describes a finance control, but the identity lesson is broader: one actor should not be able to initiate, execute, and verify the same business outcome. That same concentration problem is what breaks NHI governance when a service account, API key, or workflow identity is allowed to both act and validate its own activity. Practitioners should recognise this as a control-design problem, not just an operating issue.

Segregation of duties in AR mirrors least privilege in identity programmes, but the enforcement model is different. Least privilege limits what an identity can do; segregation of duties limits which identities can complete adjacent steps in a sensitive process. That distinction matters because excessive overlap can exist even when each individual permission looks harmless in isolation. The practitioner conclusion is to review workflows as chains, not as isolated entitlements.

AR SoD exposes a named concept we see repeatedly across identity governance: control-chain independence. A process is only trustworthy when the person or system that performs an action cannot also complete the verification path alone. That principle applies to financial operations, human access reviews, and NHI lifecycle management alike. If the same account can create the record and certify the record, the control has not really separated duties.

Automation strengthens SoD only when it preserves separation, not when it centralises power. The article’s automation angle is useful because tooling can enforce approval routing and logging, but automated enforcement still fails if one administrator can override every checkpoint. That is the same failure mode identity teams face when governance tools are deployed without clear delegation boundaries. The practitioner conclusion is to automate enforcement while keeping approval, execution, and review under different owners.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• A separate NHIMG finding shows that only 5.7% of organisations have full visibility into their service accounts, which is why ownership separation must be paired with discovery.
• For a broader control model, see the NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding stay independent over time.

What this signals

Control-chain independence: the finance pattern in AR is the same governance problem identity teams face when one actor can create, execute, and verify its own work. As access programmes move deeper into automation, separation of duties has to be designed into the workflow, not just assigned by job title.

The practical signal is that review cadence alone is not enough. If approvals, execution, and reconciliation converge in one system path, the control becomes a record-keeping exercise rather than a preventative barrier, which is why lifecycle oversight and entitlement review should be designed together.

For practitioners

• Split AR permissions by control step Assign credit approval, invoice creation, payment collection, and reconciliation to different roles, and remove any shared access that lets one person complete the full cycle.
• Introduce independent review for exceptions Require a second person to approve large write-offs, unusual credit terms, and manual payment adjustments so exceptions cannot be self-authorised.
• Use access reviews to find role overlap Review ERP and finance system entitlements for conflicting combinations, then remove overlaps that let the same identity create and verify transactions.
• Automate evidence collection for auditors Retain logs that show who approved, who issued, who collected, and who reconciled so SoD can be proven during audit without manual reconstruction.

Key takeaways

• Accounts receivable segregation of duties reduces fraud by preventing one person from controlling credit, billing, collections, and reconciliation at the same time.
• The evidence problem is independence, not visibility alone. A control that can be self-approved is not a control that can be trusted.
• Identity teams can borrow the AR lesson directly: separate action, approval, and verification across human and non-human actors.

Key terms

• Segregation of Duties: Segregation of duties is a control design that splits sensitive work across different people or systems so no single actor can create, approve, execute, and verify the same outcome. In identity programmes, it protects against self-approval, hidden errors, and concentrated privilege.
• Control-chain Independence: Control-chain independence means the actor that starts a process cannot also be the only actor that completes or certifies it. This matters in finance, IAM, and NHI governance because a workflow is only reliable when each critical stage has a separate checkpoint and a separate owner.
• Compensating Control: A compensating control is an alternative safeguard used when a primary control cannot be fully implemented. It may include dual approval, supervisor review, or independent logging, but it should reduce risk rather than merely document it.
• Access Review: An access review is a periodic check of who can do what inside a system and whether those permissions still make sense. For non-human identities, the review must look for role overlap, stale access, and workflows that let one identity both act and validate its own work.

Deepen your knowledge

Segregation of duties and lifecycle separation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is translating finance-style control separation into identity governance, it is worth exploring.

This post draws on content published by SecurEnds: Segregation of duties in accounts receivable and revenue control. Read the original.