AI Business Case for Finance: The Questions a CFO Will Ask

A finance-ready AI business case compares what one completed task costs today with what it costs once an agent handles part of it, including the time people spend checking the output. It names one owner for the outcome, one owner for the controls and one owner for the spend, and it sets a review date when the evidence will be examined. This article walks through the questions a finance lead will ask and how to answer each one with measured task outcomes rather than general promises.

Key takeaways

• Build the case around one recurring task with a measurable outcome, not around the platform or the model.
• Divide the full running cost by accepted outcomes, so rework and human review sit inside the number.
• Name an outcome owner, a control owner and a spend owner before any budget is released.
• Write the approval boundaries and the evidence you will review into the proposal itself.
• Present the first case as a test of the operating model with a fixed review date, not as a forecast of total value.

What a finance lead is really deciding

A finance lead rarely asks whether the technology is impressive. The decision is narrower: whether a specific cost can be tied to a specific result, whether the spending can be reduced or stopped if that result does not appear, and who will notice when something drifts. Most approval conversations come down to four questions about the baseline, the expected change, the total cost to run, and the consequence of being wrong.

That framing changes what the proposal must contain. A slide that describes capability answers none of the four. A short document that names a task, its current cost, a target, a stopping condition and a review date answers all of them.

Start with one task that has a clear end

Choose a task that repeats, produces a visible output, and has a person who can say whether the output was right. Routing supplier requests, drafting replies for a standard support category, or reconciling a weekly list of exceptions are typical candidates. Avoid tasks that depend on judgment nobody has written down, because the case will then rest on opinion rather than evidence.

Before writing any cost, document the work as it runs today:

• Describe the trigger, the inputs, the steps and the output in plain sentences.
• Record who does the task, how often it arrives, and where delays and errors usually appear.
• List the memory, documents and systems the work needs, and the data the agent should never see.
• Define one success criterion that someone can check in your own systems, not in a vendor report.
• Decide what the agent may do alone, what it may only propose, and what it must never do.

This list is also the first draft of your scope statement. If you cannot write it on one page, the task is probably too broad for a first engagement. The guide on proof of concept, pilot or production explains why a single bounded task should prove its value before the scope grows.

How do you measure outcomes per completed task?

The useful unit is the cost of one accepted outcome. The FinOps Foundation's unit economics guidance makes a similar point for cloud spending: a total bill tells you little until it is connected to the business activity it supports. Apply that logic here. Add model usage, infrastructure, integration maintenance, monitoring time and the human time spent reviewing output, then divide by the number of outcomes completed and accepted without rework. Rework and escalations belong in the calculation, not in a footnote.

Illustrative scenario: a customer operations team handles refund requests. Today a coordinator reads each request, checks the order record and drafts a reply. The proposal has the agent prepare the order check and the draft, while a person approves every refund. The finance lead will not accept a general claim that the work is cheaper. The lead will ask what an accepted refund decision costs, how often a draft needed substantial rewriting, how many cases were escalated, and what the team did with the time released. If rework rises, the case weakens, and the review date is where that decision gets made.

Who owns the outcome, the controls and the spend?

A case without named owners tends to fail at the first incident, not at the approval meeting. Three roles belong in the proposal. The outcome owner is the business leader who accepts the result and decides whether the task should stay automated. The control owner is the person responsible for permissions, logs and changes, usually from operations, IT or security. The spend owner approves the recurring cost, which may sit in a central budget or in the department that benefits. Where that money should sit is a real decision, and the article on who pays for the AI agent sets out the trade-offs.

Put the three names on one page with the authority each one holds. Include who can pause the agent without asking anyone, because finance will ask how quickly activity and spending can be stopped.

Which controls will finance ask about?

Finance rarely reads permission models, but it needs to know that access is bounded and that the bounds are checked. Access should follow least privilege: the agent receives only the tools and records its task requires, each with a stated purpose. OWASP's authorization guidance treats access as a decision to be enforced consistently, which is why access should be reviewed on a schedule rather than only at setup. The quarterly permission review steps give a concrete format for that evidence.

Evaluation is the second control. Anthropic's engineering guidance on evaluating agents describes running fixed test tasks, grading the outcomes and repeating those checks as the system changes. The NIST AI Risk Management Framework offers a shared vocabulary for mapping, measuring and managing risk, which helps when the finance lead and the risk owner need to discuss the same thing. Use these as the source of your evidence section, and keep the wording plain.

The questions a finance lead tends to ask are these:

• What exact task does this change, and what is its current baseline?
• What does one accepted outcome cost, with review and rework included?
• Which systems can the agent read, and which can it change?
• Who can pause it, how quickly, and who is told when it happens?
• What evidence will be shown at the review date, and who decides what it means?

How do you present the case and set the review date?

Write the proposal as a short decision document, not as a presentation. Include the task description, the baseline, the target, the scope limits, the owners, the cost structure, the evaluation method and the date when results will be reviewed. State the conditions that would make you stop. A case that names its stopping conditions is easier to approve, because the downside is bounded in writing.

Set the first review early enough to act on and late enough to show a pattern. Finance should see accepted outcomes and failed cases side by side, with the reason for each failure and the change that followed. If the review shows that the task is not worth automating, that is a useful result, and the decision to pause is part of the same operating discipline. The steps for stopping a pilot without wasting the work already done cover that path.

Be Human approaches this as a managed service. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled changes, each recorded so the owners have evidence at every review date. The work is delivered remotely, in English or Portuguese, and the scope stays as small as the first task allows. What the first months typically involve is described in the first months with a managed AI agent.

If you are not yet sure which task deserves to go first, the free Be Human AI diagnostic is designed to help you find it.

Frequently asked questions

What if we never measured the current cost of the task? Start with a short time sample across a normal period, recording how long each step takes and where work waits. An estimate with a stated method is more useful to a finance lead than a precise figure with no source. Keep the method in the proposal so the baseline can be measured again at the review date.

Is a cost per task enough, or do we also need the total? You need both. The per-task figure shows whether the work is improving, and the total shows whether the spending is sustainable at the volume you expect. The total should include running costs such as monitoring and integration maintenance, which are easy to forget at the approval stage.

Who should decide to stop the agent? The outcome owner should decide on performance, and the control owner should be able to pause the agent immediately when access or behavior looks wrong. Write both rights into the proposal so that nobody has to ask permission during an incident. Finance benefits from knowing the stop decision is already assigned.

How does this differ from a standard software business case? A software case usually assumes a stable feature set. An agent's behavior depends on its memory, tools and permissions, which change over time, so the case has to treat evaluation and permission review as recurring costs and recurring decisions. That is why the owners, the review date and the stopping conditions belong inside the proposal itself.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.