Treasury in Action 01: Financial Modeling Edition

The Excel Guru Strikes Again (Or: How to Fix a Financial Model That Fights Back)

Case Study

The Situation

When asked to describe the environment, the consultant (let’s call him Model Yoda, for reasons that will become obvious) didn’t walk into a startup wrestling with a chaotic spreadsheet.

Instead, he stepped into a large European airport, the kind of highly regulated, complex organization where financial models quietly sit at the center of major decisions, whether people like to admit it or not.

At the heart of it all was a financial model built by a well-known international firm. And to be fair, at first glance, it looked the part. Large, detailed, and sufficiently complex to give the impression that everything had been thoroughly thought through.

It was only when people started actually using it that the cracks began to show…

  • ~40MB monster file
  • Built on outdated logic
  • Packed with unused features
  • Slow, rigid, and… slightly terrifying to touch

Technically, it worked, but working and being usable are not always the same thing. The model behaved a bit like an old, well-maintained car: reliable enough to get you from A to B, but not something you would trust if quick reactions or flexibility suddenly became important.

And in an environment where timing and clarity matter, that distinction tends to become visible fairly quickly.

The Challenge

What made the situation tricky was that nothing was obviously “broken”.

The numbers reconciled, the outputs looked reasonable, and the model did what it had originally been built to do. The problem was more subtle: it was slow, rigid, and increasingly difficult to adapt to new requirements.

Once you looked a bit closer, three structural issues stood out.

1. Rigid Structure

Adding something as simple as a new subsidiary required changes across large parts of the file. That, in itself, is manageable until you realize how easy it is to miss a single reference and quietly introduce an error that only shows up much later, usually at the worst possible moment.

2. VBA Dependency

Under normal circumstances, that might not be a problem, but in this case the company, like many others, was already moving away from it for security reasons. Which meant the model wasn’t just inconvenient; it was gradually becoming incompatible with the company’s IT security environment.  

3. Performance Bottlenecks

Recalculations could take up to ten minutes, which doesn’t sound dramatic until you’re in the middle of a discussion and need to adjust assumptions in real time. At that point, even small delays start to shape in what way and how often the model is actually used.

None of these issues are unusual on their own. What matters is how they combine. A model that is technically correct but slow to adapt, difficult to maintain, and increasingly out of sync with its environment tends to create friction in places where clarity is expected.

After three decades of working with financial models, this was a familiar setup.

The Approach

Rather than trying to improve individual parts of the model, the decision was made fairly early on to take a step back and rethink the structure altogether.

Or, put more directly: instead of patching something that had grown overly complex, it made more sense to rebuild it in a way that would actually support how the business operates today.

Step 1: Back to First Principles

At its core, every financial model consists of:

  • Inputs
  • Calculations
  •  Outputs

It’s a simple idea, but one that often gets blurred over time as models evolve under pressure.

Here, the separation between those three layers was reintroduced deliberately and consistently. Not because it’s elegant, but because it makes everything else easier: changes become clearer, dependencies more visible, and errors easier to spot before they spread.

Step 2: Rethinking Where Calculations Happen

Excel is an excellent tool, but like any tool, it has its limits, especially when it is used as both an interface and a calculation engine for increasingly complex logic.

Instead of pushing those limits further, the heavy calculations were moved outside the spreadsheet and rebuilt in C#, then connected back to Excel via an add-in.

This left Excel to do what it does best: provide structure, transparency, and interaction. Meanwhile, the computational load was handled elsewhere.

Step 3: From Hardcoding to Drivers

Another major shift was moving away from hardcoded logic toward a driver-based, parametric framework.

Rather than embedding assumptions directly into formulas, the model now works with clearly defined drivers such as price, volume, growth, inflation, and seasonality. From there, projections are generated systematically.

The immediate benefit is not just flexibility, but traceability. Numbers are no longer scattered across the model; they can be followed, understood, and explained without needing to reverse-engineer entire sections.

Step 4: Using Excel as It Was Intended

With the structure in place, modern Excel functionality could finally be used properly.

  • Structured tables
  • Dynamic arrays
  •  Lambda functions

All replaced older constructs, making the model more consistent, robust, and easier to navigate.

VBA was removed entirely, which aligned the model with the company’s broader direction and eliminated a layer of technical dependency that had been causing concern.

As he put it, with a slight smile:
“ Many people think they know Excel. They usually know just enough to get into trouble.”

Step 5: Designing for Real Use

  • Automatic handling of new entities → just add a row
  • Built-in validation → errors don’t hide
  • Scenario modeling → unlimited, without breaking formulas
  • Timeline flexibility → switch from 3 to 10 years instantly

Why This Works

As mentioned earlier, the Model Yoda’s approach is shaped by something simple: 30 years of fixing other people’s models.

He’s seen broken logic, hidden errors, and “Quick fixes” that became permanent disasters.

So now he designs models that don’t break under pressure, don’t depend on one person understanding them, and don’t collapse when reality changes. Very handy in our ever-evolving economy, isn’t it?

Most importantly, he genuinely enjoys this!

What excites him most?

“When the client finally ‘gets it’… and you see that smile.”

The Impact

The effects of the rebuild are already clear.

Calculation times dropped from around ten minutes to one or two, depending on the level of detail. More importantly, the model became responsive enough to be used in discussions, not just before or after them.

Changes that previously required careful adjustments across multiple sheets could now be handled in a more straightforward way, whether that meant adding entities, adjusting assumptions, or modifying reporting views.

At the same time, transparency improved significantly. With clearer structures and built-in validations, the likelihood of hidden errors decreased, and the model became easier to review and explain.

What changed was not just speed, but usability. The model moved from being something people worked around to something they could actually rely on.

Client Feedback

Early feedback reflects that shift.

The new model reconciles with the previous version, which provided confidence in the transition, but beyond that, the team has been noticeably more comfortable working with it. The advantages are not theoretical; they show up in day-to-day use.

Interestingly, the decision to bring in an independent expert rather than relying on a larger firm was ultimately validated not by branding, but by the outcome.

Personal Perspective

For the consultant, this project was less about fixing a file and more about building something the right way from the ground up.

It offered the opportunity to apply 30 years of experience, challenge familiar patterns, and demonstrate that good financial modeling is not about adding layers of complexity, but about removing unnecessary ones.

Or, as he put it:
“The client went from a model that worked against them… to one that works with them.” 

Final Takeaway

What changed here wasn’t just performance or structure. The model went from being something that required careful handling to something that supports the people using it.

And that this makes all the difference.

Thinking About Your Own Model?

 If your financial model:

  • Takes too long
  • Breaks when you touch it
  • Or requires “that one person” to understand it

You don’t have a model; what you have is a liability.

And that’s exactly where Model Yoda comes in.

Interested in what Model Yoda could deliver in your environment?

Reach out to us, and we’ll show you.

“The CFO Prompt Playbook: How Treasurers Should Talk to Finance Leadership”

Looking for an Interim Treasurer? Avoid These 5 Mistakes

Africa & Middle East Treasury Summit (Reality check)

more blogs