How can finance teams tell whether AR SoD is actually working?

How to tell if SoD is working in practice

Segregation of duties is working only when the control survives contact with live access data. That means the role model, the actual entitlements, and the business process evidence all agree. If finance can show who posts, who approves, who reconciles, and who can override, the control is doing real work. If those lines blur, SoD exists mostly on paper.

A useful test is whether the control still holds after routine exceptions, temporary access, and role changes. Mature finance teams do not rely on a policy statement alone, they verify that the configured access model prevents toxic combinations or forces compensating review where a split is not technically possible. The gap to watch is not just access creation, but whether removal and recertification actually close the loop.

SoD is also a control over evidence quality, not just permissions. If reconciliation logs, approval trails, and exception records can be tied back to specific users and transactions without manual reconstruction, the team can demonstrate enforcement instead of describing intent. For finance workflows, that evidence needs to be repeatable enough for audit, but operational enough that teams can use it before a control failure becomes a finding.

Where SoD breaks down in finance operations

The common failure mode is stale design: the ruleset says one thing, while production access says another. That often happens after emergency access, chart-of-accounts changes, acquisition-driven role redesign, or a half-finished recertification cycle. When the business keeps moving and the control model does not, SoD becomes a documentation exercise rather than a living boundary.

Another break point is exception handling. If the same manager who grants an exception also verifies the activity it enables, the second control is not independent. That is especially risky in posting, payment, vendor master, journal entry, and reconciliation processes because one user can create, approve, and conceal the same action. Teams should treat recurring exceptions as evidence that the control design, not just the exception, needs review.

For a broader control model and examples of how toxic combinations are treated, the Segregation of Duties (SoD) Guide is useful because it frames SoD as a ruleset, a monitoring problem, and an access-governance problem, not just an audit checklist.

What proof finance should require before calling SoD effective

Finance teams should ask for three forms of proof: a role matrix that matches actual entitlements, independent reconciliation or review evidence, and exception records that show second-party review. The question is not whether these documents exist, but whether they point to the same control reality. If they do not, the team should assume the control is partially implemented and may fail under pressure.

The strongest proof comes from sampling live users and live transactions together. If a sample shows no person can both post and verify the same activity, and that conflicting access is removed when recertification runs, the control is behaving as intended. If the sample repeatedly finds access drift, orphaned exceptions, or reviewers with the same permissions they are meant to oversee, the issue is structural rather than isolated.

That is why independent testing matters as much as design. A control that only works when someone manually remembers to apply it is fragile; a control that is enforced by role design, review workflow, and periodic validation can be trusted. For finance leaders, the practical benchmark is simple: can you prove the control without assembling the story by hand?

Practitioner Guidance

What to verify: Test SoD against current production entitlements, not policy diagrams. Verify that conflicts are blocked in role design, not merely flagged after the fact, and check whether temporary access expires without leaving residual conflict.

What to measure: Track the share of conflicting access removed during recertification, the number of exceptions that require second-review approval, and the number of finance processes where posting and verification are still combined in one account or role.

Decision rule: If the control can be bypassed by exception, emergency access, or a reviewer with the same power as the actor, treat SoD as a governance gap and not a passing control.

Practitioner takeaway: SoD is working only when the control is enforced by current access, independent evidence, and enforced remediation, not when the right words appear in the policy library.

Related resources from NHI Mgmt Group

• How can teams tell whether front-channel logout is actually working across applications?
• How can teams tell whether data classification is actually working?
• How can teams tell whether access governance is actually working?
• How can IAM teams tell whether passkey adoption is actually working?