When the basics become automatic, your attention goes where it matters.
I learned this after failing my driving test four times. I was focusing on the mechanics: gears, biting point, which stalk was which. All important, but not the whole picture. The examiners all gave the same feedback: not enough attention on the road.
But on my fifth attempt, everything clicked. The roads had not become kinder, but the basics had finally become automatic. My attention could refocus where it needed to be, outside, where the test had always wanted it.
Finance teams sit the same test
I have spent my career watching FP&A teams fail the same way I did. Not for lack of skill, but for lack of spare attention. When a team's whole capacity is stuck on the mechanics – hundreds of files that won’t tie, versions nobody can reconcile, errors that take days to trace, submissions chased one by one – then the business is happening to somebody else. You can’t advise on a decision you didn’t see coming because you’re bogged down in the mechanics of it.
Budget season is where the test is hardest. A forecast is only your best estimate of what will happen. A budget is an agreement about what teams will be held to next year, which makes it a negotiation with a spreadsheet attached.
When things go wrong, it’s easy to blame our tools – a broken formula or a bad model. But the real failure in budget season is running out of time to negotiate properly. It’s delivering the first version because you never had time to explore alternatives.
Most finance teams don’t want only one iteration. They can only afford one. I have met plenty, mine included, that only had that choice. It’s one reason why FP&A teams might struggle to add the value they were hired for. The value was never in the files. It was outside, and nobody could pay attention to the road.
Seeing behind the curtain
In the last edition of this series, our CFO Alistair mentioned that his Head of FP&A was one of the people who built the AI tools our finance team uses. That’s me, and I should explain the paradox properly.
I spent years running budget cycles at other companies, apologizing for the process and frustrated with the tools available. Now I see things from the other side, working at a company that creates such tools. And so, I have spent this year sitting with our product team to make sure our solutions reflect the reality of finance teams’ day to day. As I write this, we’re kicking off our 2027 budget cycle on our own platform, with my colleagues observing exactly how it goes. The person who used to complain about the car is now helping to build it. The least I can do is tell you honestly what it’s like to drive.
What the gears used to cost
A budget cycle in files works like this: one master model becomes a distribution template, the template becomes dozens of copies, and the copies come back changed in ways you didn’t authorize and can’t always see. Numbers arrive in thousands where you asked for units. Somebody inserts a row. At one previous company, I spent two days tracing a single variance through six linked workbooks to one cell where a formula had been overwritten with a hard number, months earlier, by someone who fully intended to put it back.
Our input comes from dozens of cost center owners across functions. Each one becomes a document to produce, send, explain, chase, check, correct, and reassemble. Judgement is a fraction of the work. The rest is administration, performed by people hired to make judgements. That is the mechanics. That is where all the attention goes.
Making the basics automatic
What changed for me came in two steps, and the first had nothing to do with AI.
We wired our planning model directly to the systems the numbers come from. Headcount from the HR system, actuals from the ERP, and commercial data direct from the source (not a screenshot of the source). That prevents the most dangerous error: building a model on data that’s already out of date. A model can be internally consistent and still confidently wrong, because it was built on an extract that went stale the day after somebody pulled it.
We also replaced files with structured submissions. Cost center owners work in the same structure I do, with the same definitions, units, and hierarchy. Their inputs come back as proposals, and each one is reviewed and approved before it merges. There is no second artifact, so there is no version reconciliation, because there are no versions. The platform also keeps a record of who changed what and when. That sounds like overhead until March, when a budget owner asks why their target is the number it is, and the budget must defend itself.
None of this is glamorous. Neither is knowing where the biting point is. It is simply the condition for everything else. That was the first step.
What it exposed rather than fixed
But here’s what we discovered when we started using it. Pointing better tooling at our own data did what it does everywhere: It revealed new gaps rather than resolving them. Definitions that had drifted, fields that had shifted meaning over time, structures that were carried forward long after the reason for them had gone. Connecting a system to any of that fixed nothing. It exposed it, and then people had to fix it, before we could rely on any of it.
Learning to drive did not fix the potholes, but it did mean I could finally see them.
A fast-track to the fourth version
We can’t ignore the AI part – this is our Intelligence inside series after all. But it’s important to emphasize: the data had to be trustworthy before the next step made sense. We put AI to work on the structure of a model, not the numbers inside it. This cycle, we used the Modeler Agent for the first time to build our planning models directly.
The first build is incredibly fast. You describe the model you need in plain language, review the plan it proposes, review sections, variables, timesteps, and the formulas connecting them, and approve it (or not). Every formula stays visible and editable.
But the first build was never the expensive one. The fourth was. Restructuring a model used to carry a real price – so in the past when a budget owner told me a driver was wrong, the honest answer was often that fixing it was not worth the rebuild. The model stayed slightly wrong, everyone worked around it, and within a couple of cycles the workaround was institutional knowledge that new joiners were taught. Now, when restructuring costs an afternoon, that arithmetic inverts. You stop defending the structure and start changing it. The argument improves, because the model can finally keep up with it.
I thought I was buying speed, but what I was actually gaining was permission to change my mind.
Eyes on the road
We are still at the start of this cycle, not the end, so I will not pretend to know how it finishes. We are still building too. Together with our Product team, we are testing workflows and task management inside xP&A this very cycle, while it’s still new. It’s a strange way to run a budget and a very good way to build a product.
If you are opening your own cycle in the coming weeks, let me tell you two things (and neither is about software): First, expect any new tooling to expose your data problems rather than resolve them, and budget the time to fix them. Second, measure the cycle by how many times you genuinely changed your mind about next year, or how many times you would have if you could, not by how many days it took to close. That’s where I foresee the huge potential of AI and Lucanet’s Modeler Agent specifically: in the ability to change your mind.
For the first time in my career, I am opening a budget season feeling prepared rather than braced. Next year has not become easier to predict, just like the roads never got any kinder. The difference is that we can look past the mechanics, and the team's attention has gone back outside, to the business, the decisions, and the negotiation about next year that a budget actually exists for.
It took me five attempts to learn that the test was never about the car.
