“Wait, that can’t be right”, I remember thinking.

I was halfway through presenting our forecasts in a board presentation when I realized the numbers were off. A specific number, which I knew couldn’t be valid, revealed it.

Was I presenting the correct version? Was it a copy-paste error? Had someone else updated the file? I wasn’t sure, and despite double-checking everything, something had gone wrong. What do I do now?

I first stumbled upon the problems with financial planning in Excel and Google Sheets when I started my first finance role as Head of Finance. Commonly, my responsibilities included:

• Creating an annual budget

• Tracking actuals vs. budget every month

• Maintaining an updated cash flow forecast

• Preparing monthly KPI reports to investors

• Creating scenarios for strategic initiatives on an ongoing basis

• Creating fundraising models with 3-year financial outlooks

It seemed straightforward at first glance. With a McKinsey background, I figured I was set up for success.

I wasn’t.

Operational complexity quickly made my job difficult. The business had entities across multiple countries with different general ledgers and base currencies. Simultaneously, many colleagues required access to the model but couldn’t view each other’s figures. For instance, a country manager responsible for their country's profit and loss should not have access to other countries' salary details.

To tie it all together, I had to do a lot of currency conversion, copy-pasting, actuals import, file merging, and formula building. It all left room for error. If there is one wrong copy-paste, one wrong file merge, or one obsolete formula, the forecast might be completely off.

I’ll tell you, that will make you paranoid.

Even worse, it could be justified if it had been a one-time thing, but I had to revisit the work every month. It wasn’t sustainable. We needed the work to manage the business properly, but the resources required seemed disproportionate.

It got me thinking: How do the best finance teams approach financial planning and analysis (FP&A)?

In 2020, I returned to study at MIT. While many of my peers dove into crypto and COVID modeling (after all, it was 2020), I became increasingly preoccupied with what ‘good’ financial planning looks like. This intrigued me because it bridged two of my passions: finance/accounting and digital product development… though admittedly, it wasn’t as glamorous as crypto.

That’s when I set out to understand how top finance teams approach financial planning and how smaller teams can achieve the same thing.

At a high level, at Francis, we think of FP&A as creating and following up on plans. When we started, we knew that FP&A spanned many different areas, including controlling, consolidation, collaboration, strategic planning, and reporting, all of which require various capabilities.

Talking to 100s of people, it became clear that there was no definition of where FP&A starts and ends. Some addressed accounting automation, others broad reporting needs. Because much of the work had historically been done in Excel on an ad-hoc basis, there was no need to define the specifications.

This presented a problem. How were we supposed to explore what it takes to succeed in an FP&A role if we couldn’t agree on what it means in the first place?

Initially, it was chaos. A big part of this came from speaking to too many different types of customers. Initially, we’d meet with all the actors with a stake in financial planning. This included business owners, accountants, finance teams, and investors. At one point, I even found myself in a meeting with a bank executive discussing personal budgets for mortgage planning. However, we learned that they had different prerequisites for planning and solved for varying needs. Investors wanted standardized reporting, accountants wanted out-of-the-box budgets, and finance teams wanted more powerful planning and collaboration. Following startup 101 advice, we eventually narrowed our focus to only supporting finance teams in mid-sized companies, which, to our relief, brought a lot of clarity - more on that in a future post.

As we focused our efforts on one target segment, patterns emerged. Users asked for the same things, and it became clear which feedback to prioritize. We could now begin defining the capabilities of the future. Over the years, we’ve honed in on eight key capabilities, summarizing the hundreds of feedback items we receive. The capabilities are a great way to frame conversations with finance teams who want to do more. We’ve published them on our website and here to help finance teams articulate their needs better:

We see that the best finance teams pursue these capabilities. Think of them as a menu of items you can incorporate into your FP&A operations as you grow. Advanced FP&A teams do all eight.

For example, I can share how we approach financial planning internally at Francis.

We have two entities (USA + Denmark) and do our bookkeeping in Quickbooks Online and Visma e-conomic. For starters, I created a financial model that suits our needs. From day one, I also needed integrations to import actuals from our two accounting systems. Unusually, we started with two entities and consequently needed consolidation and currency conversion right from the start. Even though we’re a small team, I collaborate on plans with management. I use version control to forecast KPIs and cash flow/runway monthly. I use variance analysis for internal performance tracking and reporting for external investor reports. Once we expand our team, we’ll need to implement restricted access so department heads can view their plans

