How to Build an FP&A Function From Scratch: A Practical Guide

I have a strong opinion about building an FP&A function from scratch:

Don’t start by hiring FP&A people.

I realize this is an inconvenient opening for an article about building an FP&A function.

But I’ve seen companies decide they need FP&A and immediately jump to the org chart.

We need a Director.

Maybe two analysts.

Should there be a manager?

Who reports to the CFO?

Someone opens PowerPoint and boxes begin appearing.

I want to know something much less exciting first:

What exactly do you need FP&A to do?

Because if you don’t answer that, there’s a decent chance you’ll build a team that spends the next two years producing reports nobody asked for while leadership continues making decisions somewhere else.

I’ve seen enough finance functions to know that adding people doesn’t automatically create FP&A.

Sometimes it just creates more people with Excel open.

First, Be Clear About What FP&A Is Supposed to Do

At its core, FP&A exists to help the business make better decisions about where it is going and how it should use its resources.

The Association for Financial Professionals describes FP&A’s role around planning, forecasting, performance management, modeling, analysis and ultimately supporting decisions about allocating capital and resources.

That’s a useful definition.

Mine is less formal:

FP&A should help management understand what is happening, what is likely to happen next, and what we should do about it.

Everything else should support that.

Budgeting.

Forecasting.

Reporting.

Variance analysis.

Scenario modeling.

Business partnering.

None of those is the final product.

The final product is a better decision.

I think companies forget this surprisingly often.

They build a reporting factory and call it FP&A.

Before You Build FP&A, Make Sure Accounting Works

This is the part nobody particularly enjoys hearing.

You cannot build a great FP&A function on top of financial information nobody trusts.

Well, technically you can.

You can also build a house on sand.

The meetings will be exciting.

Before I start worrying about sophisticated forecasting, I want reasonably reliable actuals.

I want a close process that works.

I want definitions people understand.

I want to know where revenue, expenses, headcount and other important operating data come from.

And I would very much like Accounting and FP&A to agree on how much money the company made.

This doesn’t mean Accounting has to be perfect before FP&A begins.

If we waited for perfection in Finance, we’d all have considerably more free time.

It means the foundation needs to be trustworthy enough that FP&A isn’t spending half its life reconciling yesterday.

Disconnected data and nonstandard reporting can prevent FP&A from producing the decision-ready insights the business actually needs.

That’s why my first FP&A question is sometimes an Accounting question.

Can we trust the actuals?

If the answer is “mostly,” I’ve found our first project.

Start With the Decisions

This is where I would actually begin.

Sit down with the CFO and leadership team and ask:

What decisions are we repeatedly trying to make?

Not:

What reports do you want?

That’s how you end up with 63 reports.

Ask about decisions.

Should we hire?

Can we afford this investment?

Which products are actually making money?

Should we change pricing?

Are we going to hit the year?

What happens if sales slows?

Where should we put the next dollar?

What is happening to cash?

What would cause us to miss the plan?

Now FP&A has a job.

This distinction matters because modern FP&A is increasingly expected to provide actionable insight and decision support, not simply perform budgeting and reporting.

I want the function designed backward from those decisions.

Decision → information → analysis → process → system → people.

Not:

Software → reports → meetings → eventually somebody asks what we’re trying to accomplish.

I’ve seen the second sequence.

Vendors tend to enjoy it more than CFOs.

Build the Basic FP&A Operating Rhythm

Once I understand the decisions, I start building the rhythm.

A young FP&A function does not need 47 processes.

It needs a few important ones that actually work.

At minimum, I usually want:

• an annual planning process,
• a recurring forecast,
• monthly performance reporting,
• variance and driver analysis,
• cash visibility where appropriate,
• headcount and expense planning,
• scenario modeling,
• and a regular way for Finance and the business to talk about what changed.

The exact cadence depends on the company.

A rapidly growing PE-backed business may need a very different forecasting rhythm from a stable professional-services company.

That’s why I’m suspicious whenever someone tells me the “best practice” is to forecast exactly a certain way.

Best for whom?

The process should match how quickly the business changes and how quickly management needs to make decisions.

