AI agents in finance attract ambitious briefs: close the books, monitor every market signal, answer management questions and resolve exceptions automatically. A useful first deployment is usually much smaller. It takes responsibility for one repeatable piece of work, produces an output somebody can judge and stops before an uncertain result becomes a consequential action.
Choosing that workflow is more important than choosing a model. A capable model cannot repair unavailable source data, an undefined approval process or a task whose correct answer exists only in one person’s head. This guide gives finance and engineering teams a practical way to compare candidates before committing to a build.
You can apply the framework as you read, or use the finance agent readiness assessment to score one workflow and receive a pilot checklist.
Start with the work, not the word “agent”
Write the proposed job as a trigger, an output and a stopping point. “Build a finance agent” is not a job. These are:
- When a new supplier invoice arrives, compare it with the purchase order and receipt, then prepare exceptions for an accounts-payable reviewer.
- When a company in the coverage list publishes a filing, collect the approved sources and prepare a cited change note for an analyst.
- Each morning, find unreconciled transactions, gather likely supporting records and place proposed matches in a review queue.
- Before the monthly review, compare actuals with plan and prepare a draft variance commentary linked to the underlying figures.
Each statement names an observable event and a reviewable artifact. None quietly grants permission to pay an invoice, trade a security, post a journal entry or publish a report.
This distinction matters because “agent” describes a technical arrangement, not a safe level of authority. Some work needs a model to interpret varied documents or choose among tools. Other work is better handled by rules, queries and conventional automation. The team should be free to use both inside one workflow.
Test value before feasibility
A workflow can be easy to automate and still not be worth operating. Estimate value using the present process rather than a hopeful future one.
Look for four signals:
- Frequency. The work occurs often enough to observe and improve. A daily or weekly process gives a pilot more evidence than an annual exercise.
- Meaningful effort. People spend time gathering, comparing, copying or chasing information rather than applying judgement throughout.
- A visible delay or error cost. Slow handling postpones a close, leaves an exception unresolved, delays a decision or causes avoidable rework.
- A stable outcome. The team agrees what useful completion looks like, even when individual cases vary.
Count the complete task. If preparing a variance note takes twenty minutes but the analyst spends another hour checking the generated draft, the workflow has not saved forty minutes. Include review, corrections, retries, escalations and the operational cost of keeping integrations and evaluations current.
The ICAEW’s examples of finance agents concentrate on close and reconciliation, exception handling and finding supporting information. These are useful starting patterns because they contain repeated preparation work and identifiable review points. They are not evidence that every version of those processes should be automated.
Check whether the evidence is ready
An agent needs more than access to a folder or finance system. It needs the evidence required for the job, in forms the workflow can reliably retrieve and relate.
Map the source trail for three recent examples. Note where each fact came from, which version was authoritative and how the person doing the work resolved conflicts. Include spreadsheets, messages and personal workarounds; excluding them makes the proposed workflow look cleaner than the real one.
Then ask:
- Are the required records digital and accessible through a supported interface?
- Can the system distinguish current, superseded and missing information?
- Do permissions allow the workflow to read only what it needs?
- Are there enough accepted examples and difficult exceptions for evaluation?
- Can the output link each material claim or proposed action back to evidence?
A pile of historic documents is not automatically a useful evaluation set. The examples need a known outcome and enough context to explain why it was accepted. If reviewers frequently disagree, capture that disagreement rather than declaring one answer correct after the fact.
Poor readiness does not always reject the idea. It may reveal the first useful project: organise source records, add identifiers, expose a safe API or formalise the review state. That groundwork can improve the current process before any model is involved.
Treat control as a separate gate
Do not average control risk into a single reassuring score. A frequent workflow with excellent data can still be a bad autonomous agent if one wrong action could move money, disclose restricted information or create a misleading record.
For each step, separate what the software may read, prepare, recommend and change. Then answer five questions:
- What is the credible worst result when the output is wrong?
- Can a qualified person review it before that result occurs?
- Does the reviewer see the evidence and differences needed to make a real decision?
- Can the action be reversed without hiding the original event?
- Is one person accountable for the workflow, its permissions and its exceptions?
“Human in the loop” is not enough when the human receives fifty unexplained approvals or must repeat the entire analysis. Review must be cheaper than the original work and supported by the right context.
The NIST AI Risk Management Framework recommends defining roles, measuring risks and managing them throughout the system lifecycle. Its generative-AI profile also highlights governance, pre-deployment testing, content provenance and incident disclosure. In finance, these ideas become concrete: named owners, source-linked outputs, tested permission boundaries, retained action logs and a known way to pause the workflow.
Put the candidate into one of four starting positions
Value, readiness and control produce a more useful decision than a single percentage.
Strong pilot candidate
The work repeats, consumes meaningful effort and has a stable output. Evidence is accessible. A person can review the result before consequence, and the system can preserve sources and actions.
Start with a narrow subset: one entity, document class, ledger or coverage list. Run alongside the current process and compare both routes.
Pilot after groundwork
The value is credible, but records, examples, identifiers or integrations are weak. Fix the smallest missing foundation first. Avoid disguising a data-cleaning project as an agent pilot.
Assistive mode only
The workflow is valuable but an error would be difficult to detect or reverse. Let the system collect evidence, identify candidate exceptions or draft material. Keep posting, payment, publication and regulated decisions outside its authority.
Choose another workflow
The task is rare, its outcome is disputed, review duplicates the work or the benefit depends on removing controls. Find a smaller adjacent job. Sometimes the useful automation is routing documents or maintaining a queue rather than performing the expert decision.
Example: a research-monitoring workflow
Suppose an investment team wants an agent to monitor a coverage list. “Research these companies and tell us what matters” is difficult to test. A narrower job is easier to own:
When an approved company source publishes a new filing or announcement, identify it, compare it with the previous source, and prepare a change note with links and quoted evidence for analyst review.
This candidate may score well on frequency, preparation effort and reviewability. It still needs decisions before implementation:
- Which sources are approved, and what happens when one is unavailable?
- How is a company or security identified across providers?
- Which changes belong in the note?
- What evidence must appear beside each statement?
- How stale may market or reference data be?
- Who decides whether the note affects a forecast, recommendation or trade?
The agent can organise evidence without becoming an investment decision-maker. That boundary gives the pilot an observable output and keeps responsibility with the analyst.
Example: supplier-invoice exceptions
An accounts-payable team may spend hours matching invoices, purchase orders and receipts. A useful first slice can gather those records, compare defined fields and prepare only the mismatches for review.
Straight arithmetic and exact identifier checks should remain deterministic. A model may help interpret varied descriptions, locate supporting correspondence or draft a supplier question. Low-confidence matches should remain visibly unresolved.
The pilot should measure more than extraction accuracy. Track the proportion of invoices resolved without reopening sources, reviewer time per exception, incorrect matches, missing-document handling and whether the proposed queue reduces or merely relocates work.
Payment release stays outside the first slice. Expansion should depend on evidence from representative invoices, including duplicates, partial deliveries, changed bank details and documents containing irrelevant or adversarial instructions.
Run a pilot that can produce an honest “no”
A pilot is useful when it can disprove the idea before a broad rollout.
- Record a baseline. Measure elapsed time, active effort, exception rate and corrections in the current process.
- Assemble representative cases. Include ordinary work, missing inputs, conflicting records and rare high-consequence cases. Keep a separate evaluation set for later changes.
- Begin in shadow mode. Produce results without changing downstream systems. Compare them with the work people actually accepted.
- Introduce explicit review. Show source evidence, uncertainty and proposed differences. Record corrections and reasons.
- Test failure paths. Remove a source, expire a credential, change a document format and attempt an unauthorised action. Confirm that the system stops usefully.
- Agree expansion and stop conditions. Decide in advance what evidence permits more scope and what result pauses the pilot.
Do not promise an arbitrary thirty-day transformation when representative work occurs only monthly or dependencies remain unavailable. Choose a pilot window that contains enough real cases to judge the workflow.
Use the score as the start of a conversation
No questionnaire can decide whether a finance process should become an agent. It can expose assumptions worth testing: where value comes from, which evidence is missing, what authority is proposed and who owns the result.
Take one real workflow, not an imagined future platform, and score its readiness. Bring the result to the people who perform, review and operate the work. If they disagree, investigate the disagreement before building.
Sunclue designs and operates bounded AI-agent workflows and finance research tools around traceable sources, explicit review and clear ownership.