In my first finance role, I might not have presented the wrong forecast if I had automatic data imports, robust version control, and more governed collaborative workflows. We’re now trying to ensure that other finance teams don’t make the same mistake.

By far, the most interesting takeaway for me is how surprised our software developers have been about how finance builds and maintains financial models.

For instance, we recently onboarded a client whose financial model covered seven entities in Google Sheets. The client didn’t feel 100% confident in the Sheet model’s output as it was initially built by a consultant before the finance team joined and had since been tweaked many times to accommodate new questions from management.

With many duplicated tabs, revised versions, and custom reports, the client feared any change might produce wrong numbers or break the model.

While this may seem like an extreme example, in our experience, even the most capable finance teams spend a lot of time and mental energy worrying about updates and hidden errors in their models.

Our software developers are surprised because, in their work, they have tools to mitigate these issues.

Below, I’ll discuss those tools and their application in finance.

As we’ve come to realize, developing financial models in Excel and Sheets is similar to developing software. Both consist of handling large data sets, modeling relationships, and crunching numbers.

Software developers use programming languages and databases. Finance teams have tabs, cells, formulas, and functions at their disposal.

For the same reasons, Microsoft CEO Satya Nadella categorizes Excel as its own programming language.

The activities related to managing a financial model can also be framed using software terminology:

• New features: Changing business needs may require expanding the model, such as adding new data imports, scenarios, or reports.

• Maintenance: The model requires regular updates such as adding new general ledger accounts, replacing forecasts with actuals, or updating comparison periods. These updates are necessary to keep the model functioning.

• Testing: Financial models must be tested for accuracy by validating assumptions, verifying calculations, and stress-testing scenarios to ensure reliable outputs.

• Bug fixing: Formula errors, incorrect data inputs, or logical flaws in the model must be identified and corrected.

• Refactoring: As more features and fixes are added to a model over time, it can become overly complex and harder to manage. Refactoring involves reorganizing and cleaning up the model to improve its structure and efficiency without changing its output.

• Rewrite: When a financial model becomes too complex and unmanageable, starting over and developing a new model from scratch may be necessary.

From our conversations with hundreds of finance teams, we’ve learned that they lack tools available in software development to perform these activities efficiently and with peace of mind. Consequently, financial modeling consumes great resources and poses a significant business risk.

You have to ensure the numbers are correct. In the worst case, miscalculating cash flow can lead to bankruptcy and the end of careers. However, you must also preserve resources to contribute to strategy, operations, etc.

This description from the Secret CFO summarizes the issue well: "CFO jobs are about more than numbers. But they are also about numbers."

Even though software developers also have to allocate resources to new features, maintenance, testing, etc., they can build more durable and reliable systems that far exceed the complexity observed in financial models.

They can achieve this because they have developed tools to ensure the integrity of their systems. These tools are born out of necessity, as failure in software systems can be orders of magnitude more severe than failure in financial models.

While a miscalculation in an Excel model might blow up in management’s face and impact the trajectory of the business, a bug in a software system can affect millions of people and lead to fatal outcomes.

Consequently, software developers have created tools to ensure the reliability and durability of their systems. Without these tools, they would be as prone to failure as financial models.

In our experience, a common example of the difference between developers and finance teams is their approach toward duplicates.

Finance teams duplicate everything:

• Duplicate their workbook to create a new forecast

• Duplicate their workbook to save a version

• Duplicate their workbook to revise old versions

• Duplicate their workbook to collect input from contributors

• Duplicate their workbook to share their model

• Duplicate tabs and sections to use them as templates

Software teams don’t duplicate. As quoted by our CTO, “Duplication is the root of all evil.”

Instead, they emphasize keeping code DRY (Don’t Repeat Yourself). This makes maintaining it much easier, as you only have to update things once.

But how do software developers avoid these bad habits? They deploy the four tools below. Let’s review them and see how they can be applied to finance.

Version control

One of the biggest innovations in software development was Git in 2005. Simply speaking, Git is a version control system that makes managing many versions in a continuously evolving system easy. Git is centered around branches, which are a way to present versions visually over time.

