Headless FP&A
The interface has become the cheapest part of the planning stack. What remains — the model, the engine, the agents — is where the future of FP&A will be decided.
Farseer is used in this example because it is the platform I build and work with.
Every FP&A platform on the market sells you, above all, an interface: a grid, a dashboard, a planning screen. For twenty years that was rational — the interface was the product, because it was the only way a finance team could reach the model behind it.
That assumption is quietly dying. AI assembles working screens on demand, and “just-in-time” UI — generated for one user and one question — is turning from a demo into a default expectation. When a competent dashboard costs an afternoon of prompting, the dashboard stops being the moat.
Analytics went through this transition first: headless BI separated the governed metric layer from any single rendering tool — define revenue once, serve it to every consumer. The term is now arriving in planning too, usually framed around conversational budgeting. I think the architectural claim underneath it is bigger than the chat window. Here is the version I’m building toward.
The four layers of a headless FP&A stack
1. The model, written in a modeling language. Variables with their business grain, dimensions and their relationships, formulas — declared in a human-readable form an AI can interpret directly. This is what FML exists for. Just as important is the harness that travels with it: the business context attached to the numbers — what an account means, which assumptions produced a target, why a driver changed. An agent that sees only formulas can compute; one that also reads the harness can interpret.
2. The calculation engine. Massive calculations belong in one central, secure place. The engine takes the declared model and the data and does the heavy lifting: roll-ups across dimension graphs, scenario runs, driver propagation — millions of cells at a time. This layer can also be the system of record — the place where the numbers live and every change to them is kept — or that role can sit in a separate store the engine writes through. In Farseer they are one system. Either way, it is the engine that produces the audit trail; more on that below.
3. Interfaces, vibe-coded on demand. Once the model is legible and the engine queryable, the presentation layer becomes disposable in the best sense: a controller asks a question and a purpose-built view is generated for it — right chart, right comparison, right distribution. This is where a modeling language beats a metric layer: headless BI serves governed numbers to whatever tool asks, but an AI with the right skills that reads the model itself — grain, relationships, harness — can generate the dashboard, and get it right.
And the same goes the other way, for getting numbers in. A planner can type into a grid, as they always have, or simply tell the agent — “move the Q4 launch to March and hold the marketing budget flat” — and the agent writes to the inputs the model declares as writable, at the grain they belong to, with the change logged. Entry through conversation and entry through a screen are the same operation on the same model; only the surface differs.
4. AI workflows. Agents automate the daily work of an FP&A department — data checks, variance commentary, forecast refreshes — and act proactively: they watch the model, not a to-do list. At scale their most valuable job is focus: surfacing the few variances and drivers that deserve a human’s attention, instead of another report that contains everything and says nothing. Stakeholders stop fetching numbers; reports arrive first.
Where audit and control live
Mostly in the compute layer — with one half that belongs to the model.
Every value that changes passes through the engine, so that is where the audit trail is produced: who set it — a planner or an agent — which value, at which grain, when, and with an undo. The same layer enforces the rules that make an audit worth having: actuals read-only after close, budgets locked after sign-off, historical periods editable by administrators only with every override logged, and whoever plans not approving their own plan.
The controls themselves are modeled. A reconciliation or an integrity check is a variable like any other — assets minus liabilities minus equity must read zero — computed by the engine on every recalculation and watched by the workflows layer, which raises it the moment it stops reading zero. Not three weeks later, in a review.
The model layer adds the part that was always missing: the audit of the logic itself. A platform log tells you a number changed. It cannot tell you why the formula behind it changed, or who approved that. Once the model is text under version control, every logic change is a diff with an author, a timestamp and a reason — and approving a model change becomes a review, not an announcement.
The open question: where do the AI models run?
The financial model and its data are the settled part: they run on the calculation engine, and the engine should be chosen on one criterion — performance. The unsettled part is the AI layer. When agents read your planning model and draft your commentary, which AI models do that work, and on whose servers? If every prompt carries planning context to an external AI vendor’s cloud, your most sensitive numbers are transiting infrastructure you don’t control — for plenty of companies, and entire industries, that is simply not acceptable.
In a headless FP&A stack the AI models are a controlled component like every other layer: selected, governed and deployed where your compliance says they must be — not an external default you inherited with the product. The agent reads the model’s structure and proposes changes as reviewable diffs; the raw numbers never cross a boundary you didn’t choose.
Why headless wins
No vendor lock-in. A model written in a readable language is portable by construction: if your planning logic lives as UI state inside one vendor’s application, the exit cost is a rebuild; if it lives as text, it’s a migration script.
The interface is no longer the product. Screens are cheap now; performance over enormous volumes of data is not — recomputing millions of cells fast enough that planning and simulations stay interactive. Whoever competes on “our grid is nicer” is competing on the commodity layer; the engine underneath is where the real race is.
The complete experience is the product. The relevant player in FP&A will be the one who delivers the whole chain — a legible model, a serious engine, generated interfaces, agents doing real daily work — as one coherent experience. Not the prettiest fragment of it.
That is the bet behind everything I write here: the discipline’s future is a stack you can read, not a screen you can click.