What Is FP&A? (Financial Planning and Analysis)

Financial Planning and Analysis (FP&A) is the corporate finance function responsible for budgeting, forecasting, and modeling a company's financial performance. FP&A teams translate business strategy into numbers and explain the gap between plan and reality.

That's the definition. But in 2026, FP&A is in the middle of a structural change — and understanding where it's going matters as much as understanding what it is.

What FP&A teams actually do

Three core activities define the FP&A function:

Budgeting. Once a year (typically), the FP&A team builds the plan: what revenue do we expect, what headcount do we need, what does the cost structure look like? The output is an operating plan that becomes the company's financial commitment for the year.

Forecasting. The plan is always wrong. FP&A's job is to update the plan as reality unfolds — rolling forecasts that narrow the gap between what was expected and what's actually happening. A good FP&A team forecasts continuously, not just quarterly.

Analysis. Why is revenue tracking 15% below plan? Is the churn variance structural or one-time? Should we accelerate hiring in Q3 or wait for the data? FP&A answers these questions with financial analysis — variance analysis, scenario modeling, sensitivity analysis, and the operating model that ties them together.

The stakeholders: the CFO and CEO are the primary consumers. Department heads use FP&A's output to make decisions with financial clarity. Investors and board members use FP&A models in diligence, in board packages, and in evaluating strategic options.

FP&A vs. accounting vs. finance

The three terms are often confused. They describe different functions with different orientations:

FP&A sits inside the broader Finance department but has a distinct mandate. The Controller records what happened and closes the books. The FP&A analyst models what's going to happen and explains why the plan differs from reality.

In smaller companies, one person does all three. At scale, they're separate teams with different reporting lines and different tools.

The three-statement model

FP&A's primary working artifact is the three-statement financial model: the income statement (P&L), balance sheet, and cash flow statement — linked through the accounting mechanics that connect them.

The model is the language FP&A speaks. When a CFO says "run the model at 15% growth instead of 20%," they mean: update the top-line assumption, propagate it through gross profit, EBITDA, cash flow, and balance sheet, and show me the new output.

In a well-built model, that cascade is automatic. Change one driver — growth rate, churn, gross margin — and every downstream value recomputes. The quality of an FP&A team is often visible in the quality of their model: are the assumptions named? Is the dependency chain explicit? Can you run a scenario without breaking anything?

See a live compiled three-statement model →

FP&A at different company stages

The FP&A function looks very different depending on the company's stage:

Pre-seed / seed. Usually the founder running a spreadsheet. The "model" is a burn rate calculation and a revenue assumption. FP&A is informal.

Series A / B. The first dedicated FP&A hire — or a fractional CFO doing the modeling work. The model starts to matter: for fundraising, for board management, for the first real operating plan. This is where the model's architectural quality becomes an issue — built fast, often fragile, impossible for anyone else to audit.

Scale-up. A proper FP&A function with a Head of FP&A, possibly a small team. Rolling forecasts, department-level budgets, OKR alignment, headcount planning. The model complexity grows. The spreadsheet cracks start to show.

Enterprise. Full FP&A department, potentially a dedicated platform (Anaplan, Adaptive Planning, Pigment). Consolidation complexity, multi-entity models, board-package automation.

Flatland's ICP is Series A through scale-up: companies where FP&A is maturing but hasn't yet calcified into an enterprise software contract. The Finance Engineer is often the first FP&A hire at a technical company — they build the function rather than inherit it.

The tools FP&A uses (and why the stack is changing)

The spreadsheet layer (where most FP&A still lives):

• Excel: dominant, flexible, untyped, no audit trail, no dependency graph
• Google Sheets: more collaborative, less institutional, structurally identical problems

The FP&A platforms (mid-market to enterprise):

• Anaplan, Adaptive Planning, Workday Adaptive: powerful, expensive, locked-in, built for traditional workflows
• Pigment, Datarails, Cube, Mosaic: mid-market with better Excel integration — still server-side, still not agent-native
• These platforms work. They're designed for the traditional FP&A workflow: human + spreadsheet + dashboard + vendor support contract.

The agent-native layer (emerging in 2025–2026):

Finance Engineers at technical companies are rebuilding FP&A from scratch. They're not buying a platform — they're building the function using the same tools they use for everything else: Claude Code, MCP, APIs into their ERP, and typed compiled models.

For this workflow, none of the traditional platforms fit. The model needs to be:

• Typed (assumptions have names and units, not cell addresses)
• Callable (your AI agent can read from it and update it)
• Auditable (every compile produces a verifiable record)
• Client-owned (the model is yours, not hosted on a vendor's server)

This is what Flatland provides: typed compiled financial models, MCP-native, with computation provenance on every compile.

FP&A is the last manual process in the Finance Engineer stack

This is the most important thing to understand about where FP&A is in 2026.

Finance Engineers have automated the rest of the finance function in the last two years:

• Accounts payable: automated with Claude Code + ERP API
• Accounts receivable aging: live, scripted
• Month-end close: partially automated, partially scripted
• Data pipelines into the warehouse: dbt + Fivetran, fully automated

The FP&A model — the forecast, the three-statement, the scenario analysis — is still built by hand in Excel.

That's the gap. And it's closing.

The Finance Engineer's question is not "how do I buy a better FP&A platform?" It's "how do I make the model layer as well-engineered as everything else in my stack?" The answer is typed compiled models with computation provenance: assumptions that have names and types, an explicit dependency graph, deterministic compilation, and a signed receipt on every compute.

That's the architecture that makes FP&A legible to AI agents, auditable by investors, and maintainable by the next person on the team — without a vendor contract and a six-week implementation.

What FP&A looks like when the model layer is typed

When the FP&A model is typed instead of a spreadsheet:

• Assumptions have names: monthly_growth_rate is not B7. It's a declared driver with a type (Percentage), a label, and a unit. Any reader — human or AI agent — knows what it means.
• The dependency graph is explicit: change gross_margin and every downstream value — EBITDA, cash from operations, runway — recomputes automatically and visibly.
• Scenarios are sparse overlays: you don't maintain three separate Excel files for base/upside/downside. You maintain one typed model and three scenario overlays that change the assumptions you care about.
• Exports are auditable: the Excel file your board sees was generated from a typed model, not assembled by hand. It scores 100/100 on an institutional quality rubric — live formulas, named ranges, blue inputs, black computeds.
• The model is callable: your AI agent can read from it, update assumptions, recompile, and return the new output. The model is part of your automation stack, not separate from it.

This is FP&A for Finance Engineers. The function is the same — budgeting, forecasting, analysis. The infrastructure underneath it is finally as well-engineered as the rest of the stack.

The short version

FP&A is the function that makes a company's financial strategy legible and auditable. It lives between accounting (recording the past) and capital allocation (shaping the future). Its primary artifact is the financial model.

In 2026, the Finance Engineers rebuilding FP&A from scratch aren't buying a platform. They're building the function — typed, compiled, agent-native — on infrastructure designed for the way technical teams actually work.

The model layer, engineered as infrastructure, has a name: Financial Reasoning Infrastructure. If you're one of them: see what the model layer looks like in Flatland →