With Git, you can track edits over time, making it easy to revert to previous versions if needed. You can also “branch out,” meaning you can edit saved versions in new directions.

The Git manual describes it as a "stupid content tracker,” which I believe should be understood in the best way possible. You don’t need to go far before versioning becomes challenging in finance. Git can help keep it manageable.

Let’s look at another client example to exemplify common version challenges. In this case, the client had just one entity, managed in Excel. Here’s how January and February went:

And so it goes on. The team already had four versions to manage two months into the year. Very quickly, you end up with multiple decoupled versions that are hard to navigate, revise, and compare.

Software developers work with versions in one integrated version control system (Git). That way, they can always account for all versions and changes. One of the great missions of our software team at Francis is to introduce similar smart versioning to finance teams.

Synchronized templates

The thinking in finance is that duplicating tabs or workbooks is an efficient way to expand your model. Contrary to that, software teams never duplicate. They know it’ll create headaches down the line.

To illustrate how this plays out, let’s say you created a P&L template and duplicated it across six departments, along with a consolidation to tie it all together. This is quick to set up.

However, any subsequent change must be applied to all copies once duplicated, and the consolidation must be updated. Otherwise, the six instances will wander in different directions, making them hard to reconcile with the consolidation.

I’ve seen this scenario play out more times than I can count. The cognitive load of remembering all dependencies as you change parts of your model is really tough. This often leaves only one person able to make changes and updates to the model. It's not an ideal state for most teams.

By deploying synchronized templates, you can reduce maintenance to one place. It works by having a system that ensures that changes to the template carry through to underlying instances.

Tests and warning systems

Over the decades, software teams have learned that they need tests to ensure their code behaves as expected. The fundamental idea is that tests validate that the system still works as expected every time a change is introduced.

After conversations with finance teams, we recognized that they typically leverage two tests in their models:

1. Balance sheet checks (assets = liabilities + equity)

2. Sanity checks

Sanity checks are a highly effective way to check the correctness of numbers, but you mostly spot obvious mistakes and miss the ones hidden by subtle changes.

Disciplined teams might do more tests, but we rarely see this.

At Francis, we’ve started embedding tests directly into our platform to support finance teams and warn them about critical mistakes. Some of these tests include:

• Warn when P&L and balance sheet accounts are mixed

• Notify when new accounts have been created in your accounting system

  • Warn if these accounts are not yet accounted for in your model

• Warn if different currencies are mixed

In Excel and Sheets, you’d typically define tests using formulas and functions. In Francis, we’ve embedded a warning system telling you whether you are in the “green” or “red” at any given point.

Collaborative workflows

Financial models typically have one person “owning” the model and contributors who provide input and/or consume output from the model. Having contributors provide input is a classic challenge in financial modeling.

Collaboration challenges have historically been closely tied to version challenges. Sharing different Excel workbooks made merging changes from different people a pain. Live collaboration in Excel and Google Sheets has at least ensured that contributors work on the same version.

However, once live collaboration became the standard, two more challenges arose:

1. Ensuring that contributors only see what they should see

Since there is no way to restrict users to a specific part of an Excel or Google Sheets model, we see that finance teams effectively return to creating multiple workbooks to gather input, leading to the same historical challenges.

Software teams often work with sensitive data and systems, which presents similar confidentiality challenges. To mitigate this, they often use the Least Privilege Principle, which dictates that users should be granted the minimum levels of access - or permissions - necessary to perform their job functions.

Leveraging this in a finance setting means limiting access to specific sections of the financial model. For instance, sales teams can only view and input data related to sales forecasts, while the finance team maintains control over the overall model structure and core financial data.

While this is, unfortunately, hard to do in Excel and Sheets, new FP&A platforms support this functionality.

2. Approving changes made by collaborators

Allowing multiple contributors with editor rights into your spreadsheet opens the gates to unintended changes. In our experience, finance teams must approve changes to ensure models stay functional and input is aligned with management.

This can be compared to open-source software projects with few editors and many contributors. Here, contributors can make suggestions that the editors can then review and choose to accept at their will.

The clearest analogy is probably the track changes and approve suggestion features known from Google Docs.

Approval workflows can help make planning a decentralized, collaborative process and remove the finance team’s burden of being a bottleneck.

Conclusion