The important part is that people know when information is due, who owns it, what Finance does with it, and when decisions get made.

Forecasting especially needs clear information flows and responsibilities across Finance and the business.

Otherwise the forecast becomes Finance chasing people through Teams.

Nobody puts that in the FP&A job description.

It is nevertheless a surprisingly large portion of the job.

Figure Out the Business Drivers Before You Build the Model

I don’t want the first forecast to be beautiful.

I want it to make sense.

What actually drives this business?

For a SaaS company, I may care about bookings, ARR, churn, expansion, pricing, headcount and customer acquisition.

For a services company, I may care about utilization, bill rates, capacity, pipeline and hiring.

For another company, inventory, units, volume, labor or commodity costs may matter much more.

The model should reflect the economics of the business.

That sounds obvious.

It isn’t always what happens.

Sometimes Finance starts with last year’s financial statements, adds assumptions to every line and creates something that mathematically qualifies as a forecast.

Revenue: +10%.

Travel: +4%.

Software: +7%.

Congratulations.

We have forecasted inflation in spreadsheets.

Driver-based models are useful precisely because they connect scenarios and financial outcomes to the underlying factors that actually drive performance.

I want FP&A to know those drivers well enough that when something changes, the team knows where to look.

Decide What FP&A Owns and What the Business Owns

One of the fastest ways to ruin an FP&A team is to make Finance responsible for every number in the forecast.

Sales should understand the sales assumptions.

Operations should understand operating assumptions.

HR should understand hiring.

Department leaders should understand their spending.

FP&A owns the process, the financial logic, the challenge and the consolidation.

It should not manufacture everybody else’s reality for them.

I want business leaders involved enough that they recognize their own assumptions when the forecast reaches the executive meeting.

If the head of Sales looks at the revenue forecast like Finance has just introduced them to a stranger, something has gone wrong.

Business partnering is part of the architecture here. FP&A has to connect its financial view with the people actually running the business. Both AFP and current FP&A research emphasize this decision-support and business-partnering role.

That relationship takes time.

Which is another reason I don’t want my FP&A team spending every available hour moving numbers between spreadsheets.

Then Hire the Team

Now we can talk about people.

The first FP&A hire depends heavily on what’s missing.

Sometimes you need a senior FP&A leader who can build the function and work directly with the CFO.

Sometimes you need a strong manager who can create the planning process and models.

Sometimes the CFO is already doing the strategic work and desperately needs an analyst to get some of it out of their head.

I don’t believe every company needs the same FP&A org chart.

Company size matters.

Complexity matters.

Business model matters.

Number of business units matters.

How centralized the organization is matters.

The quality of the existing Accounting team matters.

Gartner’s organization-design guidance similarly frames FP&A structure around business needs and operating complexity rather than a single universal model.

For a smaller company, I would rather have one very good FP&A person who understands the business than three people producing increasingly sophisticated versions of information nobody uses.

Your first hires need curiosity.

They need enough technical ability to build things.

They need enough accounting knowledge to understand actuals.

And they need to be able to talk to humans.

That last requirement has ruined several otherwise excellent résumés.

Don’t Buy the Planning Tool Too Early

There is a dangerous moment in building FP&A when someone says:

“We need a system.”

Maybe.

Eventually, probably.

But software is much better at scaling a process than inventing one.

Before I buy a planning platform, I want to understand:

What are we forecasting?

Who provides the assumptions?

How often do we update them?

What are the business drivers?

What reporting dimensions matter?

Where does the source data live?

Who owns it?

What breaks today?

AFP’s implementation guidance makes a similar point: planning technology should integrate people and data around the planning process, rather than treating the go-live itself as the strategy.

If you haven’t answered those questions, buying software may simply automate your confusion.

Now the confusion has a login.

I have nothing against FP&A software.

I have something against asking software to solve an operating-model problem.

Build One Version of the Truth

Eventually somebody is going to say this phrase, so we might as well deal with it:

“Single source of truth.”

I don’t need philosophical truth.

I’d settle for everyone using the same revenue number.

Early FP&A functions often inherit a strange ecosystem.

