Where AI agents fit in finance operations—and where they should stop

Finance operations contain attractive agent work: invoices arrive in inconsistent formats, reconciliations demand patient comparison and exceptions require evidence from several systems. They also contain authority that should not be casually delegated. A system that selects a supplier record, changes bank details and releases a payment has crossed several control boundaries, even if each step looks routine in isolation.

The practical opportunity is to separate evidence-intensive preparation from consequential authorisation. Let agents gather, compare and propose before they post, pay or attest. Expand only when the control evidence supports a specific additional authority.

Classify the workflow by consequence

Do not begin with a list of finance tasks that “take time.” Map what each task can change and who relies on the result.

Work type	Useful agent role	Default boundary
Invoice intake	extract fields, match records, flag inconsistencies	no supplier-master changes or payment release
Reconciliation	compare ledgers, assemble unmatched items, request evidence	no unexplained write-off or self-clearance
Close support	prepare schedules, trace balances, draft variance questions	no journal posting without approval
Expense review	test policy conditions, identify missing receipts	no final fraud or employee-conduct conclusion
Cash forecasting	assemble inputs and scenarios	no autonomous funding or investment transaction
Management reporting	draft commentary with linked evidence	no attestation or concealment of uncertainty

The OECD reports that public-finance bodies are taking a cautious approach, favoring task automation and prediction over prescriptive AI partly because of accuracy and accountability concerns (AI in public financial management). That is a useful design signal for corporate finance too: start where the agent improves evidence and attention, not where it silently becomes the accountable officer.

Preserve segregation of duties in the technical design

An approval screen does not create separation if the same agent prepared the record, chose the evidence and can trigger execution with a reusable credential. Model the roles explicitly:

• requester: creates or imports the transaction;
• preparer: assembles evidence and proposes treatment;
• approver: judges whether the treatment is acceptable;
• executor: causes the authorised state change;
• reconciler: independently checks the outcome; and
• reviewer: investigates exceptions and control performance.

Assign the agent one or more roles only where combinations are allowed. Give each role a distinct identity, permission scope and log. The GAO’s information-system controls manual treats automated processing and access controls as part of the control environment; an agent should therefore be represented as a governed system actor, not hidden behind a shared employee account.

For example, an accounts-payable agent may extract an invoice, match it to a purchase order and prepare an exception packet. It should not also create the supplier, change bank details and approve the payment. The human approval must expose the supplier, amount, account, evidence and policy exceptions—not just a green recommendation.

Make every proposal reconstructable

Finance review depends on being able to reconstruct how a number or treatment was produced. Store the inputs, source versions, transformations, policy applied, tool calls, approvals and authoritative result. If the agent drafts a variance explanation, link each claim to the ledger line or approved business evidence that supports it.

Avoid logs that record only a prompt and final paragraph. A useful record answers:

1. Which entity, period and currency was in scope?
2. Which source systems and timestamps were used?
3. What matching or accounting rule was applied?
4. What was missing, contradictory or overridden?
5. Who approved the treatment and what changed?

The NIST AI RMF calls for deployed systems to be monitored, documented and managed throughout their lifecycle, including override, incident response and change management (AI RMF Core). In finance, that lifecycle record must connect to the authoritative transaction, not sit in a detached chatbot history.

Test the exceptions that create control failures

Happy-path invoice matching proves very little. Build test cases from real control breaks and ambiguous states:

• a supplier name resembles an approved vendor but the bank account changed;
• one invoice is split below an approval threshold;
• tax treatment conflicts with the purchase order;
• a credit note arrives after a payment proposal;
• the ledger post succeeds but the agent receives a timeout;
• a currency or period is inferred incorrectly;
• supporting evidence is altered after preparation; and
• the same user asks the agent to prepare and approve.

Evaluate detection, escalation and recovery. For uncertain execution, the agent must reconcile state before retrying. For policy conflicts, it must preserve the exception rather than force a match. For threshold games, test aggregate exposure across transactions and time.

Keep judgement and attestation with accountable people

Some decisions combine accounting policy, materiality, business context and professional responsibility. An agent may retrieve precedent, model scenarios and draft a memo, but it should not present its output as the accountable conclusion. The person signing a representation, approving a material estimate or attesting to a control needs direct access to the evidence and enough time to challenge it.

This is also why a generic “human in the loop” is insufficient. Define the reviewer’s competence, independence, information and authority to reject. If the interface rewards one-click approval while hiding source details, the human role is ceremonial.

OECD work on AI in finance emphasizes clear responsibility, documentation and audit trails across the system lifecycle (regulatory approaches). Those expectations should shape operating design before model selection.

Measure controlled throughput

Count value only when quality and control hold. A finance-agent scorecard can combine:

• eligible items processed and valid straight-through preparation;
• exception precision and missed-exception rate;
• evidence completeness at first review;
• approval rework and downstream correction;
• reconciliation breaks and duplicate actions;
• time from receipt to controlled resolution; and
• incidents involving data exposure, authority or policy bypass.

Compare against a documented baseline and segment by entity, workflow and consequence. Faster processing with more downstream correction is not an improvement. Neither is a lower exception queue produced by silently accepting more uncertainty.

Expand authority one boundary at a time

Use a close-cycle exercise to see whether the design holds under time pressure. Give the agent an unmatched balance, a late adjustment, conflicting supporting documents and a request from a senior user to “just clear it.” The correct result is not necessarily a completed reconciliation. It may be an evidence packet that isolates the difference, preserves the open item and routes the accounting judgement to the responsible owner.

Review the exercise with finance, control, security and system owners. Ask whether the agent’s proposal made the decision easier to inspect, whether permissions matched policy and whether the authoritative ledger remained the source of truth. A workflow that works only when data is clean and deadlines are distant is not ready for finance operations.

A sensible progression is read-only retrieval, structured preparation, recommendation, approval-gated action and only then narrowly bounded autonomous action. At each stage, define a stop condition, a safe fallback and an owner who can reduce permissions immediately.

Finance agents fit where they make evidence easier to assemble, exceptions easier to see and decisions easier to review. They should stop where the organisation can no longer tell whether preparation, authorisation and accountability remain genuinely separate. That line is not anti-automation. It is what makes responsible automation scalable.