Last week, I was running a live AI forecasting workshop with a room full of senior finance leaders. We'd just finished building revenue prediction models in Python. Seasonal adjustments, backtesting, everything.

And then a fractional CFO raised his hand and said something that stopped the room.

"I don't want to be the grumpy old man, but until now, I'm skeptical. For all my clients, I build a three-statement financial model. It's in Excel, but then in a very clean and consistent way. And it does everything we're trying to do now."

And you know what? He was right.

All he has to do is sit with a client, tweak the days outstanding assumption, and then show them in real time what that does to the cash position in six months.

Often, this client will pick up the phone and start chasing receivables straight away!

So why would he move to Python? For his use case, he probably shouldn't.

But someone else in that same workshop had a different problem…

Right now they are working with more than 90,000 active products, and their problem is getting the cost of goods sold predictions accurate every month.

For that person, Excel isn't the answer. And pretending that it is the right tool would cost them accuracy, time, and credibility.

The question was never which tool is better.

The question is which tool matches the problem you're solving right now.

​
The One-Tool Mindset

There's a pattern I see in almost every finance team I work with. People pick a tool first and then try to make the problem fit.

You know this expression: “When all you have is a hammer, everything looks like a nail”?

There are 2 groups:

Group 1 - sticks with Excel for everything because it's familiar. Even when they're forecasting across 50 product lines in 20 regions, and they'd need to copy-paste the same process hundreds of times.

It works (technically), but it's slow, and the chance of errors grows with every tab.

Group 2 - Chases whatever AI tool LinkedIn is buzzing about this week, even when a clean spreadsheet model would be much faster, more transparent, and more useful.

Both approaches fail for the same reason. They start with the tool, not the problem.

"If you talk to a data scientist or somebody who's very technical, then their solution is often going to be very technical. It may not be the correct solution."

This is the danger.

The data scientist defaults to Python because that's what they know.

The Excel pro stays in spreadsheets because that's what they trust.

And neither one is asking the right question first.

When you pick the wrong tool in forecasting, it is much more than the hours you waste.

If you present a black-box Python model when the board wants to see what assumptions you’ve made, and logic they can follow, you've lost trust.

If you present a basic trendline when the business needed multi-variable modeling across thousands of products, you've lost credibility.

The answer?

Group 3 - This group asks "what problem am I solving?" first, and then picks the tool that fits.

This is where you want to be.

​
Choose Your Transport

The solution is a decision framework.

Three questions that you can run through in a single meeting.

And they'll tell you, for any given forecasting need, whether to stay in Excel or bring in Python.

Think of it like choosing transport for a trip.

A bike is perfect for 5km.

A car is better for 50km.

A plane for 5,000km.

Nobody argues that planes are "better" than bikes.

It’s just a question of where you want to get to.

​
Three Questions Before Your Next Forecast

Question 1: How many things am I forecasting?

If you're building a single revenue forecast or a three-statement model for one client, stay in Excel. My fractional CFO's two-day build process is hard to beat for this use case.

But if you're forecasting across 50 product lines, 20 regions, or thousands of products, Python wins because it can run the same forecast logic across every segment automatically.

The breakpoint is around where you'd need to copy-paste the same Excel process more than ten times, or where the number of variables influencing your forecast goes beyond what you can do by hand.

Plus, there is another layer to this.

Even if you're forecasting less items, look at what drives your revenue. If it has high transaction volume, strong seasonality, or links with external factors like macro-economic conditions or web traffic, Python gives you something Excel can't.

You can use seasonality algorithms like Prophet, or build models that include more than one variable at a time.

In Excel, you only have trend lines and manual adjustments. In Python, the model can learn from all of those drivers together.

Question 2: Am I encoding what I already know, or do I need the model to learn from the data?

If you're building assumptions you understand (growth rate, headcount, days outstanding) and you want to change those assumptions in front of a client or your board, Excel is good for this.

But if you need the model to detect patterns you can't see on your own (seasonality across 90,000 products, non-linear cost drivers, anomaly detection in transaction data), that's where Python and machine learning models like Prophet or XGBoost come in.

Question 3: Who's your audience, and do they need to see your working or your accuracy?

These are two very different conversations, and they need different tools.

If you're in a meeting where someone asks "what happens if we collect payments 10 days faster?" you need to change that number and show the impact right there in the room. Excel is built for this. You adjust one cell, and the whole model updates in front of everyone. No waiting or re-running code. That's why my fractional CFO's clients pick up the phone on the spot (it’s fast).

But if the conversation is more like "how confident are you in next quarter's forecast?" then you need proof, not a cell change. You need to show that you tested the model against real historical data it hadn't seen, and that the predictions were close to what happened.

Python lets you do this in a few lines of code (it's called backtesting, and it's standard practice in data science). You walk into the boardroom and say "our model predicted the last 6 months within 5% of what happened" instead of "trust me, the trendline looks right."

One tool is better for live conversations. The other is better for building confidence in your numbers before the conversation even starts.

Try this right now

​
If you're not sure whether Python’s the right fit, let your AI tool tell you.

Open whatever secure AI tool you use, upload a sample of your data (or a spreadsheet), and use this prompt:

That last line is important. You want the AI to understand your context before it jumps to a solution.
​

Want to give Python a go?

🔗Dummy data link: Ice Cream Sales - 2025.xlsx​

1. Download the dummy ice cream shop data above
2. Upload it to your secure AI tool.
3. Enter my prompt below:

​
The One Thing To Remember

I remember the first time I saw a developer use Python. He uploaded a file and produced an awesome heat map (which in Excel you cannot do). It was perfect. I stormed out of my office thinking “this is really going to change a lot of jobs.”

But just because you see something super cool does not mean you have to use it for everything.

So, before your next forecasting cycle, run your problem through the three questions I have given you.

The answer will tell you which tool is best.

Don’t waste another meeting arguing about technology when you should be arguing about assumptions.

Best,

Your AI Finance Expert,

Nicolas

P.S. - What did you think of this newsletter? Hit reply and let me know (I read all replies)

P.P.S - For more on Python check out Christian Martinez, one of our AI Finance Club experts' video tutorial: The Ultimate Beginners Guide: Python Finance.

​