At a glance
- A finance agent needs a different answer for every action, not one blanket approval rule: reading the ledger, drafting an entry, and releasing a payment carry different risk and need different gates.
- Nine named actions, each with an agent permission level (none, suggest, do with approval, do and log), a named approver role, a segregation-of-duties note, and the evidence to keep, in one role and action matrix.
- Segregation of duties applies to an agent the same way it applies to a new hire: the role that proposes or executes a transaction is never the role that approves it.
- This article covers finance actions and who approves them; it doesn't cover how an agent's technical credentials or API scopes are configured.
Why finance needs action-level gates
General AI-governance guidance addresses, in the abstract, which decisions need a human in the loop. Finance needs a finer grain: a ledger read, a draft entry, and a payment release carry different risk.
An approval gate is a control point: a specific action, by a specific agent, that a named person clears before it takes effect. This article uses four permission levels:
- None — the agent may not perform or suggest the action.
- Suggest — the agent may draft or recommend it, but a named person decides whether and how it's entered or acted on.
- Do with approval — the agent prepares the action and executes it only after a named approver signs off.
- Do and log — the agent may complete it without a per-instance approval, because it's low-risk and reversible, and every instance is logged.
Nothing here needs a new, AI-specific control: COSO's internal-control framework treats this kind of gate as ordinary control-activity design. Control activities "may encompass a range of manual and automated activities such as authorizations and approvals, verifications, reconciliations, and business performance reviews," and "segregation of duties is typically built into the selection and development of control activities"[1]. An agent is one more actor whose access needs that discipline, not an exception to it.
The role and action matrix
The table below sets a default gate for nine finance actions an agent might touch, as a starting point to adapt to your own policy and approval chain.
| Action | Agent permission | Approver role | Segregation-of-duties note | Evidence kept |
|---|---|---|---|---|
| Read the ledger | Do and log | None per instance; access owner reviews periodically | Read access can't create or approve a transaction; scope still follows least privilege | Query log: account, date range, requester, timestamp |
| Draft a journal entry | Suggest | Preparer (the accountant who owns the account) | The agent proposes; a named preparer accepts, edits, or rejects it before it exists in the ledger | Draft text and amount, source data cited, preparer's decision |
| Post a journal entry | Do with approval | Reviewer or controller, distinct from the preparer | The preparer who accepted the draft never approves its posting; the agent posts only after the reviewer signs off | Entry detail, approver identity and timestamp, link to the draft |
| Match transactions | Do and log | None within tolerance; a preparer for exceptions | Tolerances are set in advance by the controller; the agent applies them, it doesn't set them | Rule applied, items matched, exceptions routed |
| Clear a reconciliation break | Do with approval | Account owner or controller | The agent proposes and applies the resolution only after the account owner or controller approves; it never approves its own resolution | Proposed resolution, supporting transactions, approver sign-off |
| Change vendor bank details | None | AP manager, plus an out-of-band verification step | No automated path: a changed payee account redirects every later payment, so it gets the matrix's strictest gate; the person who requests the change never approves it | Change request, requester, verification method, approver, date |
| Release a payment | Do with approval | Named approver by policy threshold; a second above a higher threshold | The preparer never approves or authorizes its release; the agent executes the payment only after the named approver authorizes it; above the higher threshold, both approvers are independent of the preparer and of each other | Batch detail, approver chain, threshold applied |
| Send external communication | Suggest | Named business owner | The agent that drafts a message is not the one who authorizes sending it; a named business owner decides whether and how it's sent | Draft, approver, final sent copy, recipient |
| Change a threshold | None | Controller or CFO, under change control | The system operating under a threshold must not be the one that can change it; the person who requests a threshold change never approves it | Prior value, new value, requester, approver, effective date |
Segregation of duties when an agent is one of the actors
In this article, segregation of duties means a simple working rule: the role that proposes or executes a transaction is never the role that approves it. An agent doesn't retire that principle; it adds a new kind of actor who can hold one of those roles.
COSO's control-environment principles support giving the agent's role a defined authority: "management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities," and "the organization holds individuals accountable for their internal control responsibilities"[1]. The agent's role needs a defined authority; a named person stays accountable for the outcome, even when the agent proposed it.
- Give the agent's role its own name in the approval workflow, distinct from any human user it acts for, rather than hiding it inside someone else's login.
- Never let the same agent role both propose and approve the same transaction type, even if a person could technically click through both steps.
- Where an agent's output feeds a downstream review, that review is performed by a role that didn't produce the output being reviewed.
Designing approvals people actually read
An approval gate only works if the approver actually reads it. Too little context gets rubber-stamped; too much gets skimmed the same way. The design question is what an approver needs to see to decide, in the time they have.
- Name the vendor, invoice, and amount in plain language
Not a system code or batch reference alone — the specific payee, document, and amount.
- Show the source data the agent used
The invoice, contract, or bank confirmation the proposal rests on, linked, not described.
- State why the agent proposed it
The rule or pattern it matched, so the approver isn't reconstructing the reasoning from scratch.
- Flag anomalies instead of hiding them
A new payee, a round amount, a repeat submission — surface what's unusual rather than presenting it identically to routine cases.
- Show who else has touched it
The preparer, any prior approvals, and whether this is a resubmission.
- Make accept and reject equally easy, with a reason required on reject
A reject with no reason recorded teaches nothing about why the gate caught something.
NIST's AI RMF describes defining who does what when people and AI share a task: "policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems."[2] We recommend using that role split to route only what needs a decision to a person: "do and log" actions, like matching within tolerance, shouldn't also demand a signature, so approval attention stays on "suggest" and "do with approval" actions.
Evidence for audit
The matrix's last column names what to keep for each action, but the pattern is the same everywhere: what the agent proposed, what it was based on, who decided, and when. NIST's AI RMF places override and change-management mechanisms inside post-deployment monitoring plans: "post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management."[3]
- Actor identity: which agent, version, or configuration proposed the action, not just "the system."
- Input: the specific records, documents, or data the proposal relied on.
- Decision: who approved, rejected, or edited it, and when.
- Outcome: what actually happened in the system of record, linked back to the proposal and decision.
NIST's AI RMF describes errors as tracked and documented: "incidents and errors are communicated to relevant AI actors including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented."[3] We recommend keeping errors in that same record, not a separate one kept only when something goes wrong. A near-miss belongs there too: it's evidence the control works.
Duplicate execution is a preventable version of this problem: an agent or a person resubmits the same invoice, payment, or entry, and it posts twice. We recommend the same three checks regardless of system: give every proposed action a unique reference tied to its source document, check new proposals against that reference before they queue for approval, and reconcile what posted against what was approved on a fixed schedule.
Changing the matrix safely
Changing the matrix needs the same discipline as any other control. Loosening a gate — moving an action from "do with approval" to "do and log" — is a policy decision that should go through the approval chain governing the action.
- Version every change: prior setting, new setting, requester, approver, and effective date.
- Test a loosened gate against past cases: would it have let through anything the old gate correctly caught?
- Review the matrix on a fixed schedule, not only after an incident, since volumes and vendors change over time.
COSO's framework treats this as ordinary policy deployment: "the organization deploys control activities through policies that establish what is expected and procedures that put policies into action."[1] A matrix without a dated policy behind each row is a diagram, not a control.
Outstanding approval requests should expire too: a request left unactioned for days risks being decided against stale context, so treat an expired one as void rather than let it stand.
When this doesn't apply
- This matrix assumes the agent's proposals are already traceable to source data; if your systems can't do that today, fix that first.
- It covers finance actions and approvers, not the agent's credentials, API scopes, or data access — a separate exercise for IT security.
- A workflow with genuinely no repeat volume may not need a standing matrix; a single documented sign-off can be simpler.
Frequently asked questions
When should an agent need human approval in finance?
When the action is hard to reverse, moves money, or feeds an external communication. Reading data or matching within tolerance needs no per-instance approval; drafting an entry, clearing a break, and releasing a payment route to a named approver. Vendor bank details and thresholds are different: the agent never touches either one; people change them under change control.
What approval thresholds for agent payments?
Set thresholds the same way you would for any preparer: an amount above which a second approver is required, tied to your existing payment-approval policy rather than a new AI-specific scale. The agent's proposal doesn't change who needs to sign off at a given amount; it changes who's making the proposal.
How do approvals fit segregation of duties?
In this article, segregation of duties means the role that proposes or executes a transaction is never the role that approves it. The agent's role on a transaction is one role: it proposes and, once approved, executes — never the approver. That's the same rule applied to a new employee, whether the actor is a person or an agent.
What should an approver see?
The action and amount in plain terms, the source data the agent used, why it proposed this action, any anomaly flags, who else already touched the transaction, and an equally easy accept or reject, with a reason required on reject.
Should approvals expire?
Yes. An approval request left unactioned for days risks being decided against stale context — payment details, vendor status, or a threshold may have moved on. Set an expiration tied to your control cycle, and treat an expired request as void so the agent re-proposes it against current data instead of an approver clicking through an old screen.
How do you prevent duplicate execution?
Give every proposed action a unique reference tied to its source document, check new proposals against that reference before they queue for approval, and reconcile what actually posted against what was approved on a fixed schedule. We recommend applying this same discipline to an agent's proposals, not only to human-entered ones.
Related reading
- Our AI agent implementation service covers how a system like this is scoped, tested, and handed over, including where approval gates get built and tested before go-live.
- For the broader principle behind a human in the loop, see human-in-the-loop AI governance; this article narrows that to nine named finance actions and their approvers.
- Our financial reconciliation automation page covers the matching and exception workflow behind the "match transactions" and "clear a reconciliation break" rows.
- The close a posted journal entry feeds is covered in financial close automation, including the controller sign-off.
- Our article on AI financial close automation discusses that close workflow at more length.
- Not sure which workflows are ready for this? The 360° AI Blueprint ranks automation candidates by risk and readiness first.
Sources
- [1] — COSO, "Internal Control — Integrated Framework: Executive Summary" (2013-05-14), "Control Activities" and "Components and Principles" sections (accessed 2026-09-29)
- [2] — NIST AI RMF Playbook, "Govern" (GOVERN 3.2) (accessed 2026-09-29)
- [3] — NIST AI RMF Playbook, "Manage" (MANAGE 4.1, 4.3) (accessed 2026-09-29)
More in Agent governance
Build vs. Buy AI E-Commerce Back Office Automation: Point Tools vs. an AI Implementation Partner
Build vs buy AI e-commerce back office automation: a six-factor decision table comparing packaged tools with an AI-agent layer, plus how to scope one workflow.
Ecommerce OperationsBuild vs. Buy AI for the Energy and Utilities Back Office: AI Agents vs. Entrenched Land, JIB and Billing Software
Build vs buy AI for the energy and utilities back office: a five-factor decision table comparing land, JIB and billing software with an AI-agent layer.
Utilities and Energy CompaniesHow to Monitor AI Agents in Production When You Don't Have an ML Team
How to monitor AI agents in production without an ML team: a weekly review with nine signals, owners, cadences, and thresholds, plus a dashboard spec.