Accounting has one dataset.

Sales has another.

HR has headcount.

Operations has something extremely important stored in a spreadsheet nobody in Finance knew existed.

And somebody named Mike has the file that makes everything tie.

The goal isn’t immediately to put every piece of information in one enormous system.

The goal is to establish ownership and definitions.

What is ARR?

What counts as a customer?

How are bookings defined?

What is approved headcount?

Which actuals are official?

Who owns each dataset?

This work is boring right up until two executives walk into a meeting with different versions of the same KPI.

Then it becomes fascinating.

Don’t Let Reporting Eat the Function

This is one of the easiest traps.

Leadership asks for a report.

FP&A creates it.

Someone asks for another cut.

FP&A adds it.

A new executive arrives.

New report.

Board wants something.

Another report.

Two years later, the team has become a subscription service nobody remembers signing up for.

Reporting matters.

But every recurring report should earn its continued existence.

Who uses it?

What decision does it support?

How often is it actually needed?

Can it be automated?

Can the user answer the question without asking FP&A every month?

This is becoming even more important as FP&A teams face growing demand for decision support. Gartner has argued that simply adding more in-person support and more reporting does not scale indefinitely; technology and self-service decision support increasingly have to carry some of that load. Gartner

I want FP&A spending its scarce human time where judgment matters.

Not changing the date on page 14.

Measure Whether FP&A Is Actually Helping

Eventually I want to know whether the function we built is any good.

Forecast accuracy matters.

So does speed.

So does the reliability of reporting.

But I wouldn’t stop there.

I look at things like:

Are surprises decreasing?

Does leadership understand what is driving performance?

Does bad news reach Finance faster?

Can we answer executive questions without a two-day archaeological expedition?

Are assumptions explicit?

Can Finance explain what changed?

Are scenarios connected to actual decisions?

Is the business involving FP&A earlier?

And perhaps my favorite:

Is Finance helping the company decide something it couldn’t decide as well before?

Because you can build an extremely impressive FP&A department that produces immaculate work and changes absolutely nothing.

I don’t want that one.

What I Would Build in the First 90 Days

If I walked into a company tomorrow and had to build FP&A from scratch, I wouldn’t spend the first month drawing the perfect future-state organization.

I’d start working.

Days 1–30: Understand

Learn the business model.

Understand the financials.

Meet the operating leaders.

Map the data.

Find the recurring decisions.

Identify where management currently lacks visibility.

And locate Mike.

There’s always a Mike.

Days 31–60: Build

Create the basic management reporting.

Identify the core business drivers.

Build the first useful forecast.

Establish ownership for assumptions.

Create a planning calendar.

Start a regular operating conversation between Finance and the business.

Nothing fancy.

Useful beats fancy for quite a while.

Days 61–90: Improve

Find the manual work consuming the team.

Standardize definitions.

Fix obvious data problems.

Introduce scenarios around the decisions leadership actually faces.

Document the processes currently living in people’s heads.

Then decide what needs automation, additional talent or better systems.

Notice what I haven’t done yet:

Bought seven pieces of software.

Designed 42 KPIs.

Created a 60-slide finance transformation deck.

We have time.

Build the Function the Business Actually Needs

There isn’t one perfect FP&A function.

A $30 million founder-led company shouldn’t automatically copy the FP&A structure of a $2 billion public company.

The objective isn’t to look sophisticated.

It’s to become useful.

Start with the business.

Understand the decisions.

Get the numbers trustworthy.

Find the drivers.

Build the planning rhythm.

Establish ownership.

Hire around the work.

Then add technology where it actually removes friction or improves decisions.

If you do those things well, the FP&A function will become more sophisticated naturally.

And if you’re ever unsure whether you’ve built the right thing, I have a fairly simple test:

Walk into a leadership meeting and watch what happens when something changes.

Does everyone wait for Finance to explain last month?

Or does FP&A help the room figure out what to do next?

That’s the function I want to build.

Build the Operating Pieces

Once the function design is clear, the next layer is execution: establish an FP&A forecasting process, decide on the right team structure, and add FP&A software only when the operating problem justifies it.