You point Claude Code at your books and ask for a forecast. Ninety seconds later you have a number, a chart, and three confident paragraphs about your runway. It looks like something a real analyst would hand you, and somewhere underneath the polish there’s a quiet, nagging question: where did this number actually come from?
A modern coding agent is genuinely good at this work. Pointed at your general ledger, it can interview you, write a model, reconcile a P&L, and explain a variance. The intelligence is absolutely there. What’s missing is everything around the reasoning: the tested accounting math, the provenance, the memory, tribal knowledge and the checks that separate a real analyst from a very confident intern.
Without the right rails and tools, the agent does what an intern with no supervision does: it writes a fresh pile of pandas every single run. New code, new assumptions, no shared accounting logic, no audit trail, no memory of the correction you made last week or understanding of your business or tribal knowledge. The output looks identical to trustworthy work but likely isn’t which is exactly the problem.
For a throwaway “roughly how much cash do we have?” question, fine. Ship the vibes. But the moment the number touches a board deck, a hire, a raise, a game changing strategy or a covenant, “the AI said so” stops being an answer. The only thing that matters is whether you can trace the number back to a source, see what was mapped, and know what failed silently along the way. A confident paragraph can’t tell you that.
What openfpa does (the point of this blog post)
openfpa is an agent-native FP&A workbench. Not an app you configure yourself into, not a connector marketplace, not a universal financial model. If Claude Code or Codex is the reasoning engine, openfpa is the FP&A toolbelt it straps on.
Traditional FP&A software, from Anaplan to datarails, asks your company to remodel itself inside a fixed application. openfpa does the opposite. It hands the AI a tested finance kernel (driven by real world FP&A work), an operating contract, durable company memory, and a research loop. Then it lets the agent learn your business and build the system your CFO actually needs.
A D2C brand, logistics company, and the SaaS startup don’t share a chart of accounts, a seasonality curve, or a definition of “good forecast,” so they shouldn’t share a model.
The kernel handles the accounting that’s the same everywhere: revenue, COGS, opex, working capital, debt, tax, indirect cash flow, 13-week direct cash, reconciliation, segment rollups, and SKU rollups.
The company-specific code the agent writes lives in plain, readable namespaces, like models/generated/ and connectors/generated/, where you can review it like any other PR. And the whole thing is plain files, Markdown and YAML in a .fpa/ directory, not a row in someone’s proprietary database. MIT licensed, runs locally (and you are welcome to submit a PR to make it better).
Lineage isn’t optional
The obvious shortcut is to let the agent read a CSV off disk and treat it as truth. Sometimes the file is exactly what it looks like. But a file existing in a folder is not provenance, and an agent that silently maps “Product Rev” into product_revenue because the names rhyme is how you end up explaining a $400k variance to your board that turns out to be a duplicated account.
So openfpa refuses to treat file presence as lineage.
Every source a model relies on gets registered with its entity, currency, periods, extraction method, and location. Every mapping from a source account to a model line is explicit and versioned, including deliberate ignores with a written rationale. Then reconciliation runs, and missing, duplicate, conflicting, or unmapped data fails loudly instead of disappearing behind a default.
A reconciliation gap you can see is a problem. A reconciliation gap the model smoothed over for you is a landmine. A bad number is worse than no number, because it hands you confidence you never earned.
The model has to earn its place
You can’t write the perfect company model up front. The first one is a hypothesis about what drives the business. Then reality shows up: December actually runs 2x, not 1.3x; the deferred revenue was double-counted; that Q3 spike was a one-off contract that should never train the forecast.
Those corrections shouldn’t die in a Slack (or…gasp…Teams) thread. openfpa captures them as durable records you own: parametric, structural, or contextual.
Parametric means a driver was wrong. Structural means the method was wrong. Contextual means this period was weird, so don’t learn from it.
That is roughly how finance people already think about their mistakes.
And model changes don’t get to ship on “feels better” either. The iteration loop is borrowed from Karpathy’s AutoResearch: state a falsifiable hypothesis, run a bounded experiment, keep what measurably improves, and preserve the failures so nobody reruns them next month without new evidence.
A challenger has to beat the champion on held-out actuals, not the periods it was fit on, while clearing hard checks: source reconciliation, accounting identities, segment rollups, working-capital continuity, and scenario coherence.
A change that improves your headline forecast metric but breaks an accounting identity isn’t an improvement. It’s a failed experiment.
The agent can generate and discard challengers all day on its own. Swapping the champion that your decisions depend on requires you to sign off, with the metrics and tradeoffs in front of you. Human control stays at the consequential boundaries: external access, architecture, and promotion. Nowhere else.
And when it gives you Excel, the formulas are real
Finance lives in Excel, so the agent can hand you a workbook. But a workbook of pasted-in static values is just a screenshot with extra steps. You can’t poke it.
openfpa compiles the model into a live-formula workbook: an Assumptions sheet of named, editable driver cells, and a Model sheet where every P&L and cash-flow line is an actual formula referencing those names. Change an assumption and watch the model move, the way a real analyst’s model does.
The catch with generating formulas is that it’s easy to generate wrong ones that happen to look plausible. So nothing ships unverified.
A harness evaluates the workbook with a Python formula engine and compares every line, every month, against the engine that produced it, to 1e-6. If it doesn’t match, the exporter is wrong and it doesn’t go out. You never loosen the tolerance to make it pass.
It’s an alpha (yes, like my other open source software, benchrail)
There are two runnable proofs in the repo today: a synthetic product company, Ridgeline, with a monthly forecast, a 13-week cash model, and an inventory-build liquidity gap; and Fox Factory, built entirely on public SEC filings, where the research loop holds out FY2025, rejects an over-aggressive recovery challenger, and proposes a better one.
The Fox Factory README is honest about the limits. Three annual observations aren’t statistical certainty, and it says so out loud rather than laundering it through a confident chart.
The whole proof runs in CI across Python 3.11 through 3.13.
git clone https://github.com/JeffBrines/openfpa
cd openfpa
python3 -m venv .venv && source .venv/bin/activate
python -m pip install -e ".[dev]"
Then open it in Claude Code or Codex and say:
Help me onboard this company into openfpa. The financial files are in
./company-data. Inspect them first, then ask me only what you cannot determine.If you’ve ever taken a number off an AI and couldn’t honestly say where it came from, I’d like you to try it. Break it, open an issue, send a PR, or tell me the framing is wrong. Alternatively, hire my firm to come in and build your own open source FP&A system custom for your company. I promise its faster, more enlightning and easier than you’d ever believe, and you can skip the $5,000 / month charges the other guys levy.
The goal is narrow: make AI-built financial work auditable instead of merely confident while learning along the way. We’re getting there…