Both finance and software are highly capable teams with similar workflows. Many software tools that stood the test of time can be applied to finance to improve efficiency and quality.

At Francis, we’re trying to bridge the two worlds by providing finance teams with new powerful tools. In future posts, we’ll describe in more detail how we leverage these tools in Francis.

We tried to hide our smiles — awesome! Who doesn’t appreciate such positive feedback? Things were looking promising.

“... but you’re definitely not there yet!”

Ouch. Back to the drawing board.

That sales call took place in early 2023, with a Head of Finance commenting on our efforts to create a new type of spreadsheet - one purpose-built for financial planning.

But what exactly was the “there”? And why did he love it in the first place?

When we first set out to create an FP&A platform, we stumbled upon Packy McGormick’s piece, Excel Never Dies. It’s a remarkable article arguing that Excel has become the most influential software ever built. However, it also discusses the unbundling trend, where niche applications are developed for specific functions previously handled by Excel.

So, we wondered: With so many seemingly great FP&A solutions available, why do most finance teams still rely on Excel or Sheets?

From our early conversations, we discovered that most finance teams had indeed tried implementing new FP&A platforms. Lack of awareness wasn’t the issue. However, the vast majority eventually found themselves returning to their trusted spreadsheets.

So, what enables spreadsheets from the 1980s to outcompete Excel alternatives developed 40 years later? Why couldn’t modern software compete with seemingly primitive spreadsheets?

Through hundreds (yes, hundreds!) of conversations, we found that FP&A professionals love spreadsheets for three reasons:

1. Flexibility

2. Autonomy

3. Familiarity

1. Flexibility to build custom models

No two companies are the same. Their financial models differ, their general ledgers contain different accounts, and their teams have different understandings of FP&A.

One major issue that we discovered with existing solutions, was that they often tried to shoehorn diverse businesses with varying needs into a standardized, restrictive system.

However, finance teams require modeling flexibility. Any platform attempting to replace their current spreadsheet models must allow the same level of flexibility. Covering 90% of their modeling requirements simply won’t cut it for planning purposes.

With spreadsheets, finance teams have become accustomed to unlimited flexibility. If you throw enough time, VLOOKUPs and VBA at your model, anything is possible within the world of spreadsheets. Also, no board member will ever be satisfied with the excuse: “Sorry, our new FP&A platform doesn’t allow me to model our new loan structure.”

The caveat? You’ll need to build the entire system yourself. More on this in a future post.

2. Avoid dependency on outside resources

Finance is accountable for the accuracy and timeliness of numbers, so relying on outside resources is a business risk.

Finance teams have spent significant time learning the ins and outs of Excel or Sheets: structuring models, transforming data, building reports, mastering shortcuts, and much more. They rely on familiar grid layouts and formula syntax to develop sophisticated analyses and keep up with their business's ever-changing environment. When relying on spreadsheets, the finance team’s time is the only scarce resource. While it's admittedly under pressure, it's within their control.

Being comfortable implementing, managing, and restructuring your tools and systems is critical across all departments — including finance. However, most “modern” FP&A platforms add complexity far exceeding traditional spreadsheets. They often require upskilling of the finance team, more technical profiles, or vendor dependency. No board member is satisfied with “A new forecast? Sure, I’ll put in a ticket with our developers and get back to you next quarter.”

3. Ease of use for everyone

Equally important, the finance team must collaborate with the rest of the organization, especially for planning purposes. Having a platform that is easy for non-finance stakeholders to use is critical. 

Why would teams invest time and effort in learning a new tool when everyone is proficient with spreadsheets? Everyone knows how to use a spreadsheet; tool fatigue is a major pain.

Conclusion

Now, with this information, we’ve concluded that your finance team will stick to Excel or Sheets until an FP&A platform emerges that:

1. is flexible enough for your finance team to replicate their spreadsheet models 1:1 without compromising flexibility.

2. enables your finance team to confidently develop, maintain, and restructure their models without needing technical support or external consultants.

3. is intuitive enough for non-finance colleagues to navigate immediately.

So, how does all of this relate to the prospect at the beginning of this post? While the prospect appreciated the familiarity of our platform, he needed more flexibility to replicate his Excel model. Since then, we've worked to close that gap.

P.S. We printed that customer quote and hung it in our office as a reminder to keep our eyes on the ball.