The internal sell for AI in finance is almost always harder than the implementation. And most people approach it backwards — they spend months building the business case for leadership, get approval, and then roll out the change to a team that had no idea it was coming and is now being asked to work differently starting Monday.
Both conversations matter but they require completely different approaches.
Making the case to leadership
The pitch that doesn’t work: “AI is transforming finance, and we need to stay ahead of it.” Leadership has heard some version of this about every major technology shift from every department for the last twenty years. It’s just noise for them at this point.
The pitch that works needs to be operational and financial.
– Here is how many hours per month we spend on work that could be automated. – Here is what that time costs us in salary and opportunity.
– Here is what we could be doing with it instead.
– Here is the specific business outcome that unlocks.
The more concrete the better.
– If you had a re-forecast request come in at 4pm on a Friday and the team worked through the weekend to produce something that was outdated by Monday, use that example.
– If your close cycle runs three days longer than it should because of manual reconciliation steps, quantify it.
Leadership approves investments in things they can picture and measure. Abstract efficiency arguments don’t make that cut.
It also helps to frame the ask in phases rather than as a single large investment. That way it is easier to approve incrementally and easier to demonstrate progress on. Showing that
phase one delivered what you said it would will make the conversation about phase two significantly easier.
Bringing the team along
The fear most finance teams have about AI isn’t really about job security, even when that’s what gets said out loud. It’s about disruption. People have built real expertise around existing processes. They know reconciliation inside out, they know which numbers to check twice and which analysts in other departments can’t be trusted to submit on time. That institutional knowledge feels threatened when the process it lives in is changing.
The most effective thing you can do is involve the team before the decision is made, not after. Let them identify the tasks they’d most like to hand off. Ask them where they feel like they’re wasting time and what they’d do with those hours if they had them back.
Two things happen when you run that conversation:
First, you get a much better map of where automation actually makes sense — the people doing the work know the work better than anyone.
Second, the team starts to see themselves as participants in the change rather than subjects of it. That shift in framing changes the entire rollout dynamic.
Another thing worth saying clearly and repeatedly: the goal is to get people out of the work they find least valuable, not out of their jobs. When the first reconciliation runs without anyone touching it, and the output is accurate, and the analyst who used to own it has spent that time on something that actually required their judgment — the conversation usually shifts on its own. People stop worrying about what AI is taking away and start thinking about what they can do with the capacity they’ve gotten back.
The timeline most people underestimate
The internal sell being slower than the implementation is almost universally true, and underestimated.
Technology moves faster than people do. A connected data layer can be stood up in weeks. Getting a team to fully trust the outputs it produces, and to stop running the manual version alongside it “just to check,” takes longer. That’s not a failure of the technology or the team. It’s just how change works.
Plan for a longer adoption curve than your implementation timeline suggests. Build in time for the team to run parallel processes while trust develops. Celebrate the early wins loudly — the first close that ran faster, the first Friday re-forecast that didn’t require a weekend,
the first scenario that leadership asked for and the team delivered in two hours instead of two days. Those moments do more for adoption than any rollout communication ever will.
The buy-in isn’t a gate you pass through once and then you’re done. It’s something you have to build continuously, in both directions — demonstrating value to leadership through outcomes, and demonstrating respect to the team through involvement. When you get both right, the implementation stops feeling like a project and starts feeling like the way things work now.
FAQs
What if leadership asks for ROI projections before approving the investment?
Build the projection around time, not technology. Calculate the fully-loaded hourly cost of your finance team and multiply it by the hours currently spent on automatable work each month. That’s your baseline. Then model what a 50% reduction in that time would mean annually — both in cost and in what that capacity could be redirected toward. Conservative estimates are more credible than aggressive ones, and a phased approval means leadership is committing to a smaller number upfront with proof points built in before the next ask.
How do you handle a team member who remains resistant even after early wins?
Usually the resistance at that point is less about AI and more about identity. Some people have built their professional value around being the person who knows the reconciliation, runs the model, or owns the close. When that work gets automated, it can feel like a loss
even when it’s meant to be a relief. The conversation worth having is about what their expertise actually is — and it’s almost never the reconciliation itself. It’s the judgment, the institutional knowledge, and the ability to catch things that the model can’t. Make that explicit, and give them work that requires it.
Should finance be leading this initiative or should it be driven by IT?
Finance should own it. IT is a critical partner, especially for the data connectivity and infrastructure work. But for the design decisions about what to automate, how scenarios should be structured, and what outputs leadership actually needs have to come from finance. Implementations that get handed to IT to run tend to produce technically functional systems that don’t match the reality of how the finance team actually works.
