What Is a Finance Engineer? (Not What You Think)

If you searched "finance engineer" looking for information about MFE programs, financial derivatives, or quantitative modeling careers — you've landed in the right place, but you may be surprised by what you find.

There's a second meaning for this term. It's newer, it doesn't have an academic credential yet, and there's no formal job title. But it's spreading fast through the CFO offices of mid-market companies, the communities of fractional CFOs, and the finance teams at startups that move quickly. Rillet, which runs the most active "Finance Engineer" community in the world right now, has started running certification programs for it.

This essay is about that meaning — not the quant, but the operator. Not the MFE graduate pricing derivatives in a bank, but the Controller who built an accounts-payable inbox agent in Claude Code last month and is now wondering what to call themselves.

What Is a Finance Engineer?

Rillet defines a Finance Engineer as a finance professional who builds their own tools. Not a software engineer who works in finance. Not an accountant who uses AI. A controller, VP Finance, Head of FP&A, or fractional CFO who has developed the technical skill to automate the repetitive parts of their job using AI coding assistants, APIs, and modern infrastructure.

The behavioral definition is more precise: a Finance Engineer is someone who, when they encounter a manual process in their finance workflow, asks "can I build something to handle this?" — and then does.

The skill set has three components:

• Finance domain expertise: deep knowledge of how the numbers work, what the rules are, what the audit trail requires
• AI coding tools: the ability to work with Claude Code, Cursor, or similar assistants to build automations and scripts without being a professional software engineer
• Systems thinking: an understanding of how ERPs, APIs, and data pipelines connect — so the Finance Engineer can wire them together

This is categorically different from a financial engineer in the traditional sense. The quant finance discipline — derivatives pricing, structured products, risk modeling — is a legitimate and demanding field. But it's a research and mathematics discipline, not an operational one. The Finance Engineer emerging right now is not replacing the quant; they're a new function that sits inside the operating finance team.

The simplest distinction: a financial engineer prices assets. A Finance Engineer automates the work of pricing, reporting, and modeling those assets.

What Finance Engineers Actually Build

The concrete list matters here, because the abstract definition is easy to dismiss as hype. The Rillet Close Club — a community of active Finance Engineers with roughly 100–300 regular participants — has published session topics from their weekly "Vibe Code for Finance" calls. The list reads like a technical backlog:

• AP inbox agent (reads vendor invoices, categorizes, routes for approval)
• AR dashboard (live aging report pulling from NetSuite via API, no manual export)
• Month-end close automation (reconciliation scripts that flag exceptions rather than requiring manual review)
• Budget vs. actuals variance reporter (runs on schedule, posts to Slack)
• Headcount model sync (HRIS data → finance model, no copy-paste)
• Covenant compliance tracker (reads loan documents, monitors live against actuals)

The pattern across all of them: Finance Engineers automate the repeatable so they can focus on the important. They are not eliminating finance judgment — they are eliminating the 80% of the workday that doesn't require judgment but consumes it anyway.

"I can get actuals out of NetSuite in 30 seconds now. The forecast still takes three hours."

That quote captures the state of play precisely. The retrieval and formatting is solved. The reasoning and modeling — the three hours — is not.

The Finance Engineer's Tool Stack

The stack a Finance Engineer works with today has four layers, and each layer is increasingly well-served — except one.

GL / ERP layer: Rillet, NetSuite, QuickBooks Online, Sage Intacct. These are the systems of record for transactions. Rillet in particular is building API-first, which is why Finance Engineers disproportionately appear in Rillet's community — the product was designed to be integrated, not just used.

AI coding layer: Claude Code, Cursor, Windsurf. These are the tools Finance Engineers use to write the automations. A Finance Engineer doesn't need to be a professional developer — they need to be able to describe a process in natural language, iterate on the generated code, and debug when it breaks. This skill is more accessible than most people expect; the Rillet community includes Controllers who had never written a line of code before 2024.

Protocol layer: MCP (Model Context Protocol). This is the infrastructure that makes AI agents and software systems talk to each other. Finance Engineers are increasingly aware of MCP because it's the mechanism that lets Claude Code read from their ERP, write to their model, and act on results without a human in the loop. If you haven't encountered MCP yet and you're building finance automations, you will.

Modeling layer: This is where the gap is.

The first three layers now have real, purpose-built tools. The modeling layer — the financial model itself, the forecast, the three-statement model, the scenario analysis — is still in Excel for most teams. Not because Excel is the right tool, but because nothing else has earned trust.

