What does a CFO ask before approving a purchase?

Four questions recur: what does this replace, what is the payback claim based on, what does it cost to leave, and who owns the outcome afterward. They are about cash, risk, and accountability rather than product capability, and they can usually be anticipated and answered before the meeting.

How do I get budget approval for software?

Pre-brief the CFO or their team so the request is never a surprise, frame the purchase around what it replaces rather than what it adds, build the payback story from your own pilot or workload evidence rather than vendor benchmarks, and name the person who will own the result. Requests that arrive with those answers attached tend to travel faster.

What kills software purchases in finance review?

The recurring killers are surprise, where the CFO hears about the request for the first time in the meeting; unowned outcomes; purely additive framing with nothing retired; and long commitments attached to unproven tools. Most are preparation problems rather than product problems, which makes them avoidable.

Do CFOs review AI tools differently?

Often the same four questions apply with extra weight on two of them: replacement, because many AI tools enter budgets as pure additions, and exit terms, because the category is young and data portability varies. Scrutiny of data-handling terms also tends to run higher than for established categories.

What CFOs ask before approving new software

Guide · Enterprise · 4 min read · last verified 2026-07-28

Reviewed before publication Editorial board Independent commercial review

In shortThe finance gate turns on four questions: what the software replaces, what the payback claim rests on, what it costs to leave, and who owns the number afterward. Written for the seller and the champion who must answer in the room.

CFO approval is the moment a software purchase stops being a team preference and becomes a company commitment. Up to that point, the evaluation has mostly been about capability — does the tool work, will the team use it. In the finance review the questions change genre: they are about cash, risk, and accountability, and they are asked by someone who may never open the product. This piece is written for two readers at once — the seller trying to survive that review, and the internal champion who has to sit in the room and answer.

It helps to separate this moment from the ongoing relationship between a department and its CFO. Reporting to finance quarter after quarter is a different discipline with its own rules, covered in how to report marketing to a CFO. Approval is a single gate, crossed once, and it tends to turn on a short list of questions that repeat across companies with striking consistency.

"What does this replace?"

Software that replaces something — a tool being cancelled, an agency retainer being reduced, a recurring block of manual work being reabsorbed — arrives with part of its own justification attached. Software that is purely additive has to clear a higher bar, because additive spend is how budgets quietly grow. The question has sharpened in the current wave of AI tools, many of which enter budgets as additions: a note-taker here, an assistant there, a research copilot layered on top of the research subscriptions the team already pays for. A champion who can say credibly that the purchase absorbs two existing line items and a standing chunk of manual effort is answering the question before it is asked. A champion who says "it makes us better" without naming anything that goes away should expect the follow-up.

"When does it pay back — and what is that resting on?"

CFOs rarely demand certainty about payback. What they probe is the basis: which assumptions produce the claim, and whose data feeds those assumptions. A payback story built on the vendor's benchmark deck rests on other companies' outcomes under other conditions. A story built on your own pilot, your own pipeline, or your own measured workload rests on evidence the CFO can interrogate — and the distance between those two stories often decides the meeting. If the purchase is a market intelligence or research product, the case has category-specific quirks, covered in how to make the business case for market intelligence. The general rule travels: bring a basis, not a promise, and volunteer your assumptions before being asked for them.

"What does it cost to leave?"

Finance reads a contract the way an engineer reads a dependency: what happens when we want out. Exit cost includes the obvious terms — contract length, renewal mechanics, notice windows — and the less visible ones: whether your data exports cleanly, how much workflow would need rebuilding, how many integrations would have to be unwound. Auto-renewal clauses with long notice periods draw particular attention, because they convert a purchase into a recurring commitment that can outlive the people who made it. A champion who has already read the termination clause, and a seller who makes exit terms easy to find, are signaling the same thing: nobody here is hoping finance skims.

"Who owns this number in a year?"

This is probably the most underestimated question in the set. Software that succeeds has an owner — a named person whose goals change if it works and whose standing suffers if it is quietly abandoned. Purchases without an owner become orphans: renewed by inertia, used out of habit, defended by nobody. CFOs have watched that cycle often enough to ask about it early. The strong answer is specific — who runs it, what they will report, and when the first honest checkpoint arrives. It also helps to know who in the process can actually say no; the difference between procurement's veto and the economic buyer's is its own subject, covered in procurement vs the economic buyer.

What tends to kill purchases in review

Watched from either side of the table, the recurring causes of death are rarely about the product. Surprise kills: a CFO encountering the request for the first time in the approval meeting has been handed a reason to say "not yet," and "not yet" is the polite form of no. Unowned outcomes kill: benefits attributed to everyone belong to no one. Purely additive framing kills slowly: the purchase may pass, but it enters the budget as the first candidate for the next cut. And mismatch kills: a long commitment attached to an unproven tool asks finance to hold more risk than the evidence supports. None of these are objections to the software itself, which is what makes them so frustrating — and so avoidable — for everyone involved.

If you are the seller

Most of this gate is closed to you directly; you will probably never meet the CFO. What you can do is arm the champion. Write the one-page answers to the four questions above in the buyer's own terms rather than your averages. Offer contract lengths proportionate to the trust you have actually earned. State exit terms plainly instead of making them archaeology. And expect the diligence around the deal — reference calls included (how to run reference calls when buying software) — to continue while finance deliberates. Sellers sometimes treat the finance review as an obstacle that appears after the real sale. It is closer to the truth to treat it as a second sale, to a different buyer, in a different language — with your champion, not you, doing the presenting.