How should organizations separate approval and execution in accounts payable workflows?

Why This Matters for Security Teams

Accounts payable is one of the easiest places for control failure to look “normal.” When the same person can create a vendor, approve a payment, and release funds, separation of duties becomes a policy statement instead of an enforced control. NIST’s NIST Cybersecurity Framework 2.0 treats governance and access control as operational disciplines, not paperwork, and the same principle applies here: approval must be technically separated from execution.

The practical risk is that payment workflows often span ERP, banking portals, shared inboxes, and exception handling. Each handoff creates a bypass path if roles are not enforced consistently. NHI Management Group’s Ultimate Guide to NHIs shows how often access control breaks down when privileges are broad, stale, or poorly observed, which is directly relevant to payment automation and delegated authority. In accounts payable, the control objective is not just approval integrity, but also preventing hidden execution rights from accumulating behind the scenes. In practice, many finance teams discover the weakness only after a duplicate payment, an insider misuse case, or an audit finding has already exposed the gap.

How It Works in Practice

Effective separation starts by designing the payment flow so that approval and release are technically different actions with different identities, different permissions, and different logs. The approver can validate the business justification, but cannot trigger settlement. The executor can release the payment only after the workflow engine confirms the approval state. This is a workflow control issue first, and an identity issue second.

Strong implementations usually combine four elements:

• Role separation in the ERP or AP platform, so request, approve, and pay functions are distinct.
• Step-up approval for high-risk payments, such as new vendors, rushed disbursements, or bank-detail changes.
• Restricted execution rights for payment release, ideally tied to a separate person, service account, or signing process.
• Immutable audit logs that capture who approved, who executed, what changed, and which exception path was used.

Current guidance suggests that approval should be evaluated in context, not only by title. For example, a supervisor may approve a legitimate invoice, but should not also have delegated access to the payment queue or the banking token used to release funds. This is where NHI discipline matters: privileged automation, API keys, and service accounts should be treated as execution identities with tightly scoped access and short lifetimes. The operational lesson from Ultimate Guide to NHIs is that over-privileged identities are often the hidden route around intended controls, especially when finance teams rely on shared credentials or manual workarounds. The control boundary has to exist in the system of record, not only in policy documents or training materials. These controls tend to break down when payment teams use manual release steps in a separate banking portal because the approval state and the execution action are no longer enforced in the same control plane.

Common Variations and Edge Cases

Tighter separation often increases operational friction, requiring organizations to balance fraud resistance against payment speed and staffing constraints. That tradeoff becomes more visible at month-end, during urgent vendor payments, or in small finance teams where one person may cover multiple tasks. Best practice is evolving, but there is no universal standard for this yet: some organizations use compensating controls, while others require dual control only above a threshold.

Common edge cases include emergency payments, cross-border treasury operations, and outsourced AP processing. In those situations, approval and execution can still be separated by using independent sign-off, temporary JIT access, or a second control owner who is not involved in the transaction. The important point is that temporary exception handling must expire automatically and be fully logged. NHI Mgmt Group’s research shows how often long-lived access and weak offboarding create lasting exposure; the same pattern appears in finance when emergency access becomes permanent. For broader control design, Ultimate Guide to NHIs is useful for understanding how privileged access should be scoped, reviewed, and revoked, while NIST Cybersecurity Framework 2.0 helps frame the governance and monitoring obligations behind the workflow. The hardest cases are hybrid approval models with email overrides and bank-side release permissions, because the control can be bypassed outside the AP system itself.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities alongside human accounts?
• How should organizations prioritize environments for NHI management?
• How can organizations prevent NHI-related breaches?