"Claude helps me write the code, but when I ask it to reason about the model, it just sees a spreadsheet."

That's the precise problem. A spreadsheet is an output, not a structure. It has no types, no audit trail, no dependency graph. You can't compile it. You can't query it. You can't fork it for a scenario without emailing versions.

This is the last frontier for Finance Engineers: the model layer. The automation layer is largely solved. The modeling layer is not.

That is the model layer made concrete: typed assumptions, a compiled output, assertions that hold — and a file you own. Drag a lever in the Workshop and every downstream value recomputes, deterministically.

Why the Finance Engineer Category Is Growing Now

Three forces converged in roughly 2023–2025 that didn't exist before:

AI coding became accessible to non-engineers. Claude Code and similar tools lowered the skill floor for building automations from "write Python professionally" to "describe what you want and iterate." A Controller who can write a clear process description can now build the tool that executes it.

MCP made system integration tractable. Previously, connecting an ERP to an AI agent to a financial model required real software engineering. MCP made it a configuration problem. The plumbing is largely handled; the Finance Engineer assembles the pieces.

ERPs became API-first. NetSuite, Rillet, and others have opened their APIs in ways that make programmatic access the normal path, not the exceptional one. The data is accessible without calling a vendor.

The economic incentive is powerful: a Finance Engineer with Claude Code can replace 2–3 weeks of manual work per month. At $150–300/hour billing rates for fractional CFOs, that's not a feature — it's a business model.

Rillet's Recon 2026 conference drew 250 attendees. The CFO Connect State of AI in Finance 2026 report shows AI adoption accelerating across the 12,000-member CFO Connect community. These aren't early-adopter signals anymore; they're early-majority signals.

The analogy that fits best: Finance Engineers are to finance what DevOps was to engineering teams in 2012. A new function, no formal title, no academic program, but clearly a distinct and growing capability. In 2012 you couldn't hire a "DevOps engineer." By 2016, every infrastructure team had one. The Finance Engineer category is in the 2013 moment of that arc.

Is This You?

The diagnostic here is behavioral, not title-based. You're probably a Finance Engineer if:

• You've used Claude Code, Cursor, or a similar AI coding tool to automate something in your finance workflow
• You know what an API is and have called one — or asked someone to explain it and immediately understood why it mattered
• When you encounter a manual process that takes hours, your first instinct is to wonder if it could be scripted
• You have a mental model of how your ERP's data is structured, not just where to find numbers
• You've explained your work to a colleague and they looked at you like you were describing a different job than they have

If three or more of those are true, you are functionally a Finance Engineer. Whether you use the title is optional; the capability is already there.

The community you're looking for: Rillet's Close Club runs weekly sessions where Finance Engineers share what they're building. CFO Connect publishes ongoing research on AI adoption in finance. These are the places where the category is being defined in real time.

The Last Frontier

Finance Engineers have automated almost everything. The last frontier is the financial model itself.

The automations are working. The data is flowing. The AP agent is routing invoices and the AR dashboard is live. But when it's time to build the forecast, model a scenario, or hand an investor a three-statement model — the workflow hits Excel.

"I need an audit trail that doesn't involve emailing Excel versions back and forth."

That's a systems problem, not a spreadsheet problem. The model needs types — what is this number, what are its valid values, what does it depend on? It needs a dependency graph — if this assumption changes, what else changes? It needs history — who changed what, when, and why? It needs to be queryable — not just by a human, but by the agent the Finance Engineer built.

This is what Flatland was built for. Flatland is a typed financial modeling engine: you define your assumptions, your formulas, and your dependency graph, and it compiles. The model is structured, auditable, and callable via MCP — which means the Finance Engineer's AI agent can read from it, update it, and reason about it the same way it reads from the ERP.

"You built the automation layer with Claude Code and Rillet. Now build the model layer with Flatland."

If you're a Finance Engineer and you've gotten this far, the natural next step is to see what a compiled, typed model feels like. The Flatland quickstart takes about eight minutes — you install the MCP server, build a model with a few typed assumptions, compile it, and see what the output looks like. It's not a sales demo. It's the actual tool.

The Finance Engineer category is being defined right now. The modeling layer is the open problem. This is what comes next.

The model layer, given the same architectural discipline as the rest of the stack, has a name: Financial Reasoning Infrastructure. See it as a live, forkable model: the three-statement model preset and the LBO model preset both compile in your browser.