How do you know if an AP SoD matrix is actually working?

Why This Matters for Security Teams

An AP segregation-of-duties matrix is only useful if it reflects how the accounts payable process actually behaves inside the ERP and supporting tools. A clean spreadsheet can still coexist with risky access if approvers, preparers, and posting users can bypass controls through overrides, shared accounts, or indirect paths. NIST’s NIST Cybersecurity Framework 2.0 treats control effectiveness as an operational outcome, not a documentation exercise.

That matters because SoD failures usually surface in payment runs, vendor master changes, or emergency access after the process has already been abused. The matrix should therefore be tested against transaction reality, not just policy intent. NHI Management Group’s Ultimate Guide to NHIs shows why this evidence-first approach matters more broadly: only 5.7% of organisations have full visibility into their service accounts, which is a reminder that “documented access” often diverges from actual access.

In practice, many security teams discover SoD drift only after an audit finding, a fraud review, or an access incident has already exposed the gap.

How It Works in Practice

A working AP sod matrix ties job functions to the exact permissions enforced in the finance system, then proves that conflicting duties cannot be combined without a controlled exception. That means mapping the matrix to ERP roles, workflow approvals, privileged access paths, and any service accounts or integrations that can post, approve, or modify vendor records. The control is strongest when reviewers can test whether one identity can both create and approve, or change bank details and trigger payment.

Operational validation usually includes role mining, transaction testing, and exception review. The matrix should be compared against actual entitlements in the system, not just HR titles or policy text. For identity governance teams, the operational question is simple: can the user or account perform a prohibited combination in the live environment? If the answer is yes, the control is not working, even if the matrix looks correct on paper.

Practical evidence includes:

• ERP role extracts showing granted permissions, not just assigned roles
• Logs proving whether restricted combinations were attempted or blocked
• Exception tickets showing who approved temporary access and why
• Periodic recertification that validates both human and non-human access paths

Current guidance suggests treating emergency access, delegated approvals, and bot accounts as part of the same SoD test because those paths often bypass the intended control design. Where a process depends on manual compensating checks, the matrix may look compliant while the operational risk remains unchanged. NHI Management Group’s Ultimate Guide to NHIs is especially relevant here because long-lived identities and excessive privileges are common failure points in real environments. These controls tend to break down when the ERP allows indirect posting through integrations or shared service accounts because the matrix rarely models those pathways accurately.

Common Variations and Edge Cases

Tighter SoD enforcement often increases business friction, requiring organisations to balance fraud reduction against operational speed and month-end deadlines. That tradeoff is real, especially in smaller finance teams where the same person may need temporary access across multiple functions. Best practice is evolving, but the usual answer is not to weaken the matrix; it is to make exceptions explicit, time-bound, and reviewable.

There are a few common edge cases. First, organisations sometimes rely on compensating controls such as post-transaction review, but those only work if reviewers are independent and actually examine the risky transactions. Second, outsourced AP operations can obscure who really holds the privileges, so the matrix must include vendors and managed-service access. Third, systems that are not integrated with the ERP may still enable SoD violations through spreadsheets, email approvals, or RPA workflows.

For broader governance context, the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both reinforce the same operational principle: control design is not proof of control operation. The matrix should be considered healthy only when exceptions are rare, documented, and closed promptly, with evidence that no user or account can quietly accumulate conflicting access over time.

Related resources from NHI Mgmt Group

• How do you know if remote work security controls are actually working?
• How do you know if Oracle SoD evidence is actually working?
• How do you know if FIDO passwordless is actually reducing risk?
• How do organisations know if cloud identity enablement is actually working?