Getting finance to fund automation: what the numbers need to look like

Automation proposals that do not get funded typically have one of two problems. Either the savings estimate is too vague to survive scrutiny ("we will save 20 hours per week across the team"), or the risk picture is unclear ("implementation will take three to six months"). Finance teams are not opposed to automation. They are opposed to business cases that require them to take the proposer's word for it.

Getting automation funded reliably requires producing numbers that a CFO can independently validate. That means building the business case from data that already exists in your systems, rather than from estimates of how the process should work. Here is what that looks like in practice.

Start with the cost baseline, not the savings estimate

The most common mistake in automation business cases is leading with the savings figure. "This project will save $180,000 per year." A finance reviewer immediately asks: where does that number come from? If the answer is "we estimated that the team spends about 15% of their time on this process," the conversation deteriorates.

The stronger structure is to lead with the cost baseline: what does this process currently cost, based on data you can show? The baseline has three components: transaction volume (from your systems), average labour time per transaction (from workflow event data, not from interviews or estimates), and loaded cost per labour hour by role (from HR data). Multiply these together and you get the annual cost of the process from data, not from assumptions.

A finance reviewer who can see the cost baseline calculated from first-principles data has something to verify. They can check the volume against the CRM or ERP. They can check the role cost against the HR system. The business case becomes a matter of calculation, not trust.

Decompose the savings to the step level

A savings estimate that says "this process costs $240,000 per year and the automation will save 60% of that" does not tell a finance reviewer which part of the process is being automated, what that step currently costs, or how the 60% was calculated. These are not unreasonable questions and the inability to answer them is what kills proposals in budget review.

The stronger structure is to decompose the savings to the specific steps the automation addresses. The process has seven steps. The automation targets steps 3 and 5, which together account for $142,000 of the $240,000 annual cost. The automation will eliminate 80% of the labour time in step 3 (a data transfer step that will be fully automated) and 40% of the labour time in step 5 (an approval step that will be routed and escalated automatically, reducing queue time). Projected annual savings: $97,000.

This structure is verifiable. A finance reviewer can check the step-level cost breakdown, evaluate whether 80% and 40% are credible improvement targets for the described changes, and recalculate the savings with their own assumptions. That is what a credible business case looks like: one where the finance reviewer can reconstruct the calculation independently.

Bound the implementation cost honestly

Finance teams are suspicious of automation implementation cost estimates for good reason. Software projects routinely cost more and take longer than projected. A business case that projects a 12-week implementation with a $45,000 tool cost and three weeks of internal configuration time will be received sceptically if there is no basis for the estimate.

The honest structure is to give a range rather than a point estimate, and to explain what assumptions the range is based on. "We expect implementation to take 10 to 16 weeks, based on the complexity of the two integrations required and comparable implementations we have reviewed." Give a comparable reference point if you have one: similar-scope automation projects in the same tool category, documented in vendor case studies or industry benchmarks. Not a specific named company, but a category reference: "projects of this scope in this tool category typically run 12 to 20 weeks."

Also separate the one-time implementation cost from the ongoing annual cost of the automation (licensing, maintenance, monitoring). The payback period calculation should use the total cost of ownership, not just the implementation cost.

Address the FTE savings question directly

Finance teams have a specific concern with automation business cases that claim labour savings: will the savings actually appear in the cost structure, or will the time saved be absorbed by other work and not reduce headcount? This is a fair question and avoiding it makes the business case weaker, not stronger.

There are two honest answers. If the savings are large enough to reduce headcount, say so explicitly: "These savings represent 1.2 FTE equivalents. We are not proposing a headcount reduction; we are proposing that as the team grows, these two roles can be deferred. The savings show up as avoided hiring cost." Finance understands avoided cost.

If the savings are not large enough to reduce headcount, say what they produce instead: "These savings free up approximately 6 hours per week per person in this team. The redeployment value is [one of: faster processing of X, capacity for Y project that we currently cannot resource, or reduction in overtime that is currently running at Z hours per month]." Give the finance reviewer something concrete to evaluate, not an abstract productivity gain.

What a CFO actually needs to see

The business case structure that gets approved has four components: the current cost baseline (data-derived, not estimated), the specific intervention and its projected impact (step-level decomposition), the implementation cost with a realistic range, and the payback period calculated conservatively.

Conservative means using the low end of the savings estimate and the high end of the cost estimate. A business case that projects payback in 18 months in the conservative scenario will get more durable approval than one that projects payback in 9 months in the optimistic scenario and then misses by a factor of two.

We are not saying you need to undersell the opportunity. We are saying that finance teams have seen enough automation proposals that overstated their savings that they have calibrated their discount rate accordingly. A proposal that leads with conservative, data-grounded numbers gets taken more seriously than one that leads with the best-case scenario. Build the business case from your actual workflow data, decompose the savings to the step level, and present the range honestly. That is the structure that gets a yes.